Skin Engine Suggestion

After seeing a lot of traffic about the work putting together skins and the soliciting of core improvements for 0.2, I make the following suggestion.

Problem
Everytime a plugin is created or sometimes changed, the skin must be updated to reflect that. There's several issues with this:

1. Frequent skin updates (every MP release and every new plugin)
2. As plugin development increases, skin update time increases
3. Prevents skin developers from spending time on new skins
4. Reason for some to stop and others not start developing skins.

Solution
Create a Skin Engine API that a plugin developer can use to create his/her UI. Briefly, define an API that would allow the skin developer create a skin "construction kit" which has all sorts of pieces in it (arrows, buttons, appropriate fonts, frames, etc.) that can be mapped to specific functions in the UI.

The skin developer would make a skin as normal. But when it comes to skins, merely puts all the various graphics and maybe blank buttons of various sizes and fonts to used on the buttons. This would all be defined by the API: graphic function (up arrow for example) and it's size in pixels.

The plugin developer would create a function within his code, include that appropriate graphic on the appropriate place on the screen (map it?) and then define the event when the graphic is pressed (onClick?). Obviously a developer would need some custom graphics such as buttons but that's why blank buttons, etc are in the library.

Some plugins (like weather) would have additional graphics but that shouldn't be the job of the skin developer, imho.

Other thoughts
I'm definitely not a graphic artist and my coding is limited to SQL, PHP, and HTML so take that into consideration. I'm dabbling in XML. My goal in making this suggestion is to lower the dev time of skins and skin development easier for all. I've been playing with a skin but I'm not going to even think about releasing it because I don't want to deal with the pain of updating it everytime a new release of MP is done.

So if this idea stinks... it stinks. Not going to hurt my feelings.

Cheers!

[butcherBoy]

no, it smells good

thought about a skin engine, too! it would be great.

i released my skin when version 0.0.0.12 was out and sometimes it is hard work to update all xml files, create new graphics for new or updated plug-ins ...

something like a skin engine could increase development of new skins and user don't have to wait for an update of their favorite skin when a new mp version is released.

the butcher

[MrMario64]

the thing is,
when you make an easy skin engine skinners want to have more power.
WHen we give them more power, they get more work and
Then they want an easier system....

With power comes more work.

The current engine has become like this because of wishes from the skinners!

And it would show better when people will use this power, as most ones just keep on using the default menu on the left, list on the right etc etc.

What I think should be in place, which i belive i mentioned earlier is that subdirectorys would be enumerated for plugins, which would contain the XML files for the skin, any non standard graphics, and dll/setting files, then when the plugin is loaded it would check the skin directory for plugin_name.xml, if found load that, if not found load local directory one, this way theres a standard interface which is avalaible to all skins, but also gives the skin developer the *option* of having more power to control that plugins interface this way plugins could be released witrhout a NEED to update the skin but as an option to the skin developer.
There are standard button names already used, maybe create some standard that defines the filename the button/etc is supposto have and what its purpose is so standardise things a little more, example

panel.PNG = Panel Frame
button-nofocus.PNG = Button NOT Focused
button.PNG = Button Focused
etc

This way plugin developers can use standard image file names in their XML and it would still look good having those standard names so you dont have the problem of well im writing my plugin for XXX skinn which has a blue look to it then if the plugins not implemnented in XXXred skin, it doesnt have a whole red look then all of a sudden blue buttons/etc, it would use the standard skin buttons which would consist of all of mediaportals controls.

Also another important part to look at while where here is langauge file, everythime a plugin needs to add another multi-langauge term it has to go in the main langauge file, I would say to extened the mediaportal loading to first check PLUGIN_DIR\strings.XML which would contain all langauge or PLUGIN_DIR\langauge.xml when loading a string from the plugin this way the plugin writer has full control of his string's/string ID's and if any updates are needed he simply realese a new installer/zip file not having to worryt about if his strings.xml file was up to date when he released it or if someone else is simotaniasly adding there own strings for their plugin and using same id's/etc

I think this would make MP's skin and plugin interface much better because all items will be in the plugins directory, all that is really needed is subdirectory enumeration and if a plugin uses this new method a check when loading the plugin is plugin_name.xml exists, if yes load it if not load your own copy

[tomtom21000]

Originally Posted by EvilDreamer

After seeing a lot of traffic about the work putting together skins and the soliciting of core improvements for 0.2, I make the following suggestion.

