[Livin]

i have used several other gui building applications (netremote/tonto, philips pronto, xlobby, etc) and found that a specific methodology of skinning always works best... from the perspective of speed of creation, reduction in size of skin, ease of modification, and ease of sharing with others for thier modification/use.

please consider incorporating these methods into the current schema...

objects and templates


first, objects... the best way to define, organize, and share skins is to separate the skin into parts.

these three are not hard and fast, but an example of a good way to divide it up....

1) objects - buttons, devices, etc
2) layout/screens - definition of how objects are displayed
3) events - macros, screen changes, etc

example button: "home"
purpose: redirects (or "jumps") to the home/main screen.

step 1) define the "home" button in a definition file
- image used, size, event triggered, etc
step 2) use the layout files to place the button object on one or more screens
step 3) define the event to occur within the event files
- tell it to go to the screen called "home", or whatever else you need it to do.

this way, skinners have the opportunity to put any object (button, rss feed, etc) anywhere and everywhere.
plus when the skinners want to share with others, they can modify the layout, objects, and events independantly... it is very common for a layout to be changed but all else stays the same.

second is to use templates...
a template is a screen layout that, if specified, is called from your current screen. like an include file. think of it as a base layer 'under' your current screen.

example template makeup and usage:

template name is "main background & buttons"
contains a background png file and several buttons such as "home", "next","previous",etc.
all the buttons are arranged within the layout so they are to be used on all screens.

usage...
we then create a "games" screen that calls "main background & buttons". since "main background & buttons" already has a background image and some buttons there is no need to duplicate those on the "games" screen layout file. we will simply include other objects we wish to add to the screen... like a games list, view button ,etc.
so the "games" screen is overlayed onto "main background & buttons" to create the final screen displayed.


i hope this was clear. i'd be happy to explain more if needed. i believe this methodology would give more flexibility, better reusability, and a quicker dev time for skins.


i'm interested to hear comments...

[Livin]

wow...
over a week and no response from the dev team at all?!

i'm dissapointed. :tear:

imo... it would be nice if the dev team worked on improving the architecture more until they got it solid and flexible before working on other more cosmetic features.

anyway here's another area of serious defficiency in the current skin schema:

i love the stacking feature and the title view for movies... but one thing that is a major problem with the schema is the way sections we are forced to "group" items like tv shows and movies and cannot be broken out...

this would definitely be helped if we could add more sections to separate into different types of videos. i'd love to remove the "my videos" section and replace it with "tv shows", "movies", "short films", etc and have each a separate section with it's own settings.

maybe this is available but i've yet to see it done by any skinner.

all this goes back to looking at each item as an object... create objects, create layouts... place any object anywhere, on any layout. tons of skinning deficiencies fixed in one huge swoop!

[jmarshall]

sorry for my lack of response earlier. i've been on holiday.

i have yet to look at any other applications to see how they do it, but the main restraint is how to program all this stuff.

the current system is fairly flexible, and there are a few things being added to make it more so.

the problem is that all the code has to go somewhere, and some things just don't make sense to be global stuff (able to be moved anywhere) as they only effect certain things.

for instance, there are controls on the my videos interface that effect only that view. (the view as buttons, stack buttons etc. for instance). it doesn't make sense for these to be able to be defined elsewhere, as they only effect that one view.

the templates idea is imo something better suited to a skinning app - unfortunately there isn't one and i personally don't have time to write one at this time. the skinners we have currently doing the work seem to be coping with the current system reasonably well.

the current system is already object orientated. you can define the generic button etc. in references.xml, and then put the layout in the .xml file you want. the event action obviously is placed in the layout .xml as well (where it makes sense).

i guess we need specific things you would like to be able to implement that you can't do at the moment. in the past, when skinners have wanted stuff, it's generally been talked over, and a solution has resulted.

we are not going to do major changes to the gui code unless there are obvious benefits.

supply some specific examples of what you wish to be able to do, and we'll see what we can come up with.

cheers,
jonathan

[Livin]

cool, i do understand your thoughts on it.

i gave one example above so let me elaborate on it and i will give you some other main ones to start with...

1) handling of multiple different "types" of objects withing a screen.

this really shows a current deficiency when dealing with the "my videos" section:

i love the stacking feature and the title view for movies... but how to have tv shows also display in the same screen as movies?

i hate having to switch back/forth between 'file' view and 'title' view just go tv shows <-> movies.

it would definitely help if we could add as many categories/sections to separate into different types of videos (this goes for anything else too... programs & games, etc).

