Kodi Community Forum

hi all,

it's your favourite destroyer of all skins again.

we've recently been discussing the idea of combining the thumb + list controls together into 1 "composite" control that has the list + thumb controls etc. as subcontrols. the advantage with this is we can have 2 (or more! separate thumb controls with differing sizes etc. instead of having all the various options defined (ie 2 different itemheights etc. etc. as there is currently).

the "view as" button would then interact with this new control (possibly being a part of it??) - filling up with the number of views that it contains etc. obviously xbmc would have control over exactly which views are allowed in some cases (just as it does now).

now, i haven't nutted out the details, but as this would ofcourse break all the skins, i thought i'd let you guys have some input on the issue.

the advantage of it would be that you could have 2 list views (as is in mymusicalbums) and 2 thumb views on top of that. or, we could define a new view that can't be layed out with the current list + thumb views to handle a different type of view (eg details view, or a large right-left scrolling thumbs view for instance.)

please let me know what you think about this. obviously it'll only go ahead with you guys' agreement.

cheers,
jonathan

i think this is a good idea.

could you also allow for user defined views?

this would allow the skinner to creatively come up with custom views.

@jonathan

all skin-things you made in the past were great.

maybe a little offtopic, but a view with the use of imdb-info would be great.

like this

bobrooney: thanks for the support.

that is the long-term goal - to be able to have alternative views available. for this, however, we need a more general framework in place to handle the different views - thus the idea of the "view" control that then contains all the different types. naturally, it also makes sense from the code side of things.

naturally i'll hold off till i get other opinions - it may well be that i'm barking up the wrong tree and there is a better way to achieve this type of thing.

well if choke and other skinners hold to pattern.... a short time after you do it it'll be resolved in a current skin... could even tie choke into it for his pm3 skin since its still on the drawing board.

bottom line, if you get started on the concept by the time its reasonably perfected skinners should/could be current. if you want go ahead i am all for it, but i will be waiting obviously on my local until a skin is setup for it then its time for another upgrade .


sorry jm i just read things a bit more closely.. as i am not a skinner i should not have even offered my 2 cents in the matter.

i think the idea is good and the benefits should be worth the hassle.

any change that gives the skinner more options is good. do you think this is something that will be available soon? we are just now working on those screens and could hold off if it is.

it won't be available for at least a couple of weeks. i probably won't even start working on it for at least a week or so.

the change will be fully planned out and will be fully detailed here before it goes in to cvs by at least a few days, and hopefully a week or so.

it will involve an increase in version number, and we'll likely define/change a couple of things at the same time (to reduce code overhead in xbmc that is there atm)

cheers,
jonathan

hi jmarshall, i don't understand exactly what you are going to implement, but all kind of improvements are always wellcome, doesn't matter if i'll have to rewrite the skin.
btw something like this will be nice too:

two lists (one is enought too) and a thumb for the focused folder with the album info.

(kotix @ feb. 21 2005,14:09 Wrote:two lists (one is enought too) and a thumb for the focused folder with the album info.

and in my programs we could display a preview video for the focused game... aint:

i would have absolutely no problem with making any necessary skin updates, but does xbmc really need more "views?"

the xbmc interface is already pretty cumbersome (or perhaps cluttered is a better word) and i would rather see the existing views tweaked, modified, or replaced instead of having additional views added. changing the "view as" button from a simple toggle into a button that cycles through a whole bunch of different views that vary depending on what page you are on just doesn't sound like a good idea to me.

just my 2 cents. i'm sure nobody here will agree with me... :p

we definitely need more views... and actually we need to be able to "assign" views to specifc pages on a user-by-user basis.

i'd like to hide the views option on specific screen(s) if i want to assign that screen only one view.

we need to be able to have different views for different types of items... i want avis to show me small icons while having mp3s show me the album cover. this would enable me to view two types of files on the same screen and have each look "correct" instead of having a darn generic icon for the file.

the ui needs the flexibility of many more views. this coupled with the ability to assign specific file types specific icons and or methods of defining what to show in what situations.

hope that is not too muddy of an explaination. i can clarify further if you'd like

affini: you can already define icons on a filetype basis. mixing music + videos only seems viable to me in the case of music videos, and even then is complicated as the music videos don't have metadata information.

pin87: i agree with you to a point. the interface is cumbersome, but i'm not sure how to simplify it. any ideas you have would be most welcome - practically anything + everything is welcome at this point.

we won't all agree, but hopefully we can come up with some genuinely good ideas that can simplify the interface. that's the goal - not just to add new views for new views sake, or to satisfy the odd user here and there - but to genuinely make it easier to use.

the idea of combining the views into a single control simplifies things from the skin programming side and the xbmc code side as well. it also allows us the flexibility to try new ideas to see if they're an improvement. hopefully we can construct a gui that can clarify + simplify the users experience.

so throw out everything you know about the current system - what should it look like, feel like, etc.

cheers,
jonathan

(jmarshall @ feb. 22 2005,07:40 Wrote:hopefully we can come up with some genuinely good ideas that can simplify the interface.  that's the goal - not just to add new views for new views sake, or to satisfy the odd user here and there - but to genuinely make it easier to use.

amen to that!!!, can i have a hallelujah for eveyone trying to make xbmc fool-proof?! :thumbsup: ..."xbmc, a user-interface for dummies" aint:

jonathan,
i have several cases where i'd like to mix filetypes onto a single list.

here's some examples:

1) "most popular" screen : this screen would hold a list of the most watched movies, tv shows, listened to music, etc.

2) "system demo" screen : this screen holds both video (avi/mpeg) clips and music files (mp3,wav) that demo my home theater system.

3) "newest media" screen : simular to "recently added media" but displays all types of media (music, videos, and games) in a single list.

if the view could include all file types and display them appropriately (the way i choose for each file type) then i could easily make a screen that fits my needs.

i think one way that may make the view definition easier is if we could define default display types for each type of media. but, allow this to be overridden at the screen level.

for instance, in the definition file...

<avi>
display as small icon - imdb image
text is folder name - display on right of icon, scroll

<mp3>
display as icon - \folder.jpg
text is id3 tag.name - display under icon, word wrap

<game>
display as large icon - imbed.cover
text is imbed.name - display under icon, scroll

<picture>
display as small icon - thumb
text is exif.name - display under icon, scroll

this way we could define specific views any way we need to so to accomidate having any/all defined file types with the view's display