New tools for Studio users

[PLUCKYHD]

I love this tool and I am so glad I found it

You mention needing to include the jar with the import is that just the

gkunsick.sagetv.jar?

many thanks for this great add in to studio.

[GKusnick]

Originally Posted by PLUCKYHD

You mention needing to include the jar with the import is that just the gkusnick.sagetv.jar?

Correct.

[PLUCKYHD]

Originally Posted by GKusnick

Correct.

Okay got a problem i am including the .jar with my import but if I import on a computer without your tools installed the external reference get lost

When I import on a computer with your tools it imports in fine?

[GKusnick]

How exactly are you including the JAR? Simply putting it in the same zip file is not sufficient. You must take steps to ensure that when the user unzips it, the JAR lands in the JARs folder where it belongs; otherwise Sage won't be able to find it.

[PLUCKYHD]

Originally Posted by GKusnick

How exactly are you including the JAR? Simply putting it in the same zip file is not sufficient. You must take steps to ensure that when the user unzips it, the JAR lands in the JARs folder where it belongs; otherwise Sage won't be able to find it.

Yes that is what I am doing including it in the jars it is in the right location in the zip and when I extract

If I download your import and extract the entire thing it works when mine imports.

[stuckless]

One potential issue... if the the jar is simply included in your plugin, then your users will have to shutdown sagetv, extract your plugin, then start sagetv, and import your plugin. If a user simply extracts your plugin with the jar file and then immediately tries to import it without restarting sage first, then sage will not see/use the newly added jar file.

So, a rule of thumb if you are including external dependencies... Have you users shutdown sage before they extract your plugin. This will need to be done on updates as well, since sage (windows only) won't be able to overwrite an existing jar file, if it's in use.

I only point out the restart, since with a stv that doesn not have any jar dependencies, it can be imported without having to restart sage, so this aspect of plugin development may be new to you.

[GKusnick]

Originally Posted by PLUCKYHD

If I download your import and extract the entire thing it works when mine imports.

The only things in there besides the JAR are source and javadocs, and it seems fairly unlikely that your code has a dependency on those (unless you're doing something really weird).

Are you sure you're including the current version of the JAR in your package?

[PLUCKYHD]

Originally Posted by GKusnick

The only things in there besides the JAR are source and javadocs, and it seems fairly unlikely that your code has a dependency on those (unless you're doing something really weird).

Are you sure you're including the current version of the JAR in your package?

Shoot me a pm if you don't mind with your email and I will send you the zip if u don't mind and make sure I am doing it right

[PLUCKYHD]

Greg,

Could you explain to me what all these backref it keeps throwing in are?

[GKusnick]

Backrefs are references from outside your code to widgets within your code. So for instance if you insert a reference to your code into an existing menu, that will generate a backref at export time. They should be fixed up automatically at import time. If that's not happening, then either you did the export incorrectly (i.e. you didn't export all of your new code), or you imported it into a different version of the base STV that doesn't have a corresponding place to insert the reference.

If you do the import using the Import STVI command on the STVI menu in Studio, it should flag any errors of this sort.

[PLUCKYHD]

Originally Posted by GKusnick

Backrefs are references from outside your code to widgets within your code. So for instance if you insert a reference to your code into an existing menu, that will generate a backref at export time. They should be fixed up automatically at import time. If that's not happening, then either you did the export incorrectly (i.e. you didn't export all of your new code), or you imported it into a different version of the base STV that doesn't have a corresponding place to insert the reference.

If you do the import using the Import STVI command on the STVI menu in Studio, it should flag any errors of this sort.

I figured it out it was because I was deleting items and they would get moved outside the menu and backref would be placed was really screwing with me

[PLUCKYHD]

Greg how exactly do I right in a reference for an import that may not be existant during importing my import to make sure it will relink to that reference when that import is imported. I thought this was automatic but I guess I am wrong

[GKusnick]

If your STVI refers to widgets in another STVI, or inserts references to itself under widgets from another STVI, that other STVI must be imported first so the references have something to link up to. There's no provision for leaving some references unresolved and then magically linking them up later if STVIs are imported out of order.

[PLUCKYHD]

Originally Posted by GKusnick

If your STVI refers to widgets in another STVI, or inserts references to itself under widgets from another STVI, that other STVI must be imported first so the references have something to link up to. There's no provision for leaving some references unresolved and then magically linking them up later if STVIs are imported out of order.

okay thanks I thought there was and I was missing something

[PLUCKYHD]

Greg wanting to make sure I am understanding correctly

If I want to add something to a menu in the default STV the best way using your tools is to create my own menu item(with a name different) and link it to the original stv and make my menu item have the primary reference. Is this correct?

[GKusnick]

You should create a dummy menu (not just an item) and put all your new code (including menu items) under that new menu. If you want your new items to appear on existing menus, place secondary references to them under the existing menus, but keep the primary refs under your dummy menu.

The widget names shouldn't matter since it will use the widget's unique symbol to do the linking.

[Slugger]

Hey, GKusnick:

Any chance you can regenerate the API based on 6.5.17? More specifically, I'm really looking for the new SystemMessageAPI to get included so I can mod my Twitter plugin to actually tweet about some rather useful information. If you can't do it in the next few days just let me know and I'll probably fiddle around by calling the raw API calls instead. Though life is so much easier if you regenerate based on 6.5.17.

[GKusnick]

Originally Posted by Slugger

Any chance you can regenerate the API based on 6.5.17?

Done. Version 0.72 has been uploaded.

Note that I have not tested the SystemMessageAPI wrappers in any way other than to eyeball the generated code to see that the types got wrapped correctly.

There are also a few other new API methods that got wrapped in this version for the first time, mostly having to do with other recent beta features such as subtitles and metadata import.

Apart from regenning the wrappers, there are no other tool changes in this version.

[tmiranda]

Originally Posted by GKusnick

You should create a dummy menu (not just an item) and put all your new code (including menu items) under that new menu. If you want your new items to appear on existing menus, place secondary references to them under the existing menus, but keep the primary refs under your dummy menu.

The widget names shouldn't matter since it will use the widget's unique symbol to do the linking.

Greg,

Your tools are really good, thanks much.

Why is this the best way to add code vs. just putting it directly in the existing menus?

Also, what is the advantage of using your STVi generator vs. the "built in" STVi generator?

[GKusnick]

My generator does not do any comparison against the base STV. The only way it knows which widgets to export is for you to tell it, and the way you do that is by grouping all the exportable widgets (and only the exportable widgets) under one or more new menus. So if you want to use my generator, you must take that extra manual step of gathering your new code in a place where the generator can find it.

My generator is not meant to replace or be better than the built-in generator, because the built-in generator (and the widget UIDs on which it's based) did not exist when I wrote mine. If you find the built-in generator easier to understand and use, by all means use it. It does have the advantage of being able to find newly created widgets wherever they may live in the widget tree, without having to manually group them under a dummy menu. On the other hand, it's not very smart about newly created hooks and listeners, and will happily create duplicate hooks if two or more STVIs each call for their creation. (Whereas my generator tries to be smart about that and share newly created hooks and listeners where possible.)