Problem
Everytime a plugin is created or sometimes changed, the skin must be updated to reflect that. There's several issues with this:

1. Frequent skin updates (every MP release and every new plugin)
2. As plugin development increases, skin update time increases
3. Prevents skin developers from spending time on new skins
4. Reason for some to stop and others not start developing skins.

I agree.

Solution
Create a Skin Engine API that a plugin developer can use to create his/her UI. Briefly, define an API that would allow the skin developer create a skin "construction kit" which has all sorts of pieces in it (arrows, buttons, appropriate fonts, frames, etc.) that can be mapped to specific functions in the UI.

The skin developer would make a skin as normal. But when it comes to skins, merely puts all the various graphics and maybe blank buttons of various sizes and fonts to used on the buttons. This would all be defined by the API: graphic function (up arrow for example) and it's size in pixels.

wouldn´t this lead to skins all looking the same?

The plugin developer would create a function within his code, include that appropriate graphic on the appropriate place on the screen (map it?)

This way the developper has to do the job of the skinner?

But I think it would be a good idea to have some things you propose, so that there could be standard elements, so that basic functions of a new plugin would work with any skin

[tomtom21000]

GregMM: You were faster

tomtom21000

heh, also another thing I forgot when loading all graphics from filename, because I belive MP doesnt take Bitmap object i think it just taked filename's, first check skind dir for filename.png, then check plugin folder for filename, as the main picture graphic will obviosly be custom, but since most are transparent should atleast look decent on whatever skin, I guess the plgin could check for the file and then respond with an absolute path of the file and not just file.png, although Id have to check weather that works and make sure its not trying to load "C:\program files\team mediaportal\media portal\skin\meia\C:\prog..... which it might just concatinate what filename you give it, but built into MP would be better as it just has to be done once not for every plugin, later

Well... I was just throwing out an idea. Here's what my understanding of the situation is based on the replies...

1. The skinners WANT to design the UI for each plugin
2. Most of what I suggested is already in place (just not always adhered to?)

Here's the big reason I made the suggestion.. Once (not if) MP goes mainstream, the plugins will proliferate. The possibilities are almost limitless. In a year you could be talking about 100 or more plugins. Do you, as a skinner really want to that amount of work for ONE skin everytime there's a new release? Even assuming that engine stabilizes so each new release doesn't require a skin update, and if you only have to doa plugin once and never look back, it still sounds like a lot of work to me. I think I'd rather remain a bystander.

The main idea with the "construction kit" was that each skin could define the image libraries so the the plugin would still use the skin and have that skin's unique look. Yes, the pluging developer does the skin for his/her plugin while maintaining the look and feel of the skin. But unless it's a "core" plugin (if there is any such thing) I don't think I would even want to look at all the possible plugins.

I hope I threw a couple of things out for you to think about and conisder. I think in the meantime I am going to see how some of the other projects do it and maybe clarify my suggestion. If not, I'll let it die peacefully.

Cheers!

[MrMario64]

we allready have a default place where everything is defined.
it's references.xml.

stabdard buttons r decribed there,
listviews, iconviet, togglebuttons etc etc.
the only thing needed in an xml file is a place for the button.

if you make the code determine where the button will be there will be no more difference in a skin.
So you will always have to have a place to put the place of the buttons.
same goes for width,
the one skins has wider buttons as the other.
Same with height,
color etc etc.

But, the default form of buttons and all are put in references.xml.
This saves you a lot from retyping everything,

[Mr.Mitchell]

In a way the programmer already defines a great deal of the look since the programmer defines the controls that have to be used.

One thing that would really help is a visual skin designer (like the one that has had a beta in one of the forums). Most of the time that I spend on making the XML is try put the controls on the right spot, start MP, see what it looks like, close MP, fix the errors, start MP again. Basically the same for navigation.

If the visual designer could have some kind of "magnetic" rulers like for example used in CorelDraw it would become very easy to align controls the way you want it. Maybe have some kind of template system for the skin so you can easily start a new screen.

And for navigation it would be really usefull if it could show with arrows from control to control how the navigation currently is setup in the skin and have an easy way of changing the navigation.

An other thing that would be nice is some kind of skin validator which checks if all images are available, do all controls fit on the screen, are all id's valid and more...

Hmm, I got a bit carried away I think.

As a skinner I really like to be in control of the skin, so the current skin engine suits my needs/desires. But as mentioned above a good tool could make skin developing easier and faster.