Studio frustration

[perry59]

Maybe its just me, but it seems that trying to do anything usefull with studio is extremely difficult. I do have some programming experience in other languages but java and sage are new to me.
For example; in my first stv project, the main menu is to be a "semi" dynamic one. By that I mean that I will have a "dummy" menu which just contains some item (button) widgets. The true main menu is to is to populate itself with these items. At first I tried a panel but that just didnt work out so now I'm trying to do this with a table. So, I plopped a table into my main menu, I want to feed it the items in the dummy menu. I look at the studio tutorials and they are so simplistic they arent much use beyond creating the "push me" button. Looking at the tutorial for tables I see two tiny examples of creating a table by feeding it the output of an api call, not what I need, but I assume you need to input an array of objects to a table (not array of strings?). I figure I can loop through the contents of my dummy menu and pass each item widget to my table. Then I realize I've seen nothing for "for loops". Andy was kind enough to remind me that I can loop through things, I just wont see constructs such as "for, do, do-while" etc.
At this point I'm thinking, well, maybe a loop isnt the best way to do this anyway so I start looking at the API. In there I find the function "GetWidgetChildren" and I think this sounds like just the ticket, after all, I want all the children of this dummy menu and a menu IS a widget. Unfortunately, like the tutorials, the api doc is pretty sparse too. Not a lot of help. It looks like "GetWidgetChildren" returns an array of objects (or strings? just what does it return?) So I figure I gotta plug this guy into my table, telling it to get the children of dummy sage user, er dummy menu. I see also that this function expects a widget as its input parameter, so I give the name of the dummy menu. Doesnt seem to work. I click on my action widget and select "evaluate" and it returns null. Ok, so I guess simply passing the menu name to GetWidgetChildren doesnt cut it, it needs an object or some other kind of reference to the menu?
Looking at all the docs doesnt give me much to go on here so I start looking for code examples. All I got really is the default .stv so I do a search in it for "GetWidgetChildren" and see there are no call to that function anywhere to be found. Great. So I do a search for ANY api call that expects a "widget" as an input parameter, dont find any of those either, wonderful. Do a forum search, cant find anything there either (for GetWidgetChildren).
Frustration getting much worse now...
So I start looking through the default stv for some other examples of setting up tables, even if they are all using stock api calls.
Lots of tables in the default stv, but really seeing how they are set up is like looking for the proverbial needle in the haystack.
Being able to reference other code chunks within the stv is a nice option, but I think its has gone way too far.
Just my opinion, but the default stv, to me, looks like the goto statement from hell.
Frustration mounts...
At this point, doing plugins for MediaPortal is looking easy.
I think it would be a GREAT help if the tutorial docs where beefed up a bit, with some more in depth examples. The api docs should at least have one example of how functions should be called and what the return (an array of string, array of objects, a ham on rye?)
Having a nice, indexed, repository of code examples somewhere on this side would be great too.
What Im trying to do should not be very difficult, but I've spent quite a bit of time on it and STILL dont have even the first menu of an stv done yet!
Is anyone else being buggered by any of these issues???

By the way, I am NOT trying to rag on the sage devs or anyone else. I realize that documentation is one of the least liked areas of software development. We produce software where I work and our tech writer is definately a full time job!

[GKusnick]

The Studio learning curve is fairly steep. Prior programming experience helps, but the Studio programming model (how code is structured and how it executes) is pretty different from typical programming languages, and takes some getting used to.

Maybe it would help if you said what other languages you're familiar with, so we can calibrate our answers properly. One of the concepts you seem to be having trouble with is the concept of data types and object classes (trying to pass Strings where Widgets are expected and so on). If you haven't worked in a strongly typed language before, that's one more concept you're going to have to learn before things start to make sense.

I addressed your table issue briefly in another thread, but basically you're going about it entirely the wrong way. You don't create menus in Sage by patching widgets together on the fly at runtime. You assemble them statically in Studio at design time. That's why you're not finding any WidgetAPI calls in the stock STV. For tabular menus, create arrays or lists of data and feed them to Table widgets, and let the Tables do the work of replicating widget instances as needed at runtime; that's what they're meant for.

I completely agree that widget references in the stock STV are out of control (no offense, Andy) and seriously impair the readability of the code. To my mind this completely unconstrained use of "goto"-style control constructs, with no structured alternatives (loops, subroutine calls, etc.) is the single biggest design flaw of the Studio widget language. All I can suggest is to slog through the stock code as best you can, making heavy use of Set As Primary Reference to try to straighten out the control flow (not that it will stay that way), and to try to discipline yourself to avoid that kind of goto-overkill in your own code.

