[djh_]

I've always liked the idea of mod support, though the problem has always been importing new code on top of old code and removing it without causing irreperable harm. That and it isn't really "mod support" so much as editing text.

What would be great would be some kind of object-orientated approach to modding skins, much like the way Unreal Engine makes it easy for mutators to override basic classes in Unreal Tournament. So you'd have a mods folder, say, in your skin directory, and XBMC would pick up its contents like it picks up custom.xml files. Then it would override, or maybe extend, any includes specified in the mod files (view types, for example) with those contained in the mod files.

Maybe you could also have a tag in the mod files, or an equivalent of skin.xml (call it mod.xml, perhaps), for mod name and author details. That way, a skin could use this information to tell users which mods were active.

Sound even remotely possible?

[jmarshall]

Anything is possible. The problem is that the amount you'd have to change is entirely up to how the skinner implemented their skin.

Overwriting a whole file or a whole include is simple. But usually you need far more than that, or you need to be able to insert stuff and change navigation and so on and so forth.

Essentially not feasible most of the time. If you have concrete ideas, let's here them.

Cheers,
Jonathan

[djh_]

I'll have a think.

[Livin]

I made this request about 2-3 years ago also but I think with the popularity of AEON and some other highly adopted skins it is very relevant to again bring it up.

There are a lot of MODs to skins and no easy way to try/test/reverse them.

The goal would be to leave the base skin unaltered and have a separate folder in the UserData for MODs or custom themes.

Here's how it would work....

1) user sets skin & theme/mod to be used in Settings
2) engine reads in users Settings
3) engine checks UserData\Skins\<skin name>\<theme/mod name>, and creates index (pointers) to all files needed, including new or 'substitute' XMLs
4) engine loads skin based on new 'index' of both original skin folder and mod folder.

note:
MODed XMLs would need to be complete replacements for originals


This would create an easy way to test and switch between mods/themes


thoughts?

[Jeroen]

imo it's bound to cause problems as the skins themselves are updated and conflicts arise when a mod is referencing something that is not in the original skin anymore, or has been changed or the other way around.
When a skin gets a big update it is often advised to remove the older version first because of the same sort of scenarios like this.

[Livin]

imo it's bound to cause problems as the skins themselves are updated and conflicts arise when a mod is referencing something that is not in the original skin anymore, or has been changed or the other way around.
When a skin gets a big update it is often advised to remove the older version first because of the same sort of scenarios like this.

Actually it will cause less problems and be easier to add/remove MODs.

... it will be 100x easier to test the MOD with the 'updated' skin since, if there is an issue with the MOD, all you need to do is turn the MOD off in Settings.

[Jeroen]

I don't see how it would cause less problems. I understand it will be easier to use/install mods. What I am talking about is conflicts because of cross referencing includes, conditionals and such. I'ts easy saying it will cause less problems, it's another thing to actually understand. no offense

[Livin]

I don't see how it would cause less problems. I understand it will be easier to use/install mods. What I am talking about is conflicts because of cross referencing includes, conditionals and such. I'ts easy saying it will cause less problems, it's another thing to actually understand. no offense

My request is not to address the issue you are talking about - XML code conflicts.

It would not make it any different than it is today... no better, not worse.

It WILL make enabling and disabling easier... so if there is a problem undoing is simply changing a setting, not copy/replace files... so IMO is is WAY easier.

[Livin]

I guess no one sees the usefulness of this... like all my other suggestions, it will show up in XBMC 1 to 2 years later.

[harryzimm]

I made this request about 2-3 years ago

I guess no one sees the usefulness of this... like all my other suggestions, it will show up in XBMC 1 to 2 years later.

Hilarious

[Livin]

it usually takes a few times asking before it happens... last time they implemented 'themes' as the "answer" definitely inferior to the solution I've been asking for.

maybe one day.

[jmarshall]

Most skin modifications are used while a skin is still in production.

There's very few available for finished skins - these usually end up as separate skins (eg Horizons and Aeon).

There's lots of mods for Stark at the moment as it's not finished, and thus in a state of flux. Once it's finished, these mods will become either less important (or unneeded) as the skin includes them, or more important as they move to become a separate skin altogether.

There's very little cases where this hasn't happened, thus there's reason for reluctance.

Cheers,
Jonathan

[Evanrich]

I don't know anything about mods, skins, or any of this, so if this sounds dumb forgive me, but I just had an idea.

Is there anyway possible to make it so that mods and changes are kept in a seperate file....say Viewtype_Multiplex_MOD.xml instead of editing the originals, so that if you update, say using the GIT program, your changes will still take effect? I don't know if this would be skin based, or if it would have to be coded into XBMC, but I think that would solve the problem of updating and then loosing your mods. Make it so the skin would look for a file with a _MOD extension or something, and then use that in preference to the default file.

[althekiller]

You need to read up on how to use git correctly. One of its key features is the ability to keep a local branch. In this branch you can apply all of your mods (which should be released as patches not these dumbass full file replacements), then update djh's remote and merge it with your local. Occasionally, you'll run into some merge conflicts, but this is too be expected and you should learn how to resolve them.

[motyR]

but this is exactly what the guy is saying, the all skining capabilities of xbmc is crap, don't believe me? well look at aeon skin and how it has abused the power that xbmc gave him, abuse? raped, molested.

the all design should have been entirely different, is there any reason why xbmc skining not using inheritance FFS why do we need to recreate each and every widget(and please i'm not talking about includes), xbmc should have given more formality and unified specs to the widgets and an explicit directive way when ever u want to use your own custom widget that way u could maintain your modes with no big fuss.

at the time being, for one to create a skin u'll need to have MIT diploma or a father that works as a NASA engineer, that for me is a DESIGN BUG, and lets face it, when it comes to functionality the only skin that can deliver the needs of a true media centre is pm.hd3 and guess what the skin had been written by xbmc developer.