Skin Engine Suggestion (1 Viewer)

[Anonymous]

Okay.. all sounds good. I guess I had a mistaken impression. One of the big objections I was hearing about building skins was the amount of work involved. Like I said from the beginning, I'm no expert in this area. Just saw a lot complaining and thought I would make suggestion that could possibly help.

Bottom line is I like most of the skins I see. I must admit I've never consciously chosen a skin based on button placement but thinking about it I guess it does effect the overal asthetics of the skin.

Oh yeah.. thanks for being gentle and not "flaming" my ignorance. :wink:

Cheers!

 

[Anonymous]

well the idea I had would solve both problems, it would allow skin developers complete and full control over the interface, if they wanted, but if the default interface of the plugin looks good and was what they were thinking of implementing, then they can just leave it using the plugins default interface, its the besxt of both worlds, easyness of skin developement without having to code all plugins XML files themselves and the ability to completely customise the interface by using there own XML files, its completely backwords compatible witht he way things are now, so its not forcing all plugin writers to re-package there plugins, and if I understand what MrMario said about the refrences.xml we woulnt even have to specify images in the plugins defaul XML file, so image loading wouldnt even be a problem, all we would need would be sub-directory enumaration when scanning for plugins, its not really even needed but i would like having all plugin binarys, default plugin layout xml, plugin settings xml, etc all in one directory, it would just get too messy also if i release a plugin it can just be a seprate download, install all files to PLUGIN_DIR\Plugin Name\ rather then install some there, some in all the skins directory, some in the langauge file directory hopefully not overrideng someone else langauge changes, I think plugins/skins should be seprate downloads, not from the main MP installation except the main 4 skins, main plugins like weather, as plugin count grows its going to be impracticle to just keep packaging with the main download, MP is a 16MB download as it is, as we keep adding plugins people arent going to want to download a 50MB mediacenter then have to scroll through a hunder plugins, I think they should scroll through a webpage, find the plugins they want download the package and install, same thing for skins, not having to worry if skin A supports plugin B and if it doesnt getting an Error can t find blah.XML

 

[Anonymous]

I hear you GregMM. I use OO (Open Office) and dread doing the downloads because they are 50mb. So instead of downloading with every new release, I download about once every 6 months.

There has been some discussion of seperating non-core skins from the package. Maybe there should be a similiar movement for plugins?

 

[emp3r0r]

MyXaml

Anybody heard of MyXaml? It could be the answer to everyone's needs.

MyXaml offers developers declarative markup capabilities to your .NET 1.1 and 2.0, and ASP.NET applications using a markup language called XAML (pronounced as "Zamel"). This new technology will give developers and end users alike the ability to use an XML-based approach to dynamically define and use the application's interface.

MyXaml allows developers the opportunity to create user interfaces dynamically with ease. It allows the design team to take advantage of the architectural strengths of XAML. It supports scalable, vector graphics and 3rd party controls. And, it gives your users the option to modify the interface dynamically.

The important thing to remember with MyXaml is that it will work with any compliant class in any assembly. By "compliant", I mean one that has a parameterless constructor and uses public property get/set methods to interact with the different properties of the class.

[/quote]