[da-anda]

As a extension of the discussion started on PR7453, I'd like to use this thread to document and discuss the plans, whishes and ideas for the skinning engine / UI. I actually wanted to talk about this at devcon, but it seems the demand for discussion is already right now. So here we go:

To me it seems that skins are drifting away from the old hirarchical menu structure approach and would like to go new ways in terms of navigational concepts and getting feature rich home screens etc (see fTV skin, leanback, ...). To achieve this in better ways than currently possible, I have some ideas I'd like to share and discuss:

1) Separation of core and UI
To free our skins we IMO have to remove the hardcoded bindings of some core functionality and the UI, which basically means separating core from the UI. IMHO this could be achieved by an interface that's hooked up to thread messages, which means that core components only fire thread messages (or alike), passing along required arguments, a unique action ID and a hardcoded log message (if required). The interface/communication layer is catching it and forwarding to registered observers via JSON, BSON (which is faster than JSON) or alike. The connected UI component is then processing the message and performing the required actions (ask skin for special handling of that action, if not ask addons, if not perform a default action like triggering a dialog). In case of an interactive action (dialog/input result) GUI is sending a response back (response action/callback would be part of the arguments of the initial request/message). Required label IDs would be mapped and fetched by the UI component, so that the entire core would be free of strings (besides of debug messages) and any UI logic (windows, dialogs, ...).

Doing this will have the following benefits:
- no more UI and label bikeshedding in PRs of core components
- UI guys can go crazy without annoying core devs
- thin clients
- any kind of UI (feature-full HTML5 UI/Webinterface for headless, desktop app like UI ...)

2) MVC in skinning engine
Instead of having hardcoded window structures with actions we could leave it up entirely to the skins which windows and which content to show. Core/UI component would only provide "data-providers" that skins can use to grab arbitrary data (list items, infolabels, settings, ...). These data-providers could be add-ons, so that new/custom ones could be added easily. In order for skins to be able to trigger actions, buttons etc whould have to be extended to allow some sort of "controller" and "action" attributes which will be processed by UI component and forwarded to core (<button label="123" controller="videolibrary" action="scan" />).

3) context based keymaps
Because keymaps are currently bound to window IDs, they won't work anymore when skins are free to do what ever they want. To compensate for that keymaps would be bound by contexts instead, which a skin would define for each window/dialog. End result would be simmiilar to what we have now, but more flexible.

4) skin specific keymaps
because of all the flexibility, one global core keymap won't really work anymore, so core would only provide basic keymaps and skins would have their own defaults.


-------------
Please see this only as some basic ideas and a starting ground for further discussion and ideas. I know that these are quite drastical changes and a lot of work if we would like to go that way. What do our core skinners think about it?


I post this in the readonly section for now, but we could also open it up for "public" discussion so that all skinners could share their ideas.

[natethomas]

For reference, garbear was already running into many input-related issues and so has been doing a lot of work with controllers and event handling.

http://forum.kodi.tv/showthread.php?tid=230276

I'm not sure how useful or applicable that work is to this discussion, but I figured I'd point it out.

[da-anda]

I just moved this to the public dev section so that all skinners can reply. If you are not a skinner or dev, please don't take part in this conversation, thanks.

[echo]

Oh wow, finally... that would be great. I would love the possibility of seamlessly animating and moving from one section to the next without the stringent page/window structure... to have everything flow as if it was on one page [home to movies to tv shows and back home]... without the "lets just refresh the page" look to show new content. Likewise I would love to see multiple content containers on one page (for example two movie containers on one page [a top one showing unwatched movies by date added, and a bottom one showing the rest of the watched movie library ... as opposed to the current "hiding watched"]).

And since we are talking about skin engine ideas, my most favourite feature request: BLUR

Thanks.

[thedeadman]

@Da-anda: Great ideas all.

I'm not sure whether it's the right way to go to move away from the existing skinning engine at the moment. It is really good, and many of us have spent a long long time getting to know its inner secrets.

That being said, I would welcome a number of things:

- Adjustment of the 'node' based filesystem so that it is much easier to manage what types of content get shown with each type of view. The amount of conditional logic required to manage this currently seems obscene (though I know in my own work i'm forcing Kodi to behave in a way that it wasn't necessarily intended to do). The recent splitting of the PVR windows into individual windows made skinning PVR much easier, it would be good to see that extended to 'myvideonav' and so forth.

- A root and branch dissection of the current skinning engine, with a view to reducing the number of windows, controls and dialogs that require skinning to achieve basic level functionality. I know this stuff is ongoing, but it wouldn't hurt to blitz it. Particular attention needs to be paid to the music section imho, where windows like 'mymusicsongs.xml' should probably be done away with.

- A 'skin development plugin' or something similar that provides easy access to all windows and dialogs, populated with appropriate dummy data. God knows it's hard enough to skin Kodi without having to repeatedly navigate to a given window to test it.

There's more i'm sure, i haven't had my full dose of coffee yet this morning :-)







-

[da-anda]

with my suggestions I don't want to break every skin out there. Ideally there could be some compatibility layer, or let's say, after separation of core and UI, a new UI implementation (moving towards steps 2 - 4) could be developed and skins could specify which implementation to use, or something like that.

