Standardize Skin Items

[ComputerTimeCO]

Hi All,

As I'm creating the CTpvr TV plugin for Xlobby, It is very difficult to create a plugin that can be used by all the skins available. At least not with out a lot of work creating a screen for each and every skin. It would help if all skins had a few standard items i.e. buttons(blank), themes(fonts&colors), backgrounds etc. What I mean by standard is the name of these items need to be the same so a plugin designed on one skin with these standard items can be used in another skin with out creating a whole new screen. The plugin can even detect a skin change and create the needed xml files to run on that skin. The user would only have to add or remap a button to start the plugin.

This should make it a lot easier for skin developers. Currently when a good plugin comes around, it is the skin developers who do most of the work in implementing the plugin into their skin. This way all your hard work will be preserved and users will have the same look no matter what plugin they use. This of course does not mean that the skin could not be customized. Coming up with this thought was easy but to come up with the standard I'm sure will be plenty difficult.

I'll leave Steven and all you talented skin designers to give this some though and form your opinions.

Regards,
Carm.

[Colby]

My first thought on this is there is no way to make a standard, without taking away customization of the skin. I also figure that I can pretty much skin anything, so having a truely integrated plugin would be the first step, and making the graphics independent of the functions would be the tricky part for your plugin. Im headed to the jon to think this over, we'll see.

[jowaldo]

what if the plugin just included a mini generic looking skin, that was just basically the screens, eventgroups and images required for it, then skin makers could just copy those screens into their skin, and then cusomize it and make it more in tune to their skin?

Whenever Steven add's a new feature and shows it in his default skin, thats what i usually do (take the screens and eventgroups, copy them over to mine then tweak it)

Seems to work good for me, at least so far....

btw... how is the plugin coming along?

[ComputerTimeCO]

I'm not talking about making all the items standard. Just a few names on the buttons, main background and main theme(fonts &color). This will allow for a simple screen to be created by plugin developer with these few items. Like in my case, all I need is a few buttons to control the tv fuctions. The text and rectangle already have standard names but not their appearance(what I call theme). The plugin could be used by all skins because it will know the names of the main background, button and theme in order to create the xml needed as it gets loaded by Xlobby.

I've never used meedio but I've read that a plugin will automatically take on the look of the assigned theme. If this is true it would be easier for plugins to get created for that type of an environment. I'm sure there is a lot to think about here.

Regards,
Carm

[ComputerTimeCO]

what if the plugin just included a mini generic looking skin, that was just basically the screens, eventgroups and images required for it, then skin makers could just copy those screens into their skin, and then cusomize it and make it more in tune to their skin?

Whenever Steven add's a new feature and shows it in his default skin, thats what i usually do (take the screens and eventgroups, copy them over to mine then tweak it)

Seems to work good for me, at least so far....

btw... how is the plugin coming along?

My concern with current approach is if a skin is no longer under development. What happens for users who like the skin and would like to keep it. It may be a long wait before someone may modify the skin for the plugin. Not to mention that I would suck at making a generic skin. My designers eye is not quite up to par with you guys.

If you had some standard item name the eventgroups could be used by all skins that follow the naming scheme. The plugin would just have to copy that xml to the current skin's eventsgroup folder.

Keep in mind if skin designer want to enhance this plugin screen it can still be done. When the customized skin is released by the designer it will contain everything needed by the user.

The plugin is going quite well. Because of the nature of PVRs it cannot just live inside of Xlobby. Scheduled recordings should not need Xlobby running in order for it to record. So the nature of the plugin would be more for Live TV and Recordings viewing. You could also include scheduling and management of schedules, favorites etc.

Regards,
Carm.

[BaddaBing]

Hi Carm,
Requiring Xlobby to be more like Meedio is a BIG drawback in my book. When you skin Meedio you can change the way Meedio looks but you never really change the way Medio 'behaves'. All the buttons and functions are still in the same place and still function the same way- they just look different. Just look at these medio skins to see what I mean:



