Login at Kodi Home

**Martijn** · (This post was last modified: 2013-09-24, 20:36 by Martijn.)

then we change the code to replace the sin with something else.
add new skin, remove old skin, change default setting, done.
what's so hard about that.

i don't see your point. this is just the way it is, take it or leave it.

**da-anda** · 2013-09-24, 21:35

ofc we could have confluence as submodule, but actually we don't like the submodules we have ATM and there where plans to get rid of those (caused several issues with pr's). That's why confluence is not outsourced. Also it's much easier for core devs to at least do basic changes to confluence along with other code changes. If it was in it's own repo there would be quite some overhead in syncing PRs for both repos and then bump the submodule version.

powlo · 2013-09-24, 22:48

Do you mean submodule in the git submodule sense?

HenryFord · (This post was last modified: 2013-09-25, 13:19 by HenryFord.)

(2013-09-24, 20:23)powlo Wrote: mplayer seems to keep its skins separate from its main repo, as does xine.

Apples and Oranges again.
Xine is a library for which several frontends exist - but that has nothing to do with "skins" in the usual sense. A skin is something you apply to an already running program, while a frontend for xine is already a program in itself. In that sense XBMC itself is a frontend to a host of libraries. And thus it makes sense to have the skin integrated - because without an integrated skin you cannot use the frontend at all.
Same thing goes for mplayer - except that mplayer is a command line tool that is being used by the frontends available.

~~Ned Scott~~ · 2013-09-25, 13:33

I think he just means how it's organized on github.

FernetMenta · 2013-09-25, 13:42

Even if a user installs a different skin, Confluence is required as fallback for the case that a page is not implemented on the other skin.

HenryFord · 2013-09-25, 13:43

Ah - then I misunderstood the point here. Carry on Wink

**da-anda** · 2013-09-25, 15:07

(2013-09-24, 22:48)powlo Wrote: Do you mean submodule in the git submodule sense?

yep - git submodules caused quite some pain with PRs on github already (changed submodule state is not shown on github and thus can cause accidental reverts of submodule bumps or alike).

powlo · 2013-09-25, 18:55

(2013-09-25, 13:13)HenryFord Wrote: Apples and Oranges again.

To me it doesn't matter whether a skin is just a repo of xml files, or a full blown executable. It's a thing that does its thing on top another thing.

And the mplayer/xine parallel wasn't drawn by me. Go and chastise wsnipex! Tongue

(2013-09-25, 13:42)FernetMenta Wrote: Even if a user installs a different skin, Confluence is required as fallback for the case that a page is not implemented on the other skin.

This is interesting. Does this mean that Confluence skinned pages can crop up in another skin? That must look clunky. I'll have a play and see if I can make it happen.

(2013-09-25, 15:07)da-anda Wrote: git submodules caused quite some pain with PRs on github already (changed submodule state is not shown on github and thus can cause accidental reverts of submodule bumps or alike).

Well I wouldn't use a submodule for confluence, I'd keep it in a completely separate repo. Then maybe use tags to sync between xbmc repo and the skin repo (in much the same way, I imagine, as other skin developers have to. ie use a tag for "Frodo" and so on)

Bear in mind that this isn't really a serious issue I'm having. It's just something that I found mildly frustrating and seemed a bit wonky. Naturally I don't know the ins and outs of XBMC, but I am interested in learning why things are the way they are.