[Livin]

Lately there are tons of new, amazing, skins popping up (very good thing) and an equal or greater amount of modders (another great thing).

One thing that would help users and modders is a way to easily add/substitute both themes and XMLs (modded screens).

Today we need to directly add to / change / delete existing XMLs / XPRs multiple folders... 720p, colors, media

One major issue I found is where when the skin revs, it wipes the mods and themes.

It would be nice to leave the stock skin in tact and have a folder under User Data that added/sub'd the files there in place of the stock skin.

A thought would be to mimic the 'addon' folder under the 'Userdata' folder. This way, the user could simply make changes there and also backup all needed info from only one spot - Userdata.

Then any skin updates automatically happen and the user's mods stay in tact.

thoughts?

[giftie]

Lately there are tons of new, amazing, skins popping up (very good thing) and an equal or greater amount of modders (another great thing).

One thing that would help users and modders is a way to easily add/substitute both themes and XMLs (modded screens).

Today we need to directly add to / change / delete existing XMLs / XPRs multiple folders... 720p, colors, media

One major issue I found is where when the skin revs, it wipes the mods and themes.

It would be nice to leave the stock skin in tact and have a folder under User Data that added/sub'd the files there in place of the stock skin.

A thought would be to mimic the 'addon' folder under the 'Userdata' folder. This way, the user could simply make changes there and also backup all needed info from only one spot - Userdata.

Then any skin updates automatically happen and the user's mods stay in tact.

thoughts?

Though I'm not a skin developer, there is a problem with this.. If the Skin updates contain changes to the XML's that the Mod also contains, this probably will cause breakages. This would especially be true if the Skin requires the changes.(often often can crash XBMC as well)

Another way would be to edit the addon.xml file and have a duplicate skin(ie skin.confluence.mod)

[Livin]

Though I'm not a skin developer, there is a problem with this.. If the Skin updates contain changes to the XML's that the Mod also contains, this probably will cause breakages. This would especially be true if the Skin requires the changes.(often often can crash XBMC as well)

Another way would be to edit the addon.xml file and have a duplicate skin(ie skin.confluence.mod)

I don't see this as an issue... it is no better or worse than it is today.

duplicating the skin defeats the purpose - using custom mod's with the latest tweaks/fixes of a skin.

My suggestion solves a need for skins that are more in steady state with minor updates and tweaks... as many are. And it solves the real problem of skin updates completely deleting themes.

the

[stoli]

I'm by no means a developer, but if something like this were to be implemented I think the simplest method would be to look for "<folder>_Custom" and if there are files in there, they should take precedence over the standard folder.

Example:
|-skin.neon
|--->720p
|--->720p_Custom

If in 720p_Custom there is a "DialogFullScreenVideo.xml" it will be used instead of the one contained in the default 720p folder. If it breaks, so be it, at least the original will be in-tact and they can just remove the offending file/folder.

Just my quick 2 cents.

[ZombieRobot]

what if the user wants a mod for dialogvideoinfo.xml and one for home.xml but both have a edited includes.xml you wont be able to have both the same for textures someone may do a mod for something in a skin and add or change a texture that may be used somewhere else it would be cool if we could have something like this but cant see how it could work

[Hitcher]

We've covered this ground before and there wasn't a definitive answer to the problem of skin changes that would break the mod.

Best solution is for the modder to keep their mod up-to-date with the skin.

[Livin]

We've covered this ground before and there wasn't a definitive answer to the problem of skin changes that would break the mod.

Best solution is for the modder to keep their mod up-to-date with the skin.

There will not be a perfectly seamless way but the one I proposed is as close as you can get.

Create a mirror of the 'addons\<skin folder>' folder inside 'Userdata' (thus 'userdata\addons\<skin folder>
... the skin engine can load the regular skin folder and look for an substitutes inside the userdata folder's mirror.

* requirement: user will need to keep the mod they use in sync code wise for it not to have issues

* benefit: updating the original skin will not delete the mod so if the update was something that does not affect the mod it is seamless, and secure (no deletions)

* limitation: this method would allow one mod per skin unless there was a scheme to allow more like this... skin.name.mod1 ; skin.name.mod2 ... but this would require more coding and a UI to select and I don't think it is necessary.

JM is a wizard, I'm sure this would be simple for him to do.

[pecinko]

I'm pretty sure JM won't implement it.

Why don't you just copy original skin, rename it, put modded files in place. Then just copy original when updated NOT overwriting mod files?

[Livin]

Why don't you just copy original skin, rename it, put modded files in place. Then just copy original when updated NOT overwriting mod files?

Because that does not solve the issue.

[Jezz_X]

I thought I posted this last night but must of forgot to hit send

The only way it would work is with some kind of version system like svn or git to keep track of all files changes what changes were made and when a mod of a skin was branched off so it knows at what point to use the old code as a base

And its just way too complicated and probably won't ever happen when really its easier for a modder to release the skin with the version its intended.

example doing changes to the main version of confluence like this would completely break any mods done on the fly because I changed 4 xmls deleted 2, added 6 images and deleted about 10

[Livin]

I thought I posted this last night but must of forgot to hit send

The only way it would work is with some kind of version system like svn or git to keep track of all files changes what changes were made and when a mod of a skin was branched off so it knows at what point to use the old code as a base

And its just way too complicated and probably won't ever happen when really its easier for a modder to release the skin with the version its intended.

example doing changes to the main version of confluence like this would completely break any mods done on the fly because I changed 4 xmls deleted 2, added 6 images and deleted about 10

It would not need to be that complex as I'm talking about allowing what I will call "private" mods, not a full modded skin release to the public. This is for the numerous people like myself that modify the skins for personal use by changing a few XMLs and adding a theme or changing some images.

Everyone is making this WAY more complicated then the intent so I guess I'm not getting my point across properly. I will use my specific case as an example...

I use Alaska Revisited. It is updated often and when it does my personal (aka 'private) theme and the XMLs I have modified get deleted since they must reside in the same folder and the entire folder structure 'skin.alaska.revisited' under 'addons' is reset.

If we simply add a duplicate folder structure (manually by the user - not by svn/git/etc) under 'userdata' so the user can place their changed/added XMLs and themes... then have the XBMC skin engine load the userdata folder structure after it loads the regular one... it will replace/add the user's XMLs and themes.

[Hitcher]

If we simply add a duplicate folder structure (manually by the user - not by svn/git/etc) under 'userdata' so the user can place their changed/added XMLs and themes... then have the XBMC skin engine load the userdata folder structure after it loads the regular one... it will replace/add the user's XMLs and themes.

That's no different than just keeping your modded XMLs, images, etc in a separate folder and simply copying them over the skin when it updates though. And, as said, in many cases this will break the skin anyway and it doesn't seem worth adding as a feature if it's not going to work 100%.

[loggio]

Agree with Hitcher ^^