Request for generic menu items between skins (1 Viewer)

[cul8er]

Hi,

For me every skin editor that want to support the generic settings file is responsible for;
1. Load the settings file from MediaPortal config directory (be able to parse it)
2. Save any adjustment an user do in the editor to that same settings file.
3. Write a basichome.xml file for the skin that the editor supports.

In other words. We only need to agree;
1. What is the filename of the settings file
2. What is the xml file to look like

Then we are done.

The plugin id's are loaded dynamically in every editor I have tried today (like StreamedMP, Aeon, X-Factor) so no need for an additional window id file.

I'm sorry if I'm a bit harsh here but I think the original idea that a bunch of skins "bought into" with a common settings file is to good and important to drift away from but that's only my two cents. I'll keep quiet now

best regards
cul8er

 

[n4orcer]

Hi,

For me every skin editor that want to support the generic settings file is responsible for;
1. Load the settings file from MediaPortal config directory (be able to parse it)
2. Save any adjustment an user do in the editor to that same settings file.
3. Write a basichome.xml file for the skin that the editor supports.

In other words. We only need to agree;
1. What is the filename of the settings file
2. What is the xml file to look like

Then we are done.

The plugin id's are loaded dynamically in every editor I have tried today (like StreamedMP, Aeon, X-Factor) so no need for an additional window id file.

I'm sorry if I'm a bit harsh here but I think the original idea that a bunch of skins "bought into" with a common settings file is to good and important to drift away from but that's only my two cents. I'll keep quiet now

best regards
cul8er

Ahh then I've misunderstood things a little. I will still continue to work on the application and release it as perhaps someone could find use for it and I need the training.

I only looked a little at StreamedMP's config tools source and just thought it would been nice to try to build a "complete" XML file that contains that information, but if other editors just does it at runtime and displays what is installed then that function is a little redundant to do.

You don't sound harsh and I do value your input, I can see I have misunderstood things and perhaps Ill try to steer this project in another direction, perhaps as an generic editor or something that skinners can use if they do not want to write their own.

NOW lets get agreeing on the skin file and XML structure and force the devs to add it to the release of 1.2. As you said, the idea is too good to go to waste and we probably need to involve more people, those of you that are "bigger" in the community could perhaps ask the other skinnes/developers to read trough and get their input down here so we can finalize the structure of the XML file.

Anyway ill stop rambling about that now and return when I've have something to show (Probably in a new thread so I dont clutter this one).

 

[kyleh0000]

Hi All,

My nexus menu editor started as a menu editor for BlackGlass but i was able to modify it to be used with any single level skin that is one bacsi horizonal or vertical menu, pictures or no pictures it works fine.

I have got plans to implement a multi level option for skins and i belive it can be done but i have not had time to properly explore how I know how it could work in my head i just havent started the code for it.

As has already been mentioned in this thread i have been EXTREMLY busy in real life and I dont think ill get much of a chance to work on this before the end of the year because of this, but im sure you all understand real life comes first

They way my editor works is using template files, bascily the skin designer would create a template file for a menu item and a then the editor would fill in the blanks with what ever items the users wants, this works the same for backgrounds and fanart. To support the black Glass nova menu I also implemented a generic post processing option where by included in the template folder would be a batch file that would call what ever commands were required to process images for the menu.

im more than happy to provide the source if someone wants to pick it up, but if not the project is NOT dead its just on hold untill probably the start of next year.

This was my attempt at exaclty what is being asked for in this thread it would just require the skiners to provide the templates, which would often mean less work for the skiners.

Here is a quick example but please see the editor for more details....

Nexus Menu Editor