The rule I try to use when I want to share a block of widget code is to put a comment of the form "SUB: purpose (args)" at the top of the block, and reference that comment from the various points of use and also from a top-level "Subroutine organizer" widget. That way I can easily find resuable subroutines I've already created, and know what sort of arguments (context variables) they're expecting. Also the Normalize References command in my Studio Tools package is designed to pull primary references towards such top-level "organizer" widgets, which helps to control clutter elsewhere in the code.

I don't quite get your point about documenting the inputs and outputs of API calls. These are all clearly indicated in the API docs already. For instance, GetWidgetChildren is shown as accepting a sage.Widget and returning a sage.Widget[] (i.e. an array of sage.Widgets). So you must have an object of type sage.Widget in hand already to call that function (a String won't work), and what you get back is the Widgets representing the children. If you're wondering where to get a Widget in the first place, there are several functions that return Widgets without requiring a Widget as input (e.g. GetAllWidgets, GetCurrentMenuWidget). But again, the WidgetAPI is perhaps not the best example to use, since as mentioned above, you won't be calling those functions in normal STV code (although I use them extensively in my Studio Tools code).

If you're having trouble solving a particular UI problem, maybe you could describe what effect you're trying to achieve on screen, and we can then help you decide how best to achieve that effect. That way you're less likely to get frustrated by commiting prematurely to a particular implementation strategy (such as on-the-fly widget copying) that may not do what you want it to do.

[perry59]

First, thank you for your clear, concise and helpful posts!

Originally Posted by GKusnick

The Studio learning curve is fairly steep. Prior programming experience helps, but the Studio programming model (how code is structured and how it executes) is pretty different from typical programming languages, and takes some getting used to..

I think I will bold, highlight, italisize, enlarge 4x and tape this to my desk!

Originally Posted by GKusnick

Maybe it would help if you said what other languages you're familiar with, so we can calibrate our answers properly. One of the concepts you seem to be having trouble with is the concept of data types and object classes (trying to pass Strings where Widgets are expected and so on). If you haven't worked in a strongly typed language before, that's one more concept you're going to have to learn before things start to make sense.

Most recently, I've been doing a fair amount of C#.
I am familiar with data types and objects (OOP) and, in the api it certainly looks like GetWidgetChildren expects an object be given it, and returns an array of objects. But in some of the lines of code I've looked at (sorry, I cant give an example) it almost looks as if something else is being passed and returned. I'll just take the api docs verbatim and disregard any perceptions I may get from others code.

Originally Posted by GKusnick

I addressed your table issue briefly in another thread, but basically you're going about it entirely the wrong way. You don't create menus in Sage by patching widgets together on the fly at runtime. You assemble them statically in Studio at design time. That's why you're not finding any WidgetAPI calls in the stock STV. For tabular menus, create arrays or lists of data and feed them to Table widgets, and let the Tables do the work of replicating widget instances as needed at runtime; that's what they're meant for.

Seen that, thanks. And yes, I thought it would be better to construct widgets dynamically and pass them to the table. The reason I did'nt is because I am trying to create a container if you will, a "dummy menu" where I or anyone in the future could simply add (or copy an existing) item widget; or delete one for that matter, and this change would be reflected in the main menu. I know this goes against the grain of established practices. The lack of widget calls in the default stv of course does indeed solidify the idea that if widgets are to be created, they are done so in a more dynamic fashion.

Originally Posted by GKusnick

I completely agree that widget references in the stock STV are out of control (no offense, Andy) and seriously impair the readability of the code. To my mind this completely unconstrained use of "goto"-style control constructs, with no structured alternatives (loops, subroutine calls, etc.) is the single biggest design flaw of the Studio widget language. All I can suggest is to slog through the stock code as best you can, making heavy use of Set As Primary Reference to try to straighten out the control flow (not that it will stay that way), and to try to discipline yourself to avoid that kind of goto-overkill in your own code.

'Nuff said

Originally Posted by GKusnick

The rule I try to use when I want to share a block of widget code is to put a comment of the form "SUB: purpose (args)" at the top of the block, and reference that comment from the various points of use and also from a top-level "Subroutine organizer" widget. That way I can easily find resuable subroutines I've already created, and know what sort of arguments (context variables) they're expecting. Also the Normalize References command in my Studio Tools package is designed to pull primary references towards such top-level "organizer" widgets, which helps to control clutter elsewhere in the code.

