View Library for use in all skins - e.g views are objects
#1
Lightbulb 
Thought for discussion...

Problem Statement:

Numerous posts over time requesting Views which are in skinX to be put in skinZ. The issue here is today Views are specific to the skin.

Proposed Solution:

View Library which stores Views as objects (or set of) where all Skins can draw from. Views could be "installed" into the library and thus become available in all/any skin on the system, via the Skin Settings.

Considerations / Assumptions:
(I'm sure there are more but I wanted to get the ball rolling)

1) View object
Would need defined sub-objects with properties so that the skins can handle them in a universal way... menu area, image area, text area, all with properties similar to what exists today on other objects


2) Skin
Would place these sub-objects in similar to an HTML iFrame and any code that currently works (animations, etc) would be included and should work the same as it does today.... it could be like moving around lego blocks.



Commentary...
I believe giving the user a choice of any, or nearly any, View in any skin goes a long way to end-user customization. This methodology would also allow people without time to create an entire skin, or whom already have an existing fav skins, to contribute by creating Views to share with the masses.


Please give feedback, thank you. Big Grin
I'm not an expert but I play one at work.
Reply
#2
You're assuming the reason for skinX's view type not being in skinZ is purely technical, whereas it's usually aesthetic. I know I wouldn't want coverflow anywhere near my skin, for instance. You're also proposing a kind of design universality which would, imo, go against the best interests of skins in general.
Reply
#3
This is done in other HTPC apps like Meedio and works perfectly fine. It eases development of skins, makes things easier to understand for end users, etc. If aesthetics are that important to the skin designer that he/she would remove options, then give them the ability to do so. Just a parameter with a list of the allowed view possibilities for that spot.
Reply
#4
You should be able to already take any view directly out of the skin and dump it in another, assuming it's done via an include which 99% of skins use.

Ofcourse, you need to take all the includes that the skin uses, plus resolve any texture naming conflicts and font conflicts and so on and so forth.

Plus the fact that it'd look sucky on any skin with different dimensions for views and so on, plus the navigation may not work at all in the skin.

Forcing the skinner to adopt a particular form of naming, navigation, and sizing conventions is an option, but honestly, there's enough people in the community and enough hacking of skins already that I really don't think there's any limitations in place that people aren't already prepared to work around. Plus as it is now allows creativity of skinners to do things that I never thought would ever be possible.

Let's face it: 99.9% of users are happy with using a single skin as it is. Those who aren't usually have the skills to add a mod or whatever.

You'll have to come up with a pretty iron-clad "how it should be done, what the problems are, and what the solutions to those problems would be" that the skinners themselves are happy with before I'd consider implementing something like this.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#5
As szsori stated, several other front-ends have done this and it works out well.

XBMC does not have what many would consider "true" skins (this is not intended as an insult, just comparison to other apps). Traditionally an app skin overlays graphics and layout on already existing code... Winamp and about dozen other popular apps come to mind. This is why it is called a skin and not a "muscle"... no joke, this is how it got its name "skin".

XBMC's "skins" actually extend the back-end code and navigation engine, which is why views are not easily portable.

I disagree that making Views portable and having a View DB would to anyone's disadvantage... I think it would enhance the end-user experience (let them choose the view they want, not tied what the skinner thinks is "best"), make skins easier to develop (much easier code reuse, less custom coding), and you might even get more end-user coding participation like you have with scripts/plug-ins.

I respect djh and other skinners but in the end... isn't the skin for the users, not only the skinner? What do you care if the end-user mods the skin and puts in views they like? When my friends/family see it they never ask who made it. What would I tell them... djh? The only people that know and care are us in the community. Why not allow people to choose a skin due to the style, not just a view they like?
I'm not an expert but I play one at work.
Reply
#6
One of the biggest benefits is that users can easily transition to new skins without having to completely rework their thumbs, library structure, etc. I've posted elsewhere about Meedio's library system, which works hand-in-hand with the skins, and I honestly believe it's by far the best method out there. That's not to say there's anything wrong with XBMC's method, although I do think it's overly complicated and doesn't have the same user-friendly feel that Meedio does for the end user. However, XBMC makes up for this by being far easier to initially set up and use.
Reply
#7
Moving between skins I agree needs to be as seamless as possible. One of the problems is that some skins use predefined source paths for stuff when ideally they shouldn't (or at least they shouldn't by default). Other than that, though, I can't think of anything I've ever had to muck around with to get a skin going well. I'm more than happy to work on making this less hassle for both the skinner and the user if anyone has ideas in this regard.

I must agree with djh_ in that views are in general unique to the skin due to aesthetics, rather than due to technical restraints. Compare Aeon and PM3 for instance. Very few of the views would be transferable between the two without quite a bit of work, assuming one wants the view to look as if it's actually a part of the skin and not a tack on. This is due to more than just the basic layout (thumb/list/coverflow/wraplist) of the view - it's about how skin layers textures, how it animates, and how it works in with the surrounding controls.

I think it would be difficult to get a transferable view system in place without placing strict limitations on how said views would look and function, which in some respects defeats the purpose of it.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply

Logout Mark Read Team Forum Stats Members Help
View Library for use in all skins - e.g views are objects0