[toolpunk]

Great idea! The split would open up so many possibilities. I really hope this is going to happen some day.

[nessus]

I don't know if this is good or bad idea. IMO whatever big change will come the main purpose should be to make skinning more simple and less code demanding. I know that they are skinners out there that they want to have full control in every element and they don't mind to write hundreds or thousands lines of code for that. That should not be the goal here.

At the moment, to create a skin from scratch until is ready for the official repo is a nightmare and that is because of the many little things that a skinner has to deal with them so to make the skin just functional, without any extra futures. This procedure should be simpler and faster so more people to get involve. People that have some great ideas but never make it out to the big public since the moment that the realize how many (not so attractive) things they need to be done they give up and those ideas the stay only in the WIP Skins forums fro ever. A very good example of what i am talking about is the skin shortcuts script. Without this script i would never thought to include so much customization in my skin because the amount of work that will needed. Now, by using this amazing script i can offer the same features with the one-tenth of the coding work. That's what i am talking about !!!

So, if this change will mean that we need to set and define more stuff in more details just for the sick of more detailed control over the skin engine, so the more advanced devs to do more complex and exotic stuff, then we are on the wrong way here.

Cheers
Nessus

[Hitcher]

I've said it before but we definitely need to reduce the amount work done coding all the dialogs. 2 more have been added for J* (DialogAudioDSPManager.xml and DialogAudioDSPSettings.xml) already!

Adding more controls (grouplists, background images, dialog image, etc) to the Defaults.xml and using them to auto-build dialogs would be a massive time saver.

Regarding the skin shortcuts script, all this was planned to be added to core many years ago so what happened?

[ronie]

JM left?

[Hitcher]

Possibly if it was his idea.

[toolpunk]

@nessus @Hitcher
While auto-building the dialogs would certainly be a time saver, we already have the option to code them time efficiently with includes and lots of copy pasta.

Also this change wouldn't necessarily bring about more work. Just think of all the code intensive hacks we currently need to achieve simple things. I'm convinced a properly separated UI layer could actually save skinners loads of time.

[thedeadman]

To be fair, most of the dialogs aren't too bad to work with, but they are often quite difficult to test.

Perhaps dialogs for some of the features like the new audiodsp stuff would be better suited to being rolled into the existing settings windows anyway?

[da-anda]

I'd suggest to wait with adding ADSP support to your skins as it still needs a UX review and most likely some changes

[Jayz2K]

Please see this only as some basic ideas and a starting ground for further discussion and ideas. I know that these are quite drastical changes and a lot of work if we would like to go that way. What do our core skinners think about it?


I post this in the readonly section for now, but we could also open it up for "public" discussion so that all skinners could share their ideas.

I'm on the way to deliver in some days / weeks my very first skin for KODI and I have to admit that this is such an impressive amount of work to complete the job (even for skilled skinners). Team-Kodi is making an awesome responsive job to our requests but this makes the skins development harder each time a new feature is out. I agree there is too much windows to handle : dialogs as Hitcher said but My***Nav windows too. It's quite a turn to think about rebuilding such an engine but I think it will have to happen one day with the idea in mind that much of old skins won't work anymore (and I think the engine is this complicated for getting mostly backward compatibility ?) but hey, sometimes it needs a fresh new start for fresh new works (and fresh new skinners ?).

I didn't understand the Core / UI split but here's my 2 cents from my beginner experience :

Gathering list types into a single one ?

There's many list types, list, fixedlist, wraplist, panel. In the layout I developped, I almost always use the panel one since a single column setup results in a vertical simple list and a single row setup results in an horizontal simple list. Why not keeping just this one with <wrap>true/false</wrap> tag ?

Built in grouplist and list specific contents

In the same idea in mind, with the same new list, It should be great to fill this list by specific content instead of calling built in "Id's"

Ex for calling a built in list :

Code:

<content>Builtin.List[AddonSettings(2)]<content>

where "2" is the List number (non DialogXXX.xml relative)
This can return 3 or more Infolabels depending the built-in control it actually uses : Label, Label2, Controller (spin, radio, etc with DefaultSpinUp.png in media root for an example as standard requirement).
So it's easy to set and position the controls in the layout (without having to complete all the spincontrolex, sliderex, etc)

Code:

<itemlayout>
   <control type="label>
   </control>
   <control type="label2>
   </control>
   <control type="controller>
   </control>
</itemlayout>
<focusedlayout>
</focusedlayout>

Ex for calling a Library content :

Code:

<content>Library.List[videos]</content>

where video is relative to the MyVideoNav.xml
Could also be :

Library.List[musics]
Library.List[pictures]
...

This should make possible to avoid all the MyXXXNav.xml and build just one MyNav.xml where content is set from the calling window.

All these come from my skin dev builtin layout. I actually uses only one List Type, one Nav.xml, one Viewtype and one Dialog. What takes me a huge amount of time now is to copy paste the common code into multiple windows I don't really need (but kodi does). However, custom windows are still an option for more needs

Still, these are just suggestion.