Excellent!
I must get much more familiar with your tools

Originally Posted by GKusnick

If you're having trouble solving a particular UI problem, maybe you could describe what effect you're trying to achieve on screen, and we can then help you decide how best to achieve that effect. That way you're less likely to get frustrated by commiting prematurely to a particular implementation strategy (such as on-the-fly widget copying) that may not do what you want it to do.

Again, Thanks!

What I am trying to accomplish, seems simple enough (hence my frustration at not getting it done!)

I want to have a dummy (named in honor of its creator) menu which contains a number of widgets representing buttons. In a real menu I wish to have a table whos job is to place a copy of each of the buttons contained in the dummy menu into itself, as a single column, as many rows as required to accomodate. A vertical table obviously, which scrolls and wraps.
In this way, it would be extremely easy for me or any casual studio user to simply add/copy or subtract items from the dummy menu and they would be added or subracted to the "real" menu table.
Adding a new button to the main menu would simply be a mater of making a copy of one of the widgets in the dummy menu and changing the names of its menu label, image and highlight image.
I suppose this could be done dynamically, but I would have to take a far different approach to make it easy for a user to delete an existing button or add one by merely indicating the button images, etc.

Perhaps this is just a foolish idea altogether and I should abandon it in favor of dynamically creating a set number of buttons for the table. Or have to create something as complex as the dynamic menu I've seen elsewhere.

[Opus4]

Originally Posted by GKusnick

I completely agree that widget references in the stock STV are out of control (no offense, Andy) and seriously impair the readability of the code.

I've only got time to comment on this one part... a lot of references should have a REM statement saying what the referenced code does, though I'm sure they don't all have such a comment. But, if there are several places that need to do the same thing, I consider those references to essentially be subroutines that I can call a single time instead of having to replicate the same exact code in many places & then have to search for them all when I need to change what should be a single piece of code. It makes my job easier when it comes to maintenance & sure makes readbility and bug fixing easier for me too when I don't have to rememeber that the same piece of code is copied all over. So, I sure do consolidate code when I can via references.

(Of course, there are some widgets series that can't be referenced, so there are copied code sections too when that solution is needed.)

- Andy

[GKusnick]

Originally Posted by perry59

What I am trying to accomplish, seems simple enough (hence my frustration at not getting it done!)

I want to have a dummy (named in honor of its creator) menu which contains a number of widgets representing buttons. In a real menu I wish to have a table whos job is to place a copy of each of the buttons contained in the dummy menu into itself, as a single column, as many rows as required to accomodate. A vertical table obviously, which scrolls and wraps.
In this way, it would be extremely easy for me or any casual studio user to simply add/copy or subtract items from the dummy menu and they would be added or subracted to the "real" menu table.
Adding a new button to the main menu would simply be a mater of making a copy of one of the widgets in the dummy menu and changing the names of its menu label, image and highlight image.
I suppose this could be done dynamically, but I would have to take a far different approach to make it easy for a user to delete an existing button or add one by merely indicating the button images, etc.

But this is still just a description of how you're trying to implement whatever it is you want to see on screen. What I'm suggesting is that we ignore the implementation for now and start the design process with the end-user experience. What do you want your menu to look like to the user, what sort of items will it have on it, and how should it behave when those items are activated? Once we have that specified, we can talk about ways to implement it.

Or are you saying you're trying to create a reusable menu toolkit for STV developers? That might be a worthwhile goal, but if you have yet to create a single working menu, then it's way too soon for you to be thinking about how to abtract menu creation into a toolkit. Master the existing tools before trying to invent new ones.

[stanger89]

First I'll start with saying if you want to look at some "simple" generic menu code you might want to look at this:
http://forums.sage.tv/forums/downloa...?do=file&id=47

It was from some experimenting of mine quite a while ago.

Originally Posted by perry59

I want to have a dummy (named in honor of its creator) menu which contains a number of widgets representing buttons. In a real menu I wish to have a table whos job is to place a copy of each of the buttons contained in the dummy menu into itself, as a single column, as many rows as required to accomodate. A vertical table obviously, which scrolls and wraps.

I'm not quite sure I understand what you're trying to do, I see two ways it can go:

1) You want to have a generic menu "look", and you want to easilly be able to add/remove items from that menu.

or

2) You want to have a certain layout, and have Sage automatically populate it from some list/option.

These two alternatives have very different approaches.

1) To do this, just look at the main menu in the stock STV. It's uses a Theme to define the layout and look of the menu. Then you just add Item widgets to create buttons.

