Studio/API wishlist

[GKusnick]

Here's a short list of features I'd like to see added to Studio and the SageTV API. In no particular order:

• GetCurrentWidget() -- Called from an Action or Conditional widget, this would return a handle to the calling widget. Called from Java, it would return the widget containing the Java call.

• GetSTVDirtyStatus(), SetSTVDirtyStatus(boolean) -- Get would return a boolean indicating whether the loaded STV has been edited and needs to be saved. Set would accept a boolean and mark the STV dirty or clean. This would give code that makes temporary widget changes a way to save and restore the dirty status and thereby avoid spurious "Save changes?" prompts on exiting Sage.

• Expand All Nodes -- Please put some kind of confirmation on this. Grab this by mistake when reaching for Expand Children, and you might as well go for coffee while it thinks.

• Set as Primary Reference -- Sure would be nice if this would persist across save/reload, so that widget code would stay where you put it instead of migrating all over the place at the drop of a hat. Yes, I know that from a functional standpoint it doesn't matter where the primary reference lives. But from a readability and code cleanliness standpoint I think it does matter.
  
  If that's not feasible, an acceptable alternative might be to add a "Show at top level" checkbox to the Action widget property editor. If checked, this would force Studio to display the widget always at the top level of the widget tree, like menus, regardless of how many references it has. You could then use top-level Action widgets as comments to pin your widget subroutines to one spot in the widget tree.
  
  Yet another alternative might be to introduce a new widget type called Subroutine specifically for this purpose. In this case there'd be no "Show at top level" checkbox; Subroutine widgets would always show at top level, just like menus. The name of a Subroutine widget would be treated as a comment, and the widget would otherwise function just like a noop Action widget.
  
  Something along these lines would at least give us the option of coding in a relatively clean style, with well-defined chunks of shared code that stay where we put them, instead of the spaghetti-code free-for-all of floating references one finds in the standard STV.

[jbuszkie]

Not sure where to post this so I'll just add to this thread...

I'd really like to see studio have a recent file list!

It's such a pain to edit the import, load the default stv, import.. then go back and edit the import again.

Jim

[alon24]

How about CTRL-S for saving????

[BobPhoenix]

How about just remembering the name of the file when the extension is STVi instead of dropping the name and only listing the XML's!

[GKusnick]

Since this thread has been resurrected, I'll add a few more wishlist items:

• Persistent primary references. As things stand, when you save an STV file, the definition for a shared widget gets written out at the point of the first reference (not the primary reference). When you read it back in, references are stored in LIFO order, so the last reference becomes the primary reference, effectively scrambling whatever reference structure you may have created in Studio using Set as Primary Reference. This is just wrong.
  
  What should happen is that when writing the file, the widget definition should get written out at the point of the primary reference (not the first reference). When reading it back in, a non-primary reference should be added to the tail of the reference list, and the primary reference (the one with the actual widget definition) should be added to the head of the reference list. This would preserve the reference structure created by the user in Studio and make managing shared code a whole lot easier.
  
  I see I'm repeating myself on this one, but this has been on my pet peeve list for a long time, and (as outlined above) it doesn't seem like it would be that hard to fix.

• Unique, permanent widget IDs. Each widget, when created, should be assigned a globally unique ID (like a Win32 GUID) that remains an unchangeable part of that widget's properties forever. These IDs should be written out when the STV file is saved and read back in when the file is reloaded, and should remain invariant across product releases, so that (for instance) the ID on theme X in SageTV version 6 should be the same as it was in version 5. To go with this, there should be a lookup API that, given a valid ID, returns the corresponding widget.
  
  The point of this is so that STVI code doesn't have traverse complex paths through the widget tree to find the themes, menus, and items it wants to manipulate. They should all have unique, unchanging IDs that we can just hard-code into our STVI logic in order to address those widgets directly. This would make STVIs much easier to code and much more portable from version to version or from skin to skin.

• API methods for accessing variable contexts and attribute values. As things stand, a Java function can call AddStaticContext or AddGlobalContext to create variables, but it cannot read back the values of the variables it creates. Also, there's no way for Java code to access the current values of Attribute variables. I'd like to see this fixed so that Java code can have full access to variable contexts (i.e. declaring, setting, and reading variables) on par with widget code.

• Some sort of plugin interface for Studio so we can extend Studio's command set with our own Java code for searching and modifying the widget tree. This would involve three components: (1) a Java interface for registering Studio commands, (2) a set of API calls for getting/setting Studio state such as selection info and clean/dirty status, and (3) a way to signal Studio that widget properties have changed and need to be refreshed in the Studio window.

[jbuszkie]

I'll add another one.... Jeff... Are you watching this thread??

I'd like to see a stand alone Studio Viewer/editor. It doesn't have to link to any sage window or have any debug capabilities... But as long as I can view/add/change/save that would be great. And.. also if you can have several copies open at one time!

This would solve a bunch of my headaches. I'm tired of
screen capturing a section of code and then printing so I can see what's there why I'm editing my STVI!

I know this would be a little more involved... but I'll bet it would make a bunch of us REALLYhappy!

[GKusnick]

Actually that one's pretty easy. Since the STV is just an XML file, you can use whatever tools you like to edit the XML directly, or build your own offline STV editor that reads and writes XML files and has a Studio-like GUI. So I don't see that as a crucial part of the next Studio upgrade, since it can be done independently by third-party devs.

[jbuszkie]

Originally Posted by GKusnick

Actually that one's pretty easy. Since the STV is just an XML file, you can use whatever tools you like to edit the XML directly, or build your own offline STV editor that reads and writes XML files and has a Studio-like GUI. So I don't see that as a crucial part of the next Studio upgrade, since it can be done independently by third-party devs.

Like I have the time or energy to do that! I figured it would be pretty easy for them to rip out code vs me trying to write an xml stv viewer!

[alon24]

Originally Posted by jbuszkie

I'll add another one.... Jeff... Are you watching this thread??

I'd like to see a stand alone Studio Viewer/editor. It doesn't have to link to any sage window or have any debug capabilities... But as long as I can view/add/change/save that would be great. And.. also if you can have several copies open at one time!

This would solve a bunch of my headaches. I'm tired of
screen capturing a section of code and then printing so I can see what's there why I'm editing my STVI!

I know this would be a little more involved... but I'll bet it would make a bunch of us REALLYhappy!

Actually what I do is export the part (or whole menu) to XML, go to my import, and Import the XML I just exported.

Then I just copy the parts I need, and delete all the rest.

Take the lazy way, don't use Screen caps.

[jbuszkie]

Originally Posted by alon24

Actually what I do is export the part (or whole menu) to XML, go to my import, and Import the XML I just exported.

Then I just copy the parts I need, and delete all the rest.

Take the lazy way, don't use Screen caps.

I do export the menus... but that only works for base code for the import... When I'm tyring to figure out where I need to link stuff in or where to delete, It's so much nicer to be able to put it side-by-side!

Jim "but now we're getting off topic..."

[alon24]

Just one more thing about this.

I export the full menu (also where it should go) into the STVi, and then work off that.