[ronie]

yeah it's something worth exploring.
perhaps is should start with checking if it's possible to merge all the MyPVR**.xml files.

iirc, does this mean to return to pre-Helix? Where it was just a MyPVR.xml with different view types? (I hope I got it wrong).

i only had a very brief look at the core code last night. as far as kodi is concerned, those xml files are 100% identical so likely very easy to merge.
(with the exception of MyPVRGuide.xml which requires the hardcoded id's 10, 11, 12)

before helix we only had a single pvr window (MyTV) with a hardcoded id for each container.
currently we have multiple pvr windows (TVChannels, RadioChannels, TVRecordings, etc..) and that won't change.

in case of a merge, your MyPVR.xml could look like this:

Code:

<window>
    <defaultcontrol>50</defaultcontrol>
    <views>50</views>
    <controls>
        <include condition="Window.IsVisible(TVChannels) | Window.IsVisible(RadioChannels)">ChannelsView</include>
        <include condition="Window.IsVisible(TVRecordings) | Window.IsVisible(RadioRecordings)">RecordingsView</include>
        ...
    </controls>
</window>

i agree we should only go ahead with it if saves skinners the hassle of coding the same (or very similar) pvr window xml file 4 or 5 times.
it should indeed not result in a very cluttered / unreadable xml code.


at this point, i'm just throwing out ideas and nothing is set in stone ;-)
if the consensus is, it's not a good idea in this case, it won't happen.

[ronie]

In a similar vein, there are several notification dialogs ATM (dialogKaiToast, DialogExtendedProgressBar, DialogProgress). Might they also be collapsed into a single xml, e.g. dialogUserNotification.xml?

DialogProgress.xml is a modal dialog, so not possible to add that one.


we currently have these modeless dialogs:
- DialogBusy.xml
- DialogExtendedProgressBar.xml
- DialogKaiToast.xml
- DialogSeekBar.xml
- DialogSlider.xml
- DialogMuteBug.xml
- DialogVolumeBar.xml

(of which the last two have been merged)

if you or anyone else can think of some that could use the same xml file, let me know.

[sualfred]

My channels, timers and recordings window look completely different

For sure, for me it's not a big deal to move the different layouts into one xml, but adding conditional includes/visiblities cost me more time (and code lines) than keeping them in in their own xmls. In my eyes this would be a step backwards.
And if I'm thinking back to the days I've learned skinning, I was happy to have own xml's for the most windows. It makes it easier to learn and to understand.

Long story short:
+1 for dialogs, which a very similar.
and "please not" for real base windows such as My****

Edit:
Merging MyPVRTimers and MyPVRSearch would make sense. I assume this two ones are nearly 1:1 in the most skins.

[Mike_Doc]

from someone still trying to learn to skin, would merging not complicate learning etc?

I understand how seeing 4 instead of 14 would make you think there's less but will there still not be the same amount of code? i.e. if you merge 3 of 500 lines each into 1, then you have one xml of 1500 lines with multiple controls added for them to work as they did prior? Would that be correct or as usual with skinning am I misunderstanindg what the merging has to offer?

Current format helps, as you can debug and see where you are i.e. which xml is in focus, merging 4 into one just gives you one xml but no idea which control / visibility is actually in focus?

I'm sure if I knew what I was doing then this would probably make sense to me like it does to the skilled skinners who have replied?

Mike

[wyrm]

Ronie, once again thank you, it's long overdue.

Now I know it's a throwback to the xbox days, but toast is what I scrape my Vegemite on in the morning. While you are at it, how about renaming DialogKaiToast.xml to DialogNotify.xml so that the function of the dialog is a little clearer?

Wyrm

[ronie]

Now I know it's a throwback to the xbox days, but toast is what I scrape my Vegemite on in the morning. While you are at it, how about renaming DialogKaiToast.xml to DialogNotify.xml so that the function of the dialog is a little clearer?

hehe, most of the skinners i talk to enjoy the exact same breakfast as you.
i'll add it to my shopping list.

[ronie]

I understand how seeing 4 instead of 14 would make you think there's less but will there still not be the same amount of code? i.e. if you merge 3 of 500 lines each into 1, then you have one xml of 1500 lines with multiple controls added for them to work as they did prior? Would that be correct or as usual with skinning am I misunderstanindg what the merging has to offer?

nope, it doesn't work like that.
if you have three dialogs that all contain more or less the same code, you don't have to duplicate that code anymore in the new dialog.

perhaps you can have a look at this one:
https://github.com/ronie/xbmc/commit/34a...7a6810e78d

it merges 3 dialogs (a total of 177 lines) into a single one (with just 78 lines).

[Hitcher]

Marmite.

[Mike_Doc]

Thanks Ronie for the additional explanation and example. I've never really had to work in the dialogX.xmls so don't know that much about them.

[Hitcher]

Thanks Ronie for the additional explanation and example. I've never really had to work in the dialogX.xmls so don't know that much about them.

Lucky for you then.

[User 224999]

Great work on this Ronie, this is going to save a lot of duplicate skin code.

[phil65]

next one which is open for discussion:
https://github.com/xbmc/xbmc/pull/8910

[tomer953]

Wow, great work.

Much appreciated.

[Rjsachse]

As I am new skinning and started by modding aeon mq6. I am welcoming the reduced xml's. One way I thought would be easier for new skinners having xml's moved to folders.

I have done this in aeon mq6 with the views and a few of my personal mods.

It would be good to have folders for. Views, PVR, Dialogs, Videos, Music, Custom Codes, Settings. Ect....

Just an idea.

The other thing is if this goes ahead, can skinning manual be updated to explain xml's and there function and how to find it within a skin. (Confluence) DialogkaiToast.xml had me stumped for a bit. Go the Vegemite...

Maybe rename it to DialogVegemiteToast.xml hahahaha

[Torben]

Reducing enforced .xmls is definitly a step in the right direction. Infact, every step towards freedom is welcomed.
I see no reason to enforce any kind of xml structure - at all.

With dynamic plugin lists and onclick control, I have skipped almost all but the *nav.xml's myself (and they are the next to go, as I'd to test mixed media, Albums/movies/whatever in the same lists. (Think "Oh, Bruce Willis (old-timer-action-hero) made an album.. how awful, but how nice to know.. and here it is! right.. here.. next to Die Hard")

peace