i'd love to remove the "my videos" section and replace it with "tv shows", "movies", "short films", etc and have each a separate section with it's own settings.
i like to be able to remove "my programs" and separate out "games", "programs", "online gaming", etc.


2) multiple rss feeds, on any screen
this has multiple areas that i'd like to see implimented...
a) be able to set a scrolling rss feed that actually has multiple feeds on one line (one after the other)
b) be able to have a "news" page so that we can have multiple feeds, each on a separate line. non-scrolling or scrolling. thus we can read it at our own pace if it is not scrolling by using the controller to move to the feed we want to read and using the direction stick to move along that line.
these features would, of course, allow to have a different feed on each page too.

3) creation of "shortcuts" on any screen

i'd like to have "quick navigation" abilities. so on each screen i'd like to have small icons (maybe at the bottom and/or maybe on a hidden subpanel like the home screens have) so i can jump directly to another screen... say i'm in videos and i get done watching a movie then i want to jump directly to games to play. also, this would allow a true "home" button on each screen.

this would clear up one issue i have currently with the entire way xbmc is navigated. the back button is used but if you are several layers deep you must hit back many times to get to the main menu so you can go into a different area.

4) define multiple items as a single object.

this would help in many situations and has many uses... one is with scripts. we could define a set of .py files and a folder as a "script" object. then once defined, xbmc could be told to auto-generate buttons for all script objects, say on a certain screen. so once we define the object, we may never need to build a specif button for it if we have the screen auto-generate all the buttons each time we navigate to it. this would enable us to add/remove scripts on the fly and never need to modify the skin.

5) templates

i think having xbmc's engine understand templates would have these benefits:
a) make the skins themselves smaller since there is less code required. if you set a screen as a template the skinner would not need to duplicate xml code on each page
b) xbmc could cache the tempate pages.

speed should be increased due to both a & b.

c) skin "look 'n feel" consistancy is easier to maintain. scripters would not need to include a background. if xbmc is told to use a template, by default, the script pages would always look how the skinner wanted them to.

i'd think the  end user would like this feature a lot! i'm not a huge fan of having to do code changes all the time just so my script backgrounds can match the skin i'm using. and then what happens if i change skins... ohg!

jmarshall, as a side note...
forgive me if i misunderstand your previous statement about objects but maybe i'm defining object differently. i'd like to see a define once, use many style.
i'm no expert programmer but from what i've seen in the little i have done, objects are typically defined in one place in code, in a module. the object's properties (including event action) is also defined in that same place. the object will have the same properties (including the event action) no matter where it is used even if used 100 times on 100 different screens. there are minor exceptions to this, including for redefining/redimming and such for programming c, vb, java, etc.. but that complicates things unnecessariily for skinning.
so, by this definition, no matter where you use the object anywhere, on any screen, or in any other module (in xbmc terms, anywhere in the layout pages), it always acts the same. this make it very easy to place, say a "home" button, or an rss object anywhere without needing to define its action event every time. makes skinning much easier and faster.
to me it seems that xbmc may not be following this object convention if the object properties (other then it is a 'button') is being defined in the layout. we must define all properties at the beginning so reuse is fast and easy, and standardized within the skin.


i have more ideas on making the skinning let me know what you think.

[jmarshall]

ok. there's a lot to absorb there. let's start with the easiest stuff:

3. already possible. you can use either hyperlinks or xbmc.activatewindow() style of linking.

2. this just needs improvements to the rss stuff. the feed is currently defined in the skin, and there is nothing stopping more than 1 feed being placed on a particular page. currently each rss control is limited to the 1 feed from what i can gather though. this would be easy enough to change, but it has limited use imo. a better change would be to get the rss feed information out from the skin - it's got nothing to do with the look of a skin - it's content that the user should define - not the skinner.

1. i agree that lumping heaps of things together into the 1 screen (such as tv shows and movies) is not ideal. however, we need to think of a decent way to handle the division.

for instance, there is no way for xbmc to know from a given file whether it is a tv show or a movie - it's up to the user to characterise this. i expect the most logical way is to have all tv related stuff in one share, and all the movie related stuff in the other share. then one could have a separate section for each one - see kraqh3d's patch on sf which will be incorporated into cvs once he has it completed.

a complication is xbmc's database views. these only work with movies, as we get the information from the imdb, yet they can be reached (via a switch view) from a filelisting showing tv shows.

i guess the complication is how does the skinner (or user) tell the xbmc engine what is and isn't allowed on a particular screen? most of the screens are there for specific functions, therefore they need specific code to run.

