[Hitcher]

Cool, will that make it easier for us?

[jmarshall]

It'll make it easier, yes. You may, however, lose some flexibility (and you'll gain some as well). You'll have spinners and sliders, but you'll lose some of the ability to have "pretty" background selectors and the like.

I like the idea of simplifying the dialogs. How do you see it going? Perhaps a template file or something that XBMC uses to place everything? Let's nut out the details and we can pop it up on trac so I can work on it when I have a spare moment

Cheers,
Jonathan

[Jezz_X]

the way I see it is we have a template set for every rarely used dialog and then we have a new file called defaults_dialogs.xml or something like that and in that we define how we would want all the various backgrounds buttons and text to look then you auto make up the dialogs with that in mind.

Of course the other option is use the current defaults.xml and add another one for a texture called dialogback or somthing but I must admit I have let my defaults.xml slide a little because I tend to override everything with includes

[jmarshall]

There's nothing special about defaults.xml - you can define a default in any include file AFAIK.

If you guys flesh out the idea in a little more detail (eg basic layout of what any template files would need) so I can get a better handle on what the XBMC side would do, I can look at it once Dharma is out the door.

Cheers,
Jonathan

[wyrm]

There's nothing special about defaults.xml - you can define a default in any include file AFAIK.

If you guys flesh out the idea in a little more detail (eg basic layout of what any template files would need) so I can get a better handle on what the XBMC side would do, I can look at it once Dharma is out the door.

Cheers,
Jonathan

Jonathan and others,
Having only just got an old skin upto date with Dharma could I put in a request that if you run with this idea that you leave the option of using the old dialogues. That is if the old dialog file is found use that, otherwise use the new template file instead. That way you will not break older skins, but you still have the option of using the new dialog template file.

Wyrm (xTV SAF)

[Jezz_X]

wyrm I agree that if the old xml is found then use it instead of a default template this is more a way to get rid of 20 xml files and with a few standard controls auto build the rest.

The elite skinner is always going to want to have complete control over everything take the mc360 skin for example it would look half as good without its custom layouts. But in reality for all the odd rarely seen dialogs most skins all use the same layouts (copied from the default skin) with different textures and fonts because its easier.

In a ideal world current skins shouldn't be effected since they have already done them all but newer skins would get 20+ xml files replaced by 1 common elements xml making it easier and less time consuming to make new skins.

The hard part here is deciding on whats the best layout to use for a default dialog do we just take the button layouts from confluence and call it the best way or try and come up with completely new ones

[mcborzu]

I think if we handle these common dialogs sort of along the lines of the way the context menu is handled that would really help. Like all we do is make a texture and define the font/color and XBMC does the rest. Something kind of like that....

[wyrm]

Guy's while I have no major problems with the default dialogues idea if I could get back a little to the original idea and ask about packaging (and including in the repo for download) themes.

At the moment my skin uses a script to download themes (and it's currently broken for everything but the xbox). It would be really handy to have a way to download a skin theme from within the repo. Maybe if we had a way to package up a theme (a colour.xml file and a corresponding .xbt file) or even take it one step further and include modified .xml files that could replace the skins current files we could make it very much easier to mod existing skins.

This would also allow the mix and match of views that MacGyver is after and also minor modding of the skin as required. If you are after something more I guess you do as I did and Fork the skin and make a new skin.

Wyrm (xTV SAF)

[jmarshall]

The "mod" idea will only work if the mod is constantly updated when the "parent" skin is updated. I'm not convinced that this will happen enough. It will also require the repository to hold old versions of skins (not necessarily a bad thing, and it's something we'll need with Eden vs Dharma repos anyway), else anyone using the mod skin will be SOL as it will potentially break when the "parent" skin updates.

Few folk use themes which is why there hasn't been a focus on them as yet. Possibly because they're not really what folk are after - you generally want to change more than just colours and textures. These have less of versioning issue than XML changes do, but still have versioning issues.

What it comes down to is it's a non-trivial problem that currently at least has a "cheap" solution (albeit not very elegant, and not yet implemented on the repo side) which is provide the themes or mods as separate skins. This is pretty much what happens today anyway.

In order to get more mod-friendly, skins would have to become much more modular than they are currently. This is hard as you have to basically design the skin so that it can be modular (i.e. define standalone chunks that have basically no dependencies).

Cheers,
Jonathan

[wyrm]

The "mod" idea will only work if the mod is constantly updated when the "parent" skin is updated. I'm not convinced that this will happen enough. It will also require the repository to hold old versions of skins (not necessarily a bad thing, and it's something we'll need with Eden vs Dharma repos anyway), else anyone using the mod skin will be SOL as it will potentially break when the "parent" skin updates.

OK you got me there Jonathan, "SOL", what's that?

Few folk use themes which is why there hasn't been a focus on them as yet. Possibly because they're not really what folk are after - you generally want to change more than just colours and textures. These have less of versioning issue than XML changes do, but still have versioning issues.

What it comes down to is it's a non-trivial problem that currently at least has a "cheap" solution (albeit not very elegant, and not yet implemented on the repo side) which is provide the themes or mods as separate skins. This is pretty much what happens today anyway.

In order to get more mod-friendly, skins would have to become much more modular than they are currently. This is hard as you have to basically design the skin so that it can be modular (i.e. define standalone chunks that have basically no dependencies).

Cheers,
Jonathan

Just thought I should throw the idea out there. As I said, to provide theme support at the moment I'm having to include a script and I know how much you love skinners constantly adding scripts to get around xbmc shortcommings . Also I'm sure adding scripts to a skin is not a good way to get into the official repo. That said, I have not really bothered with themes other than the white theme that was in the skin originally, so the skin has moved on a bit from the theme-able version that it was in the past. Theme packages just seems a good way to support an existing feature of xbmc, the mods idea is just taking the idea to it's illogical extreme.

Wyrm (xTV SAF)

[MacGyver]

Well the versioning could help not to break mods, or at least let you know that it is going to possibly break. If I have "Night 1.1.3" and an update to fix something minor comes out (xml changes to fix position) the update would be "Night 1.1.4" but if an update to the textures or a major xml update is involved, just go with a "Night 1.2.0" and would prompt you about compatibility with your current "Night 1.1.3.3 Home.xml.mod" becoming broken. "The last "3" denoting that its the third MOD created for this skin. Mods could be required to contain a dependencies list and any updates could be checked against that list, with a prompt about possible problems, but since the MOD files are named different than the original, ".xml vs. .xml.mod" updates would not necessarily break the MOD. And they could be turned off and on, because the original is still there.

Again just an idea.

[vajonam]

a MOD could be a extension of a skin for example my addon could be an extension for Confluence 1.1.0, (which is essentially a modified Home.xml) if its upgraded to 1.2.0 then the addon that depends on the 1.1.0 is disabled until the author for the skin extension add updates his to work with 1.2.0. just a thought.