Other than button color and backgrounds they are all the same. Compare this to the look of the skins here in Xlobby, with a different skin Xlobby doesn't even look like the same application.

Skinning in Xlobby allows you to change the behavior of the application - you can define the order of views, the placement of controls and the logic carried out by each control (and IMHO, it's probably Xlobbys most powerful and endearing feature) This flexibility creates some difficulties for implementing your suggestion;

In order for a 'self skinning plug-in' to work all skins would have to use a default navigation schema. (a.k.a. Meedio) Otherwise, the plug-in would able to create a view, but unable to create a link/method/meu to access the view. And if you know Xlobby well enough to create the controls to map to a view, then taking a default view and integrating it into a skin is not a big deal. Also, once integrated into a skin, a well designed plug-in really doesn't require any additional work from the skinner.

Finally, how would would 'style' be addresses in the automated XML generation? Jowaldo's skin places most of the controls along the left and bottom, Colby's skin on the left and right sides, Dalanik's Visual skin leans toward center of the screen. At best, what it would provide is a default image assigned to the controls - you would still need to go in and make it 'fit' both logically and aethetically. Assigning an image to a control is easy - its the 'logic and aesthetics' that require the effort in skinning.

Anyways, good luck on the plug-in but (and its just my two cents) I'll have to pass on your suggestion.

[ComputerTimeCO]

Here is a screen made by a user name Mike that I modified a bit to use with the plugin. I think it is using 1 button image that make up all the buttons. If you take the xml file that Xlobby uses to read information on this screen and place it in the folder of a different skin. You end up with a screen with text but no button images. If you had 1 or 2 buttons with a standard name(i.e bnt1, bnt2), this would not happen. I've attached 2 images so you can see what I'm talking about.

I may just wait on finishing the plugin until Steve releases his new default skin. This way every skin designer could grab the plugin and customize their skins if they so choose to.

Regards,
Carm.

in proper skin folder


in different skin folder

[Aaron]

I think what CTO is saying, and I agree, is that being able to define system wide "objects" would help. If he could create a configuration file (which he includes within his plug-in) that creates specific system wide objects... this creates consistancy.

Also, this is useful when someone wants to have specific functions of thier own that never change even if they decide to change skins.

Makes changing skins easier, more consistant... just a plain better experience for the end user.

A true "skin" is just that... it holds almost no configuration, it only overlays images on top of predefined objects/functions.

[Colby]

A true "skin" is just that... it holds almost no configuration..

I disagree with this statement. True a skin can be just a shell to change the prettyness of a preset set of functions, but how you display and layout a GUI does add functionality or configuration. Would you not say a skin is "configured" for 16X9? That would be a result of the skin, not the program. I also whole heartedly agree with Bing, the skinning of Xlobby is one of the most powerful, advantages of this front-end. I would hate to just recolor, a whole page, and call it a skin. In fact Xlobby shouldnt even call them skins, they should be called muscles since they do so much.

Carm,
If youre only talking about standardized button names that is easy. I dont think it much matters to skin designers if we name our stuff the same, (ie. mainBG.jpg, or mainBar.png). The difference between our skins isnt really the names of things, as it is the functions we choose to implement in our skin, some have database menus, some have overlay controls, some have preview windows, some have show/hide images, fonts, etc., etc.

Are you saying this plugin would only have one layout for the screen and if we were to use it we would be constrained to this layout? Are you saying this plugin needs to define the images for the buttons in coding, and cant be defined by the user?

[Colby]

Here are some ideas,

If you want to constrain all skins to a uniform button name or bg or whatever, do it by use of the Button ID. If jowaldo, bing and I want a mute button in our skin, we all have to put mute as the ID, no matter what we actually label the button.png.

Make things renameable in the configuration of the plugin. Xoapweather plugin does an excellent job of this. He defined every image or information with a preset variable, but in the configuration table he left it open for us to rename anything we wanted.

Because of the nature of PVRs it cannot just live inside of Xlobby.

Dont make it live inside of XL. winamp and zoomplayer dont. If you can make a plugin that can be communicated too from xlobby thats all we need. We dont mind using commandline to talk to a program running behind, not in XL, as long as we can extract info and the player window we dont mind.

Use steven to implement a standard set of events or commands. He can create a folder for the commands and we can draw our event groups from it. We do it with winamp, why not the pvr?

[ComputerTimeCO]

Hi Colby,

If youre only talking about standardized button names that is easy. I dont think it much matters to skin designers if we name our stuff the same, (ie. mainBG.jpg, or mainBar.png). The difference between our skins isnt really the names of things, as it is the functions we choose to implement in our skin, some have database menus, some have overlay controls, some have preview windows, some have show/hide images, fonts, etc., etc.

Yes I'm talking about a few items in all skins having a common name allowing a screen's xml file to be used in any skin the user chooses. Now lets assume we had a few standard items. If I design a screen with these standard items, Xlobby creates an xml file. This file contains all the events that I assign to buttons, the button names, the screen location, text and more. I then create a eventsgroup that would contain all the events needed by my plugin. I would assign these events and default Xlobby events to my screen items(i.e. TV On, Off, Main Menu). Now if I copy these 2 xml files(screen & eventsgroup) to another skin, every thing should work the way it did on the other skin except it will now use the background and buttons of the new skin.

Keep in mind I'm only talking about standard names for a few items. Maybe the main items to your skin(main BG, Bnts, Font resourse, etc).

Are you saying this plugin would only have one layout for the screen and if we were to use it we would be constrained to this layout? Are you saying this plugin needs to define the images for the buttons in coding, and cant be defined by the user?

When I release the plugin it would have what ever layout I designed for it. Any skin designer could make their own layout without effecting the function of the plugin.

Sample of how my plugin would work in any designed skin. A TV plugin would need an area in the screen to display the TV. My plugin uses the ID of a rectangle named "videowindow" to get the size and coordinates of where the tv window would appear on the screen. So this will give the designer the freedom to place this rectangle any where on their screen and make it what ever size they choose. The text box works the same way as other plugins(plugin->XCTtv->Info) to provide information like the channel your watching etc.

Well I hope that anwser your questions.

Regards,
Carm.

[ComputerTimeCO]

Here are some ideas,
If you want to constrain all skins to a uniform button name or bg or whatever, do it by use of the Button ID. If jowaldo, bing and I want a mute button in our skin, we all have to put mute as the ID, no matter what we actually label the button.png.

My last post mentions how this would work. The button would be assigned events just like most if not all screens. The difference is that I would be providing the eventgroup xml file containing all the plugin commands. You can just use these events on your buttons.

Make things renameable in the configuration of the plugin. Xoapweather plugin does an excellent job of this. He defined every image or information with a preset variable, but in the configuration table he left it open for us to rename anything we wanted.

So far my plugin does not require this kind of structure. The nature of these two plugins are very different.

Because of the nature of PVRs it cannot just live inside of Xlobby.

Dont make it live inside of XL. winamp and zoomplayer dont. If you can make a plugin that can be communicated too from xlobby thats all we need. We dont mind using commandline to talk to a program running behind, not in XL, as long as we can extract info and the player window we dont mind.

Use steven to implement a standard set of events or commands. He can create a folder for the commands and we can draw our event groups from it. We do it with winamp, why not the pvr?

If all it needed to to was display the TV and control channel/volume changes that would work. My CTpvr app is already capable of working this way with any frontend type programs. One of the Xlobby users even create a small app that would open CTpvr from Xlobby. This only help to show that a tighter integration was needed. I think it needs to work via a plugin.

What I meant about living inside of Xlobby was that PVRs require 24/7 monitoring. A user should not have to have Xlobby runing in order for recordings to take place. This means that a plugin alone would not provide these other solution like recordings, EPG updateing, Favorites(season) scheduling. You need a less visible solution like CTpvr, Sage, BTV to provide these backend PVR functions.

Regards,
Carm.