4. this is a tricky one, as so much of it depends on what you are wanting to do exactly. for instance, the idea of a screen with a bunch of scripts pulled from a directory could be done with a list control, if the skinners could tell xbmc how to fill the listcontrol (or could be done with a cunningly crafted derivative of the scripts window). however, other things (eg a group of controls that form a unit - such as a listcontrol with viewas, sortby etc. buttons) are more just a set of controls that interact - the code would need to know how each control effects the others. i'm not sure how this interaction would be done in a clean manner.

5. templates are possible to do, but would have to be done in a way so that it doesn't cause any slow downs in the loading of skins (as you point out). i'm not really up with the interaction of scripts and whether they can use skin files etc. so i can't really comment much on that. even once you have defined the template screen, you still need a way to tell the script windows to use the template.

i look forward to others comments (particularly those that have done skinning and want to do stuff that is not currently possible).

cheers,
jonathan

[Livin]

as a reply to your comments...

1) being able to define a share as an object (within xbmc), thus defining its properties (view type, etc) would allow two possibilities:
a) a single screen to show all items within multiple shares on one screen. since xbmc knows that everything within a specific share is a specific object type, it would be able to display it according to the properties of the object type.
* this is the "ideal" situation. now... for an easier way...
b) have the skin display each share separately on separate screens but still use the object properties to determine the type of display (thus breaking out movies from tv show from...).
- i think this still comes down to defining objects at the xbmc level, not the skin level.


2) i agree the rss feed definitions should be removed from the skin itself. it should be defined within xbmc config.this makes changing skins much easier.

4) i agree with you... i do think the solution is defining the 'set' of script files as separate objects within xbmc. this will allow the skin to simply display all objects defined in a listcontrol. by possibly doing something simple like this...
listcontrol (objscripts, alphabetical, button) - that one line (as a hypothetical) could create a set of buttons in a list and organize them in alphabetical order. this may have just created a list of 20 scripts with one line

5) templates should actually speed up xbmc by reducing the code on each xml page. the template is cached into memory, thus allowing the other xmls to be reduced in size.
also, for the scripts, they would not need to reference a template directly if xbmc could set a "default" template. thus, any xml would use the default unless a different template was speficied within the xml iteself. another way is to create, yes objects, for each set of pages that use a specific template. thus defining a set of xmls with specific properties, one being a template.


most of these ideas are not original... i have gathered these from working with the philip's pronto software, tonto (another skinning app for pronto and netremote), xlobby, and designing web pages (html, css, asp, etc). for example... even html can use many types of templates (style sheets, frames, etc)... and html is the most basic markup language i know of.

i'm also interested to hear from other skinners and programmers!

i think to enable for xbmc to grow and advance to outlast the onslaught of new media devices we should look towards making xbmc skinning simpler and more flexible which will, in turn, give it more features. all of this can only help since xbmc does not have a skinning app. :tear:

[Livin]

vote yes if....

you think it would increase the number of skinners & skins.

the current model is not flexible and you want to put items where you decide to, not where the engine developer say you must. ie: weather, sys info, ram, etc on main screen.

you'd like to have differnet icons for each folder and any type of video, audio or any file extension or from within any folder.

you'd like to separate your games, programs, tv shows, or anything else you decide to have separate screens for... not allowing the developer to decide for you what should go together. and access any of them from any other screen directly.

you'd like to have a home button on each screen!!!

you'd like to have templates so all your script screen automatically have the same background as your skin, even when changing skins.

you'd like to be able to create a new screen, by hand, in 30 seconds because the objects a(like controls and control groups) are already defined in a definition file and all you need to do to use the same control on the screen is put in one line of code! thus, reusing objects that are only needed to be defined in 1 place, not in each xml file you want to use it in.

and a sh!t load more if the model was a true object model.


vote no if...
you do not want any of the above abilities.
you like being locked into a model designed by someone else that requires you to repeat the same basic layout/design and only change the graphics... woopie!

[pin87a]

vote yes if....

you think it would increase the number of skinners & skins.

i don't think that any of your suggestions will increase the number of skinners or skins. in fact i think it will do the exact opposite.
if the goal is to make xbmc easier to skin then you would want things to be less flexible with xbmc deciding the placement and size of everything. the skinner would only responsible for deciding what textures it uses (ala xbmp).

the inability to display hard drive temperatures on the home screen isn't stopping people from creating xbmc skins. 50+ xml files, 5 tv standards, and 200+ required textures is.

