[VictorV]

Just me that find GUI addon development unnecessary hard and boring? Have I missed something invaluable?

I have played around with some addon concept lately.
Python makes addon development fun and easy, but I never bother create a release since creating a gui is so much boring and repeating coding.. Even a simple panel with some text and buttons needs knowledge to skin naming convention, or using custom graphic, mark up and position elements. And then there are diffferent display modes and a wide variety of skins that won't match your skinning if you don't create a uniqe design for it.

The basic dialogs that can be used from python are great, but comes short in more advanced addons. I was wondering how people handles their GUI development. Some tips and tricks you want share? Some reusable code to ease development?

I've been thinking of creating a generic addon project template that contains a common structure for building a gui addon. With a collection of commonly used functions and skinning xml. Making the typical addon code be maintained externally from the individual addon code.

I've also thought about a section in the skin describing a set of basic GUI elements. Like Windows, dialogs, buttons, radio buttons, text boxes etc. in the same style as the skin. Those component could be used in python for dynamic GUIs and in skin files to let the addon developer handle only the necessary properties of the user interface. With a common naming convention this would ease the development of GUI across skins.

A basic GUI library for python in XBMC and a common codebase would increase the quality of addons. It would make it faster and more fun to develop addons, and we would probably see more addons for XBMC. It would be easier to take over or join the development of addons with the same structure.

This can't be done by one person, and would only be possible if developers is positive and contributed to such a initiative. Some experienced developers to manage, delegate and approve. People willing to create good guidelines and tutorials for addon development, people willing to contribute their code to the public domain

Got a bit messy since there where no buffer or filters between my brain and keyboard today.

Sorry if you think my english is so perfect, but hope to make me understood. What do YOU think?

[Bstrdsmkr]

Unfortunately, there is no easy way to deal with all those different screen types and skins. When you create a custom GUI, you're doing just that, deviating from the standard.

The best thing you could do is detail the information skinners need in order to add your custom window to their skin and hope they're willing to do the work for you.

Now a standard naming convention is a good idea in theory, but as they say "The great thing about standards is there are so many to choose from!"

It would be great if you could pre-define a name and convention for every possible combination of GUI elements, but that just isn't going to happen.

[VictorV]

I see there are challenges and if it was easy it probably would have been done already.
The thing is that I can not see this development pattern as solution for the future. If one want more great addons from new and old developers think ther's a need for a structure that makes simpler development of quality addons.

As for the namng convention I would not interfere to much of the inner working of a skin, but rather require a file with markup for a basic set of components that match the skin. This basic components can be used from within XBMC/python to build more advanced and dynamic layouts. Python support for gui elements would have to be extended in case of a python library handling this. Are some limitations creating quite simple GUI components requiring som kind of lists per now.
This would speed up development a lot, but I guess all can't be covered, so unusual cases might need to be made the old manual way anyways.
Only strip down skin.xml-files with all the gfx details would maybe make them readable. A custom dialog i a addon requires a shitload of markup lines describing the layout. Addons do not offer a way of reuse code, so the result is not very easy to keep track of. This also increase the risk for unseable errors in python code, since invalid skin markup won't trigger any errors. The developer also need to keep track of id's used in skin to ensure correct data references from python script.

In addition to the GUI I thought that it won't hurt to share some of the code used in addons as much common code already being found in many different addons. So maintaining such code as a community would make sense.

[jmarshall]

The problem is there is no common layout that works across all skins.

If there is some layout option that will be useful to a lot of add-ons, then those files could be provided by the skin, but we typically find that most add-on authors want something just a little bit different than the dialogs/window layouts that skins provide.