2) Here you create a list and pass it into a table widget (with themed tablecompents) and let sage automatically build the table.

In this way, it would be extremely easy for me or any casual studio user to simply add/copy or subtract items from the dummy menu and they would be added or subracted to the "real" menu table.

Guess I'm not sure of the distinction between "dummy" and "real" menus.

Adding a new button to the main menu would simply be a mater of making a copy of one of the widgets in the dummy menu and changing the names of its menu label, image and highlight image.

In the stock STV, all you do to add a button is create a new Item widget (I really hope I'm using the right widget name ), place it in the main menu container, change the name, and link it to where you want it to go.

Perhaps this is just a foolish idea altogether and I should abandon it in favor of dynamically creating a set number of buttons for the table. Or have to create something as complex as the dynamic menu I've seen elsewhere.

How about this, maybe try posting a concrete example of exactly what you want to do ("I want to add this to that, by specifying a, b, c" but with real names), I know I'm having a tough time interpreting your general terms the way I think you mean them.

[GKusnick]

Originally Posted by Opus4

But, if there are several places that need to do the same thing, I consider those references to essentially be subroutines that I can call a single time instead of having to replicate the same exact code in many places & then have to search for them all when I need to change what should be a single piece of code.

Absolutely. I didn't mean to imply that you should copy code instead of sharing it. What I'm saying is that code sharing requires discipline. In modern programming languages (i.e. those invented since the late 1960s), code sharing is accomplished by formal function declarations with formal parameter lists and return types, so that all input/output dependencies are made explicit, and variables in the calling context are hidden from the subroutine code.

What we have in Studio is a throwback to the '50s, in which code sharing is accomplished by gotos, explicit parameter declarations are absent, and subroutine code is free to reach up into the caller's context and mess about with its variables. These are the issues that impair readability, and are precisely why the more modern form of function declaration was invented.

And just to be clear, I'm not attacking you for coding in this archaic style. You're just using the tools available as best you can. What I'm attacking is the primitive state of the tools themselves.

[Opus4]

Originally Posted by GKusnick

And just to be clear, I'm not attacking you for coding in this archaic style. You're just using the tools available as best you can. What I'm attacking is the primitive state of the tools themselves.

I know -- I didn't take it as an attack. I just figured it needed a comment about why references are used in many places, since some people might think references should be avoided. I think we are both doing somewhat similar things in terms of trying to put a REM or SUB comment above some of that reused code to make it more easily understood, though I don't document every variable for each commented reference... in fact, a list of which variables are sent/modified is kind of rare.

As a reminder for starting out in Studio: you can't really reference code sections in a UI chain because all the code has to lead up to the UI element... unless, of course, the exact UI element is what you want to reuse anyway.

And, yes, it took me quite a while to become proficient in Studio. The curve is still steep with the manual, but it was even steeper for those who used it before the manual came along.

- Andy

[perry59]

Originally Posted by GKusnick

What I'm suggesting is that we ignore the implementation for now and start the design process with the end-user experience. What do you want your menu to look like to the user, what sort of items will it have on it, and how should it behave when those items are activated? Once we have that specified, we can talk about ways to implement it..

Ok, what the user would see would be a tall, narrow single columm of image buttons, say 4 or 5 rows. Clicking an image would simply lead to another menu, say, "My pictures" etc. if the bottom most image were selected the user could use the down key to scroll to items that were previously out of site. the last image button would then wrap to the top. Thats it. Sounds simple no?

Originally Posted by GKusnick

Or are you saying you're trying to create a reusable menu toolkit for STV developers?

I hadnt considered that, but if I do get it working nicely it should also be very easy to export it for use by others.

[perry59]

Originally Posted by stanger89

First I'll start with saying if you want to look at some "simple" generic menu code you might want to look at this:
http://forums.sage.tv/forums/downloa...?do=file&id=47

Thanks stanger! that actually looks pretty neat. Dont think I'll be able to dig into it tonight I'm really beat. Insomnia problems.
Have you abandoned this project?

Oh, and by dummy menu I simply meant using a menu as a container for items which are to be buttons on a "real" menu. this dummy menu would not be accessible via regular navigation in sage.

[cncb]

I am a seasoned programmer but still having quite a hard time figuring out Studio. It seems that several chains just stop (without references or anything else that I can see) so I don't even see where the actual code that gets executed is.

For example, I was trying to find the widget/code used for the "Watch Now" item in the recordings option menu. I am able to trace it to the "Basic Options Panel" under the "Video Library Folder View". Now when I expand the "Watch Now" item and follow the chain there is only one action under that is just a comment? Where and how is the action performed to play the recording when this item is selected?? Maybe if someone can explain this example to me everything else will start to make more sense. Thanks.

[MeInMaui]

Originally Posted by cncb

I am a seasoned programmer but still having quite a hard time figuring out Studio. It seems that several chains just stop (without references or anything else that I can see) so I don't even see where the actual code that gets executed is.

For example, I was trying to find the widget/code used for the "Watch Now" item in the recordings option menu. I am able to trace it to the "Basic Options Panel" under the "Video Library Folder View". Now when I expand the "Watch Now" item and follow the chain there is only one action under that is just a comment? Where and how is the action performed to play the recording when this item is selected?? Maybe if someone can explain this example to me everything else will start to make more sense. Thanks.

That is a (secondary) code reference. Right click it and set it as the primary reference. I definitely recommend reading the Studio manual before doing anything.

Aloha,
Mike

[Opus4]

Originally Posted by cncb

It seems that several chains just stop (without references or anything else that I can see)

Based on your further comments in the quote below, I don't think you understand what a reference is in Studio. See p. 13 of the v6.2 Studio manual.

For example, I was trying to find the widget/code used for the "Watch Now" item in the recordings option menu. I am able to trace it to the "Basic Options Panel" under the "Video Library Folder View". Now when I expand the "Watch Now" item and follow the chain there is only one action under that is just a comment?

That single italicized action widget is a reference -- see the manual page I referred to above to understand references better.

- Andy

[GKusnick]

Originally Posted by MeInMaui

That is a (secondary) code reference. Right click it and set it as the primary reference.

Or just double-click an italicized secondary reference to jump to the corresponding primary reference. Or right-click and choose Highlight References. Or, if you use my Studio Tools, right-click and choose GK Tools > List Widget References.

[evilpenguin]

Originally Posted by MeInMaui

That is a (secondary) code reference. Right click it and set it as the primary reference. I definitely recommend reading the Studio manual before doing anything.

Aloha,
Mike

And don't just read it, code along with it. It *really* makes everything soooo much easier.

[cncb]

Oh, I see. I understand references but for some reason it didn't occur to me that the "comment" is the reference . I'm not sure why but it is clear to me now. Thanks all.

[perry59]

Sorry I had not responded to the later posts here. Been a bit busy & having serious insomnia issues.

Anyway, first I want to apologize for allowing my confusion & frustration to seep into the forums, and say thanks to all you for trying to help. I'm sure I could have done a better job of trying to explain myself.

That being said, I was about to post a couple screen shots to better explain my problem when I did something I should have done in the beginning. I actually thought about what I was trying to do, and its end result. I then realized it was a dumb idea altogether, just barking up the wrong tree. So I have abandoned this quest. Even if I had created a nice custom image button menu that a user could easily add or subract menu items from, the user would still have to tie those items to other menus/functions. Something a casual user would not want to do. That realazation alone suggested the whole thing was a bad idea.
I am still creating a custom image button menu, but in a much more conventional form, creating the buttons dynamically (more or less) from within the table cell object and feeding the table with a simple array of strings to be used as labels. It is working much better now. Still having an issue with linking the buttons to their respective menus but hopefully will solve this soon. This means more "slogging" though the default stv looking for something similar (more headaches on the way). If Im still stuck after a day or two I'll post a question on it, with a picture of my table code which should be easy for the guru's here to see what Im getting at.
I still find it difficult to use the default stv as a learning tool. In my endeavors to learn C# I found a vast wealth of code snippets on line that I could print out and study from the comfort of my recliner. This is just not practicle with sage. Just printing out a single menu page may require 50 sheets of paper (landscaped) with extremely deeply indented code that still bounces all over the place and references to code in an entirely different area of the file.
Again, not trying to blast the developers, just wish it could be structured more like what I'm used to.
Thanks again all, hope you have a great Thanksgiving (for all you yankees )

[stanger89]

You have seen Nielm's dynamic menu addon right?

[GKusnick]

If it were me learning Studio for the first time, I'd start by mocking up a non-configurable working model of my menu, with statically defined items linking statically to various submenus. That way I could focus on mastering the widget mechanics and getting the onscreen look-and-feel right without the added complication of configurability. Once I had that much working satisfactorily, then presumably it would be clearer what the items had in common and which parts needed to be abstracted out to make it configurable.