[Livin]

i don't think that any of your suggestions will increase the number of skinners or skins. in fact i think it will do the exact opposite.
if the goal is to make xbmc easier to skin then you would want things to be less flexible with xbmc deciding the placement and size of everything. the skinner would only responsible for deciding what textures it uses (ala xbmp).

pin,
are you serious? that is like an auto manufacturer saying... "we'd sell more vehicles if we only gave the buyers one vehicle to buy but let them pick from any color they wanted."

omg... pin, you should really take a look at how the world runs and why people buy/want goods & services. it is choice. not limitation.

[Gamester17]

no offence but i'm not really sure if you 'earned' the right to post a poll like this as you're not a skinner nor a programmer yourself, plus it is very subjectivly written :hmm:
...even if this poll should be allowed to stay then it should only be skinners who have the right to vote as users only hear; "add new/more * or?" and say "hell yeah!"

[Livin]

gamester,
i understand what you are saying. i'd like to leave it open to all for simply that some that are not currently skinners for xbmc may become skinners if the object based engine is implimented.

i fall into this category. i am a skinner for other products and also design guis for web pages used as control interfaces. so i completely understand the process that goes into it.

while i do not code serious languages like c, i do understand methodologies and concepts for many languages like c and i do some basic vb, java, etc. nothing fantastic like xbmc.

i hope you understand my reasoning behind wanting this engine change.

[pin87a]

i don't think that any of your suggestions will increase the number of skinners or skins. in fact i think it will do the exact opposite.
if the goal is to make xbmc easier to skin then you would want things to be less flexible with xbmc deciding the placement and size of everything. the skinner would only responsible for deciding what textures it uses (ala xbmp).

pin,
are you serious? that is like an auto manufacturer saying... "we'd sell more vehicles if we only gave the buyers one vehicle to buy but let them pick from any color they wanted."

omg... pin, you should really take a look at how the world runs and why people buy/want goods & services. it is choice. not limitation.

you said "vote yes if....you think it would increase the number of skinners & skins."

so i answered that question.
i don't think a more flexible skinning system will increase the number of skinners and skins.
it would just add another layer of complexity that would probably lead to less skinners and skins.
i didn't say that i wanted xbmc to become like that, i just said that it would be the best way to make skinning "easier."

as for your ideas...
you can already put a "home" button on any screen and access any screen from another.
<hyperlink>id of the screen you want to go to</hyperlink>

almost every script already uses "background.png" as the background image. if you wanted you could easily use "background.png" as a script background and for every other screen use "somethingelse.png."

you already can define most common objects in references.xml and re-use them with a few lines of xml.

the xbmc "skinning engine" is actually pretty damn flexible once you get used to working with it.

anyways...i think that any time put towards adding features/ui changes should be used for making xbmc better as a whole (for everyone and every skin) and not used to put the control of the entire xbmc interface in the hands of the skinners.

[Gamester17]

i don't think that any of your suggestions will increase the number of skinners or skins. in fact i think it will do the exact opposite.
if the goal is to make xbmc easier to skin then you would want things to be less flexible with xbmc deciding the placement and size of everything. the skinner would only responsible for deciding what textures it uses (ala xbmp).

pin, are you serious? that is like an auto manufacturer saying... "we'd sell more vehicles if we only gave the buyers one vehicle to buy but let them pick from any color they wanted."

omg... pin, you should really take a look at how the world runs and why people buy/want goods & services. it is choice. not limitation.

@affini, by your argument the evox/evolutionx dashboard should be the least popular xbox app to skin, but 'oddly' it's the other way around. evox/evolutionx has 10's of thousands of skins available because it's so easy to skin, just two background pictures, (now you can't get much more inflexible than that). to compare on pc you have winamp which is also skinnable and very popular to skin just because it's so easy, and it's only easy because you can't change anything, all you can do is add your texture. my point being that you can't all the choices available in real-life commercial production with the available alternatives to skin a homebrew software application like xbmc.

ps! again about the subjectivity of this poll and how you format the options, what would do you think would be the outcome if i created a poll that said;
do you want xbmc-devs to spend time on "1. adding new features/functions" or "2. extend the skin-engine that's already not being used to its full potential"

[bobrooney_78]

i think the only way to attract more skinners is to make a skinning-program for windows. in my opinion the skinning-engine is flexible enough - but there is of course some room for improvements (show harddisk-free-space in the filemanager, xmv-video-support in the gui...)

[Chokemaniac]

i totally agree with pin87...