The bottom line is layout is handled by the skinner. What controls should be present is handled by the add-on author. The only way these two fit together is if there's restrictions on the former or latter, or it's unrestricted and a lot of code is required (usually there's not a whole heap needed, though this depends on how the skin is arranged with respect to re-use).

Come up with a decent system that most add-on authors + skinners will be happy with, and I'm sure it will be considered.

Cheers,
Jonathan

[VictorV]

I think the basic component required for such feature will be:
This would be a required section/part/file of each skin. Making the skinner skin a basic layout

* Window
* Dialog with close button
* button
* radiobutton
* spincontrol
* label/multiline label
* textbox/editbox
* listbox with scrollbars/buttons and defauklt listitems (maybe some different views?)
* Font, text color and text size for a heading, labels and editbox

these would probably just be references to includes used in the script. So this will be more or less a interface between xbmc and the components the induvidual skinner will reveal to the addons. XBMC can then make those defaults exposd to python through a extension library creating a a instance from defaults. One could then combine the components and create more advanced components as tabbed panels, directory listings etc. adding functionality as layout managers, auto pos. and auto size of dialogs, and easily add button and similar to wondows and dialogs as child components through a python interface

I think this would make a powerful and dynamic tool for making gui developent less boring

[VictorV]

The problem is there is no common layout that works across all skins.

If there is some layout option that will be useful to a lot of add-ons, then those files could be provided by the skin, but we typically find that most add-on authors want something just a little bit different than the dialogs/window layouts that skins provide.

The bottom line is layout is handled by the skinner. What controls should be present is handled by the add-on author. The only way these two fit together is if there's restrictions on the former or latter, or it's unrestricted and a lot of code is required (usually there's not a whole heap needed, though this depends on how the skin is arranged with respect to re-use).

Come up with a decent system that most add-on authors + skinners will be happy with, and I'm sure it will be considered.

Cheers,
Jonathan

I can't say i know any details from the skinning engine inner workings of XBMC, but I guess my last posts proposal should be doable? Read elements and attributes from a xml file connected/reffering to skins includes and create instances of given controls with arguments as properties and pass clones of those instances to python who evt. will pass them to a window/dialog instance and rendered as a part of GUI. This should also be possible to combine with the manual way of passing xml, so it would still be possible to create custom components?

I can see that it's not simple to create a good solution here. I love the complexity of xbmcs skinning engine, but I also get a bit frustrated when it is biting my ass when I turn to python. I see the problem with the variety of gui components you could create, so people will not be limited by a few simple components exposed by the skin. But I hope maybe some could see that functionality are more important than looks, and that tiny gfx details is a low price to pay to avoid the complexity of writing massive xml files for all their addons. And realise that basic components can be used togheter for more advanced components.

Therefore i think a good addon template for common use would be a good starting point to let

I Hope I don't sound negative here. I like playing around with XBMC and wanted to here others thoughts aroiund this.

[jmarshall]

In your proposal you have moved layout from the skin to the add-on. This will negate the possibility of the skin providing layout information - they're merely changing the look of individual components. IMO this is not acceptable.

Skins need to have control over both look and placement of controls. This is why things are complex.

This is why I suggest that the best route is for add-ons to use typical (flexible) templates - just like the main views in XBMC are typical templates (this screen has a container (list/panel/whatever), and there is a collection of buttons that interact with that list).

Depending on what the add-on is, we provide multiple ways to get your add-on working nicely with the skin:

1. Plugin (restrictive - you provide a listing and XBMC does the rest).
2. Script using winxml (designed to mimic most XBMC skin XMLs - shouldn't require too much work other than copying one of the existing skin XMLs). These could potentially be templated, eg by providing a grouplist to handle the extra buttons on the left for example that the add-on could fill. The skinner then has control over how those grouplists are laid out (horizontal vs vertical, left vs right etc.)
3. Constructing things directly with python. This is typically frowned upon, as the skinner loses control of the look - what works for one skin will typically not work for others. It also relies on common naming of files which is not always the case.

Cheers,
Jonathan

[VictorV]

Yeah, when you mention it the skinner loses some control over the layout. I was thinking that python should control the position, width and info/label data to make it fit in the bigger picture. These would be the dynamic properties of the controls and I don't see how to solve this other then adding dynamic with a script.
The skinner would still control the look and feel of the controls and windows/dialogs. Also python would need to stick to skinners rules when setting width and positioning based on margins, borders etc. on controls.
Another way to see it is that python helps the skinner add dynamic to his controls.

not sure if you mean that this is doable or if it just not accepted as a solution since it won't have a clean line between skin and addon.

I based the proposal on a solution i made when trying to emulate adddon settings dialog functionality within python with XMLWindow. Where i marked up dummy controls for each type and connected type to control by a known id reference. I then gotControls from XMLWindows by ID removed them from Window list. Then I created a copy of the control instance for every entry of it's type. Changed position based on entry index * height of controls.
This gave me some kind of dynamic GUI I was needing for a project of mine with nested multiple settings (dialogs).
But I found no way to create more advanced controls that used multiple values. Like a spin contro type


ref.
Skin source
Python source

This could be done as I wanted by expose more of the GUI controls and their methods and properties to python maybe.
Breaking down the skin files and use local include files for addon would make everything a bit easier, but I i think that would be hard to implement to. I also use plugins and combination of other methods, but I feel like I always "hacking" a solution or or using thing in the wrong way to accomplish a result it wasn't meant for to create a gui that that fits my needs.

I can't see another way to add gui components to python scripts without creating a massive bunch of static control sets for different cases.

But I guess I see your point.

[vikjon0]

A sample library of controls and methods would be very nice and also the best realistic improvement I believe. (some already exists I think)

[Bstrdsmkr]

I've been thinking about this and I think there is a realistic improvement to be made here. Skinners aren't going to be able to make a layout for every custom window addon devs come up with. Likewise, addon devs usually aren't as talented as skinners in the layout and design department (I'm not).

Maybe a jQueryUI like approach could unify things a little better?

All the individual pieces in a jQueryUI addon are named the same across addons. For example, something like upper-left-corner.jpg. What if we adopt a similar standard? If the skin doesn't include a version of the current window, then the skinner doesn't have any control over the layout anyway. If skins started including this standard set of parts and pieces which controls are made of, then addon devs could have a generic layout that uses these bits and pieces to at least match the look and feel of the skin. Neither side would have to know what the other is doing in advance. If the skinner then felt that the addon dev's layout didn't work right with the feel of the skin, they just include a window for it, like they do now.

It wouldn't solve the problem, especially for the more unique skins like Paper Street Soap Company, but at least then the skinner could give us a place to start and we wouldn't end up with shiny black buttons with blue highlight in PSSC =)

[Nuka1195]

my approach is write a script that skinners will use. design a real crappy gui and skinners usually design a better one.

[Bstrdsmkr]

lol, I used the same approach to get the wife to cook =D

[bossanova808]

I tell you what.... One minimum thing to start with would be a set of standard font sizes...that would make it much easier for things to look ok cross skins!!

[VictorV]

my approach is write a script that skinners will use. design a real crappy gui and skinners usually design a better one.

That's a nice approach for "mainstream"-addons for sure But it ain't very expendable and it would make the addon dependent on the skin.

Bstrdsmkr's aprroach is close to my first thought. Create standard names for elements defined in include.xml as base for commonly used gui elements. The downside would be that there is noe way to tell if the skin are using the standards or not I guess