<control>
<description>Menu_item_#ID_IN_Right</description>
<id>#ID01</id>
<type>button</type>
<label>#LABEL</label>
<font>#MMFont</font>
<textYOff>0</textYOff>
<posX>425</posX>
<posY>#TOP</posY>
<height>80</height>
<width>430</width>
<textXOff>0</textXOff>
<textYOff>0</textYOff>
<onleft>#PREVA02</onleft>
<onright>#NEXTA01</onright>
<onup>21</onup>
<ondown>1000</ondown>
<textureFocus>-</textureFocus>
<textureNoFocus>-</textureNoFocus>
<colordiffuse>#DIFFUSE</colordiffuse>
<textalign>center</textalign>
<hyperlink>#LINK</hyperlink>
<visible allowhiddenfocus="true">Control.HasFocus(#ID01)</visible>
<animation effect="slide" start="430,0" time="400" acceleration="-0.4" reversible="false">visible</animation>
</control>

So in the example above the editor would take the menu template and replace the variables in it with the ones chosen by the user, so #LINK would be replaced by what ever link the user needs and #NEXTA would be replaced with the items that goes on the left of it.

I haved had time to docuemnt all of the variables but i have put a lot if there and also in the upcoming version these will read from an ini file so users can add there own variables and even skiner who make templates can include any extra variables they require in the template files.

Like i said you will get a better idea of how it works when you look at the full template

Currently there are some issues with the templates due to changes in the Fanart Handler and also the MP info services but these changes just require changes to the templates.

Like i said im happy to provide the source if anyone wants to pick it up, if not ill continute to work on it my time is just very limited at the moment, but i should be able to spend a bit of time on it after xmas when i get back from my honeymoon

cheers

KYLe

 

[infinite.loop]

Usually I do not like to bump old threads, but this is kinda no request.

Many of the current community skins come with an editor for customization.
While this is great in general, I find it very bad for usability that every skin comes with its own (sometimes identical to others skins) menu editor.

What I'd love to see is one menu editor available in our repository, which will be able to be used for any skin, not just a specific one.
This would definitely make things a lot easier for our users.

 

[mbuzina]

Just as a side not: If the idea of the overall menu configuration file is resurrected, would it be possible to add an XSLT Transformation script for each skin the generate their basic home.xml out of it? Thats what xslt is for (transfer one xml to another one). This would remove the whole horizontal vs. vertical menu issue (as basically it is just the way you want to hold your tree ;-).

 

[infinite.loop]

Another note
Soon the 1.3.0 development cycle will start - so if we have to do something to make this generic home menu editing to work, then we must get to a conclusion asap!

 

[cul8er]

Hi,

I like the idea with one menu editor very much but it would be a huge task. We would have to make it incredibly "smart" and configurable from a standard configuration file not to limit the current possibilities. It would be almost like a skin editor

Think of things like;
* all possible menu layouts must be supported (horizontal text, horizontal text with submenus, horizontal pictures, horizontal pictures with submenus, vertical text,vertical text with submenus,vertical pictures,vertical pictures with submenus, other menus like the "x-factor" menu in the x-factor skin that used combinations of the previous.
* all possible animations must be supported for images, and or text with different speed, effects and directions.
* adding startup parameter support to plugins in menues and submenues
* many of these skin editors also is process plugins and extends the current capabilities of MP in different ways to add more capabilities to the skin than possible out of the box
* rss support or not (infoservice)
* weather support or not
* fade stuff on screen or not in idle (like a screensaver)
* display clock or not (analog or digital)
* ...
* ...

And more important doing all the above without constraining skin release cycles. In MP we limit the number of plugins included in the core not to limit bug fixes and releases of new plugin versions and we must do the same here.

But can we find a good way to do this I'm very willing to help in any way I can.

Just my two cents.

best regards
cul8er

 

[catavolt]

AW: Request for generic menu items between skins

Well analyzed...

 

[trevor]

Hi,

Just seen this thread has kicked off again, I agree with cul8er that this will be a huge task with considerable challanges.

I know from when I did the Mustayluca editor, which I had every intention of modifiying the StreamedMP editor to do both and just change it's behaviour based on active skin just how tricky this is.

The idea of a generic self-contained editor that uses some form of template would limit the basichome design to the capabilities of the editor.

If I was to do another editor it would be a framework design, the basics could be built in here, menu structure, layout, plugin parameter handling etc. and would be extensible by using plugins to provide additional settings and generate the xml.

This of course means that coding would still be required but this approach would be easier to achive than trying to come up with an all singing and dancing editor that can do everything, not sure that is possible and create an editor with a std look and feel whist allowing free form basichome design.

Just my thoughts

 

[ajp8164]

Hi all,

Didn't read the whole thread (disclaimer) but from the initial few posts... I created a capability that should make MP1.3 called skin themes. Skin themes allow you to essentially make small changes to a base skin using a skin subdirectory structure. The main intention is to allow for users to vary images, colors, fonts - the basics, but it can be equally applied to making more radical changes. For example; a certain skin theme may completely override a whole plugin giving that plugin a custom look/feel/operation.

At the moment the description of this and other features targeting 1.3 is on our internal team forum and the code is on my branch (ajp8164_13).

Thought this would be worth a mention here. Hope its relevant!