GBPVR Widget Library

[jasonf]

I'm putting together a library of widgets (data structures, controls that will render to the screen, etc) to at least help me to refactor some of my code, and to make future development a little easier.

I'm wondering what the interest level would be among plugin developers to have a common library of reusable components. I mean, it's easy enough to just copy and paste code from one plugin into another, but the result tends to be a little messy.

When I say "control", I mean a component that is very much like Windows form controls. The developer can set properties that effect the rendered output without necessarily worrying about how the details of the control is implemented.

For instance, a Frame control would have certain properties (size and position, border style, color, etc), and when told to render, would draw a frame on the screen. This alone is not much different than sub's DrawRoundRect() method, except that a Frame control might be able to draw both a square and a rounded rectangle, selectable by a setting of the current skin. The plugin designer would just need to create a Frame object, set properties, then tell the Frame to render when it needs to. In addition, maybe the Frame is a container control (a control that contains other controls).

If there is interest, and others would like to contribute to the library, then perhaps I'll set up a SourceForge project for it to enable the proper collaboration (and to facilitate public access to the latest codebase).

[jorm]

I think that would be a great idea.

We can do list boxes, keyboard interfaces, text areas etc...

[sub]

Sounds cool, but just so you're aware - when it comes to graphical stuff, you'll probably want to use the skinhelper where possible. I realise it doesn't cover everything you need to do, but its quite flexible, and allows the users to change the look and feel of the skins by themselves. It allows you to describe an image, draw images, draw rounded rect.

I've been going back and removing all the calls to DrawRoundRect() etc in my code, and instead doing a skinHelper.getNamedImage("Background&quot that is described in skin.xml as:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
<CompositeImage name="Background" size="720,480">
<DrawImage filename="..\background.jpg" loc="0,0" size="720,480"/>
<DrawRoundedRect loc="150,35" size="520,413" radius="5" borderWidth="4" borderColor="LightGray" fillColor="Black"/>
<DrawText text="FM Radio" loc="5,5" size="160,120" textStyle="ScreenName" align="Left"/>
</CompositeImage>
[/QUOTE]

Doing it this way gives the end user and creative types, much more control.

So use this sort of approach within you widgets if you can.

[Huw]

Quote[/b] (sub @ Nov. 18 2004,16:17)]Sounds cool, but just so you're aware - when it comes to graphical stuff, you'll probably want to use the skinhelper where possible. I realise it doesn't cover everything you need to do, but its quite flexible, and allows the users to change the look and feel of the skins by themselves. It allows you to describe an image, draw images, draw rounded rect.

I've been going back and removing all the calls to DrawRoundRect() etc in my code, and instead doing a skinHelper.getNamedImage(&quot;Background&quot that is described in skin.xml as:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
<CompositeImage name="Background" size="720,480">
<DrawImage filename="..\background.jpg" loc="0,0" size="720,480"/>
<DrawRoundedRect loc="150,35" size="520,413" radius="5" borderWidth="4" borderColor="LightGray" fillColor="Black"/>
<DrawText text="FM Radio" loc="5,5" size="160,120" textStyle="ScreenName" align="Left"/>
</CompositeImage>

Doing it this way gives the end user and creative types, much more control.

So use this sort of approach within you widgets if you can.[/QUOTE]
sub, doing it this way, how can you control where your image is drawn using the Skin ?

there is no loc for the composite image tag only a size
&lt;CompositeImage name=&quot;Background&quot; size=&quot;720,480&quot;&gt;

[sub]

Where the images draw is usually up to application logic. The composite image is just the definition of an image. It does not specify where or when that image will be used.

In the case of my &quot;background&quot; named image example, the plugin calls skinHelper.getNamedImage(&quot;Background&quot then draws the resulting image to fill the screen image graphics object. The one was fairly obvious, so no location info required.

I do quite often use a SpecialElement tag to define the general location of elements on the screen, but I think this is starting to get into the plugin specific things which dont need to be as generic.

The main menu is a good example. I use the same CompositeImage of the buttons over and over. The location is specific to the main menu application logic, but by enabling the user to change the look and feel of the button in skin.xml, they can make it look quite different.

[Huw]

Quote[/b] ]I do quite often use a SpecialElement tag to define the general location of elements on the screen, but I think this is starting to get into the plugin specific things which dont need to be as generic.

Ok, that is also what I was doing, but my code seems to be broken with the current version, should get chance to give it a thourough debg tonight and find out exactly where it is broken

[goosey]

Poor Sub - has got skin designers pulling (in my case - whining) from one end, and developers pulling from the other....

Anyway, please please please developers, try to make it possible for the skin designer to control as much of the design and layout as possible, including locations, sizes, fonts, use of images etc.

I can't see why the plugins would need to define locations, size, or fonts at all (except perhaps for the video/tv window display). I would presume that the plugin could read the skin to find out where everything is?

I hope this makes sense, and that I am not showing my ignorance of the underlying code.

[Huw]

sometimes it is necesary to dictate size and therefore location of what is being displayed, admittedly not allways, but there is no point in us outputting some text if the user changes the skin so that it no longer fits correctly.

Having said that, wherever possible I am making my layout work entirely from the skin settings with as few hard coded sizes/locations as possible (if any at all)

[jasonf]

Quote[/b] ]Anyway, please please please developers, try to make it possible for the skin designer to control as much of the design and layout as possible, including locations, sizes, fonts, use of images etc.

I'm for that.  My only complaint with the current method of skinning is that there's no way to establish default plugin skins.  

Take my Solitaire plugin, for example.  If a new skin is designed that doesn't have the Solitaire directory containing the skin.xml file, then the plugin breaks when GBPVR uses that skin.  

By &quot;default plugin skins&quot;, I simply mean that if the current skin doesn't have the necessary information for a plugin, then I would want GBPVR to fail over to a default location (like Blue, for instance).  In this way, plugin designers only need to create one skin (the default) to distribute.  Skin designers would only need to modify that default skin if they needed to change it--otherwise, they don't have to worry about maintaining it.

Quote[/b] ]I can't see why the plugins would need to define locations, size, or fonts at all (except perhaps for the video/tv window display).  I would presume that the plugin could read the skin to find out where everything is?

Just keep in mind that some things, like navigation (i.e., what happens when one area has focus and then the right arrow key is pressed) has hardcoded behavior in the plugin. So, if a skin designer repositions elements, then navigation could appear to be broken to the user.

The point here is that skin designers can't just make any arbitrary change and expect the plugin to automagically work with the new settings, but this would be quite apparent as the skinner performs testing.

[KingArgyle]

I for one like the idea of a set of widgets, as it opens up several possibilities for tools besides just plugins for GBPVR. Imagine a Graphical Skin Designer that was truely a drag and drop type program. The only HTPC software that I know comes close to this functionality is XLobby, and even it needs some work. Meedio's theme designer really sucks.

Ideally, you want as much seperation of the UI from the actual Application code as possible. Personally, I fee that screen position, layout, size, etc. should be controlled with in the skin file itself. All application related data that needs to be populated on the skin should reference those objects, but not control the actual layout. This gives the ability for the plugin developer to concentrate on the data aspect of the application, instead of worrying about how it looks, and also gives the skin developer the flexibility to easily customize the looks of the UI without really having to know how that data is getting to the system. They still have to be aware of what it is going to look like, but they aren't concerned with where the data is coming from, only that it's there when they need it.

Just my two cents on the topic. From what sub has said in other posts, I would suspect this would be a pretty big redesign effort, but in the long run might be a worthwhile one as it opens up a great many things that can be done with the skins and themes, as well as the plugins.