[floink]

hi all
ok probably sticking out my neck a bit here but i was thinking about how development of new features is really progressing nicely and xbmc is getting more feature packed and stable by the day. but what about the skinning engine? isn't it lagging a bit in functionality? it's been a prett straight forward 'add image place it on screen' process since the beginning. i'd say animated gifs was the last thing that took it to a new level. anyone agree?

in my opinion there could be some things done to really lift the gui to another level. some more advanced and some less advanced. i know any change would require devs to want to do it and that is always the most important factor to get hings done with features.

my intention with this post is to get a decent discussion going where people with some kind of experience in doing skinning for xbmc should contribute. a discussion that maybe could lead to a wishlist and a feedback to any dev out there that would be willing to do some work in this area.

not the "this and that would be sooo cool" kind of discussion but rather a "this and that would add this and that possibility because of xxxx" discussion.

hope it doesnt sound to boring but i was hoping for something constructive

the first things that i come to think of that has been suggested before are:

1. animation of gfx: <pos1> to <pos2> in <time> fex
2. animated rotation of gfx:<ang1> to <ang2> in <time>
3. swf support (which isn't really feasible but still)
4. avi support for skin gfx

my quicklist...  opinions?


/floink

[jmarshall]

great thread, floink

i mayaswell give some input, seeing as i'm kinda the one who screws the gui up for skinners the most :p

points 1 and 2 are probably easy enough to do. as far as animation goes, the easiest things is to do it texture based (ie using the 3d engine). we probably want to keep the actual gui 2d as much as possible, as i don't think things like this benefit from a 3d interface (except for maybe looking cooler which imo is not the point).

animated gifs are a memory hog as we have to store all the different frames as full textures. just see how much mem project mayhem is using on the home page for an example - and that is only with a couple of anim gifs.

moving things around (changing position/size/angle) and so on is easy enough, as is doing colour effects such as alpha fades.

as for video embedded in the skin, i think it would have to be restricted to wmv (xmv) which the xbox can handle without the need for mplayer etc.

i'm interested in everyones ideas, and am willing to look into incorporating some of them once they've been thought through to a sufficient level.

also, any suggestions on how the skin system could be improved to make it easier to skin would also be good.

cheers,
jonathan

[Nickman]

moving things around (changing position/size/angle) and so on is easy enough, as is doing colour effects such as alpha fades.

as for video embedded in the skin, i think it would have to be restricted to wmv (xmv) which the xbox can handle without the need for mplayer etc.

both those features would open up a possibility to make very nice skins imho.

[floink]

as far as animation goes, the easiest things is to do it texture based (ie using the 3d engine).

does this mean one would probably use some kind of dx9 functions to achieve the 'movement' of gfx but keeping it in two dimensions?

we probably want to keep the actual gui 2d as much as possible, as i don't think things like this benefit from a 3d interface (except for maybe looking cooler which imo is not the point).

totally agree. it's been tried and failed several times before. it would also as far as i can see it add imensly to the complexity of skinning. the 'new' dashes coming out nowdays basically have some base elements in 3d that are coloured end texured differently from skin to skin. not really adding to the diversity of the skins.

animated gifs are a memory hog as we have to store all the different frames as full textures.  just see how much mem project mayhem is using on the home page for an example - and that is only with a couple of anim gifs.
as for video embedded in the skin, i think it would have to be restricted to wmv (xmv) which the xbox can handle without the need for mplayer etc.

the advantage of gifanims in this case is that they are fairly easy to create. creating vmw files is another deal but they could achieve the same kind of effects that gifanims do. from what you say my conclusion is that xmv files would be a benefit memorywise? one area where vmw's could add nice effects is in backgrounds.
as a skinner you would probably want to be able to control repeat and playonce stuff.

moving things around (changing position/size/angle) and so on is easy enough, as is doing colour effects such as alpha fades.

been thinking alot about this. and this could be used for fex hiding/showing buttons (like the new sub menu), which in turn would add space for file/thumbs lists and such. this would add complexity to navigation and could be solved in different ways. fex using display button on remote to hide/show buttons.
or in my skin retro in the home screen i have a little window that could have images rotating in/out of view (if you remember ).

i'm interested in everyones ideas, and am willing to look into incorporating some of them once they've been thought through to a sufficient level.

this was exactly my point with this kind of discussion.

also, any suggestions on how the skin system could be improved to make it easier to skin would also be good.

i'm not sure, maybe this is possible already but a thing i've been missing is the ability add skin specific stuff to references.xml. like in my case i want to add a bg and fg gfx to file/thumb lists. to really simplify skinning would be to create a good skinning application. havent had the chance to try out xform yet but maybe endorsin such a project from the xbmc team would help?

...and thx for great feedback. i'm really looking forward to hear chokeys opinions on this too.
/floink

[Gamester17]

as this is a feature suggestion (actually it it several different feature suggestions) i'm moving this to the feature suggestions forum.
note! you should split each separate feature into it's own topic thread for our managebility benifit. some things already suggested:
- game and video preview/intro support, using (wmv/xmv) preview video clips
- .wav support when navigating main menu; bleep bleeps, bloob, bloobs and clongs
- ram (recently added media) custimization, only scan in specific selected share(s).
- xbmc-skin version system of some sort?, to indicate compability for user & xbmc.
- skin container format (uncompressed zip?), standardize archive packs for xml + xpr.
- xbmc skin preview.
- auto-download of gui skins, direct from within xbmc...
- calibrate/adjust ui size, (stretch or shrink), ...a full gui calibration option... (as tv-overscan compensation)
- animated skinning-scripts, skin script language.
- status bar skinnable.
- gui requests; icons, xml changes etc.
- skinning features; tweening/animation/3d support?.
- use default skin graphics.
- gui suggestion.
- layout change for default skin, an option?
- improved ui; no more "computer" feeling please.
- display 'recently added' items per category, in place of main menu graphics.
- how about an eject button

[floink]

all great gamester17 a superb overview of things already suggested. and i do understand why you want it managable from your point of view.

tho to clarify: the reason i did not post in feature suggestions in the first place is that i did not want to make it into that... as of yet.  i thought having a constructive discussion about feasible updates to the skinning engine between skinners, and also hoping for dev feedback, would  eventually lead to some kind of wishlist. a list prioritised on the 'right' facts with supporting background info based on that very discussion (without trying to sound condesendant) from people who know what thy are talking about. i mean almost never someone questions a developers experience and authority on coding.

ofcourse no feature suggestion could really be prioritised before another in a open source project, as it is up to whom implements it what he/she wants do. but wouldnt that dev be happier if he/she knew they were implementing something that would be used and appriciated? and also basing the decision on wether to start working on it on some substancial bginfo?

so i hope that by knowing this you can let the discussion go on for a little while more before we are forced to breake it up to a thread per feature discussion (or even a feature suggestion). something that would actually undermine the idea of this thread...

i'm sure that when a dev starts to dig in on something from the discussion it will be quite natural to start a seperate thread around feedback on that feature and then maybe also a seperate dev thread. just as it has done in many other cases, the osd being the first one coming to my mind.

i might be undermining my own intentions by writing the above but it's an attempt to be more constructive around feature suggestions on the skinning engine, and i hope it works

sincerly and kindly

/floink

[Gamester17]

ok, will make an exeption and not close this thread if it's kept constructive, but willleave this discussion in the feature suggestion forum.

ps! in my last post i forgot link to thread on; flash and swf playback support in xbmc, swf video/animations/games/screensavers (link)

[pin87a]

the changes i would like to see are mostly to make things easier for the skinners, and more importantly the users.

for the users:
1. allow for easier customization. specifically the home screen.
every user seems to have a different opinion about what buttons are on the home screen, so why don't we let them make that decision instead of doing it for them?
i think using a scrolling listcontrol for the buttons on the home page would help. the buttons on the page could be configured in xboxmediacenter.xml.
this would allow for a large amount of buttons on to be placed on the home screen, and the user's personal setup would persist from skin to skin.

for the skinners:
1. standardize the settings section and have xbmc automatically generate it (using the skin's background and button textures).
the settings area is the most frequently changed part of xbmc so this would make skin updates a little less frequent. :p
plus this would make the settings section consistant from skin to skin so the users don't have to figure out where the skinner decided to put stuff.

2. add a way to launch xbmc in 16x9 mode, but letterboxed for a 4x3 display. maybe a button combination on boot or something?
this would allow skinners without access to a 16x9 television to easily create 16x9 compatible skins.

i don't know if any of these changes are feasible, or if they are horrible ideas, but i figured i would suggest them...

[jmarshall]

pin87a:

thanks for the suggestions. i agree wholeheartedly with most of them.

as for the home screen, we're planning on making it editable in some way. i was thinking of having a scrolling set of buttons as you say. basically, the skinner would just have control over where the list of buttons would be placed, and what each button would look like (like the context menu is at the moment). users could then add, remove, edit their buttons as they see fit.

as for starting in a pseudo 16:9 mode, this is a little trickier due to the way the skin system works. i think a better solution would be a solid skin-previewer for the pc that handles this. i haven't had a chance to check out x-form, but if the author is willing to opensource it we'll go with that and make sure it works well. if not, we might just have to write our own.

as for the settings screen, you are right. there is no need for this to differ between different skins (and we'd prefer it to not differ). i think that perhaps a single .xml file defining the buttons/textures etc. to use would suffice. xbmc would then generate the pages itself, using the textures as the skinner wants. there would thus still be some flexibility for skinners to get the look they want (background images etc.) but they would not have to worry about layout of buttons, adding new buttons, etc. etc. etc.

i'm very interested on hearing other skinners opinions on these suggestions - particularly the last one regarding the settings screens, and what control you want to be able to have (if any).

cheers,
jonathan

[jmille01]

i hope i'm in the appropriate place with this now.

my feature concerns around the current skinning design is that it is too tighly coupled to an existing set of windows. the underlying skinning architecture is actually more flexible than this.

the main issue is that i want to be able to design windows without regard for the existing window files. if i want to add new pages, or (as has already come up for me) use more sub-menus on my pages, i should be able to do that. as long as the new pages i create have a unique id, then they should work.

the way i chose to handle that myself was to add a "userwindows.xml" file which defines additional xml files that have to be loaded. my file includes the file name and a "type" element which instructs xmbc what class to use when creating the window.

this works reasonably well. in another forum jmarshall suggested that another options would be to load all of the xml files from the skin directory. i considered this, and actually think it would be a better option. it would also be a much more involved option. all of the existing windows have load statements that load one specific xml file into it's corresponding class file. these would have to be excluded in a generic load. we would also have to change the loading mechanism somewhat. currently a window object is instantiated, then load is called to load the xml file. in the "load all files" scenario, there would have to be some indicator in the file as to what class it should be loaded as. then the file would have to be loaded first, inspected for the class indicator, then the objects created and loaded.

come to think of it, this might now be so bad. if we created a new overload of the load() method to take a tixmldocument instead of a filename, then we could avoid double-loading the xml files. we still have the issue of the existing window files. we could change the mechanism altogether and force all skin files to include a <classtype> tag or something, but this would break existing skins, which i'm sure we want to avoid. we could scan the directory and dynamically load any file with a <classtype> tag, while using the old method for files without one. this would mean that all existing skin files would get loaded twice...maybe that would be ok.

in any case, the basics are there. there is no reason that the skinning engine has to be limited to existing files. my original drive was that i wanted multiple submenus on the home page (for quick access to common functions, while moving "power off" to a submenu that was harder to hit...i keep turning my box off by accident :hmm:.

here is the function i added (with fix for the null pointer problem jmarshall pointed out). i call it from loadskin(). i'm not sure about how useful dynamic dialogs would be, and i think another change would have to be to make full-screen windows work correctly (currenly code to get to the previous window is implemented in each of the individual window class files instead of in the base class). but submenus work great, and i indeed now have multiple submenus on the home page.

bool capplication::loaduserwindows()
{
tixmldocument xmldoc;

// load the "userwindows.xml" file
resolution restouse = invalid;
cstdstring strpath = g_skininfo.getskinpath("userwindows.xml", &restouse);

if ( !xmldoc.loadfile(strpath.c_str()) )
{
clog::log(logerror, "unable to load:%s", strpath.c_str());
return false;
}

tixmlelement* prootelement = xmldoc.rootelement();
cstdstring strvalue=prootelement->value();
if (strvalue!=cstdstring("pages"))
{
clog::log(logerror, "file :%s doesnt contain <pages>", strpath.c_str());
return false;
}

// loop through the "page" elements
const tixmlnode *ppage = prootelement->firstchild("page");
while (ppage != null)
{
const tixmlnode *pfile = ppage->firstchild("filename");
if (pfile == null)
{
clog::log(logerror, "page section contains no filename element");
}
else
{
cstdstring strfilename = pfile->firstchild()->value();

// create the window
cguiwindow* pwindow = null;

const tixmlnode *ptype = ppage->firstchild("type");
if (ptype != null)
{
cstdstring strtype = ptype->firstchild()->value();
if (strtype == "dialog")
{
pwindow = new cguidialog(0);
}
else if (strtype == "submenu")
{
pwindow = new cguidialogsubmenu();
}
else
{
pwindow = new cguiwindow(0);
}
}
else
{
pwindow = new cguiwindow(0);
}

// check to make sure the pointer isn't still null
if (pwindow == null)
{
clog::log(logerror, "out of memory / failed to create new object in loaduserwindows");
return false;
}

clog::log(lognotice, "loading user page:%s", strfilename.c_str());

// try to load the page. if the load fails, delete the pointer
if (pwindow->load(strfilename))
{
m_gwindowmanager.add(pwindow);
}
else
{
delete pwindow;
}
}
ppage = ppage->nextsibling();
}

return true;
}


thoughts?

[jmille01]

oh, one more thing...this thing about pinning control id's to certain functions in certain windows (like dashboard, reboot, and shut down) is also too restrictive. i would like to add access to a variety of xmbc internal functions available through the <execute> tag. this would be either though a numeric value, or though some text mechanism like "xmbc.reboot". then these can be checked for in onmessage, case gui_msg_execute. this would allow these functions to be accessible from any skin page.

sound ok? i'm willing to do the work on this...just getting thoughts before putting in the time.

[jmarshall]

i'm in agreement regarding the controls tied to the windows thing - anything that should be moveable, should be handled either in the windows base class, or somewhere else globally. things such as reboot, etc. can be added to the <execute> tags easily enough i think, assuming we define things well enough.

we're hoping to reduce the complexity of the skinning system (see above) by getting rid of settings altogether, replacing it with just a single .xml file where skinners could define their button textures, fonts etc. etc. we'd then build the settings screens ourselves with the same layout for all skins, built entirely from the code. it would make things much easier to add code-wise as well as make life a lot easier for skinners.

we could do a similar thing to cut down the mymusic*.xml files as well, as they're mostly just repetitions of the one file. same applies to myvideo*.xml files.

as for the idea of new skinner-defined files, perhaps we could combine both our ideas, and just load files named "userwindow*.xml" or something. these would have to be generically handled in the code - basically they'd be useful mainly for popup menus and the like where hyperlinks can take you to different windows, and where "execute" commands can be performed.

i'm not sure if there's a need for other generic full screen windows, but am open to ideas of how we could deal with this case as well.

cheers,
jonathan

[floink]

i definatly like the idea of the standardised settings menu. both from a skinner and usability point of view.

the stuff youre talking about jmille01 is way out of my league. is there a short version to what youre talking about? aint: being 'just' a skinner i got it up to where youre saying you have several submenus in the same window.
that part sounds really interesting to me. if sub menus then could be combined with some kind of animation (slide/fade in and out) i believe it could be used in a favourable way. for example the new filemanager could have it's buttons back by using pop-up or fly-out or fading menus.

the scrolling home screen buttons is also a good thing i think and such a feature would also from a usability perspective partly benefit from a combined fade/scroll animation like the one seen in winmce.

[pike]

suggest before any devs start coding the new settings that we discuss the layout and what to put in there etc...

[jmarshall]

just a quick point:

the new filemanager has all it's buttons on the context menu.

i'm not sure if users have figured this out or not!