The difference is one is a template for the tabs/categories (13) and the other is a template for buttons that appear in the settings lists (3). i.e. exactly the same as 2 and 9 (latter is grouplist for tabs/categories, former is for settings lists).
I agree that more documentation would be useful. But that doesn't preclude combining common stuff to reduce duplicate effort for all skinners, both old and new.
(2013-06-03, 07:39)jmarshall Wrote: [ -> ]The difference is one is a template for the tabs/categories (13) and the other is a template for buttons that appear in the settings lists (3). i.e. exactly the same as 2 and 9 (latter is grouplist for tabs/categories, former is for settings lists).
I agree that more documentation would be useful. But that doesn't preclude combining common stuff to reduce duplicate effort for all skinners, both old and new.
I do have this tendancy to write long posts and then forget to make my point clear - which in this case is to say I absolutely agree that anything that reduces duplication, and therefore reduces the effort involved in skinning, is definately worth it. But that there are other areas to consider as well if the overall aim is to reduce effort (preferably, considered alongside unification!)
(2013-06-02, 03:54)jmarshall Wrote: [ -> ]I've asked several questions throughout this thread. I'm not answering them myself. Show some initiative at gathering stuff together and you'll be surprised at how quickly things get done.
I was more asking skinners i guess. As far as i am concerned, i would bunch the following dialogs up:
DialogMediaSource.xml
FileBrowser.xml
DialogNetworkSetup.xml
DialogSelect.xml
DialogAddonSettings.xml
DialogContentSettings.xml
DialogFileStacking.xml
DialogMediaFilter.xml
DialogPeriferialManager.xml
DialogPeriferialSettings.xml
Have a header, with the content below it (like a list or bunch of grouped controls).
Have a grouplist next to the content with the following buttons:
Ok
Cancel
New Folder
Browse
Add
Remove
Get More...
Defaults
Settings
As long as they know when they should be visible this should be no problem.
And probably an icon for in some of the dialogs that needs to know when to show.
Most tricky would be the content. Like how many different layout types do you need for the actual content?
Single line list, double line list with icon, and a grouplist?
how would a personally customized dialog realized?
maybe a fallback if for example Smartplaylisteditor.xml no available,
go to a default Dialog woud be nice. So it´s not a big change for the all the finished skins and the new skins can have a unified dialogs.
And if somebody want to chance to a personally only write a new Smartplaylisteditor.xml
If the opinion is that the best way to simplify skinning is to combine the various dialogues (which, as I've said, I'm not convinced is the best way to proceed if the aim is, truly, to make skinning simpler to those who are likely attracted to doing this) I would suggest splitting the dialogues as such:
* Overlay, Non-modal (dialogues that show information, but don't require any user interaction - the rest of the UI is accessible whilst these dialogues are visible)
- For example, DialogProgress.xml, DialogSeekBar.Xml, DialogKiaToast.xml
* Overlay, Modal (dialogues that provide information, and controls to close the dialogue - the rest of the UI cannot be accessed until this UI is closed)
- For example, DialogOK.xml, DialogSelect.XML
* Fullscreen, Modal (dialogues that allow the user to make changes to the current settings of XMBC - the rest of the UI cannot be accessed until this UI is closed.)
- For example DialogContentSettings.xml, and others (I've not really begun skinning this type of dialogue!)
This splits the dialogues into three distinctive categories, which could have three distinctive overall layout. This means that each layout could have a general layout - along with a list of specific definitions for each control within that view. Then. a specific layout definition for each individual view - whether that's one line, a progress bar, one control button and so forth.
Each one would need, potentially:
(1) A list of different categories within the dialogue (only the fullscreen, modal type, potentially?)
(2) Information or settings exposed by the dialogue
(3) Buttons for closing the dialogue.
Assuming XBMC can provide lists of the content for each one, this shouldn't be too difficult to do - by providing GroupLists which contain the controls for each dialogue (which the skinner could access by providing default settings for each control that may be provided) there isn't even a need to provide individual layouts for each dialogue, except for whether they provide (1) or (3) or not (presumably, all will provide (2)).
I really don't get all this, we'll have a bunch of unfinished skins out there, so i can imagine just coding the home screen and some views and that's it ? Everyone here knows how long it can take to finish a skin, but well that's the deal.
What can be easier, modifying confluence and keeping the rest as it is ... You'll have the same result.
Just my 2 cent
(2013-06-06, 00:38)butchabay Wrote: [ -> ]I really don't get all this, we'll have a bunch of unfinished skins out there, so i can imagine just coding the home screen and some views and that's it ? Everyone here knows how long it can take to finish a skin, but well that's the deal.
What can be easier, modifying confluence and keeping the rest as it is ... You'll have the same result.
Just my 2 cent
I suspect the point is twofold:
1. The reason there are so many unfinished skins out there is that there are so many individual dialogues to skin, that it takes a huge amount of time and effort - time and effort that skinners can barely afford when we are doing it in our, generally limited, spare time. (I keep a list of jobs-to-do as part of any project I am working on. One of those items was "List dialogues still to be skinned" - I listed 29 before I simply added "More(+)" to the bottom of the list...)
2. Yes, we can keep Confluence dialogues as they are. Or whichever skin we're basing our's off - mine is based off of Transparency!. However, once a skin reaches a certain level, the existing dialogues simply don't fit in with the look and feel (and - far more importantly - the UX) that we''re trying to achieve, that existing dialogues look, feel and act completely different to the rest of the skin..
Yes, I could release my skin right now, but all the Transparency! dialogues I haven't managed to update so far means that the skin would provide an inconsistent look and feel, and an inconsistent UX.
(2013-06-06, 00:51)Unfledged Wrote: [ -> ]1. The reason there are so many unfinished skins out there is that there are so many individual dialogues to skin, that it takes a huge amount of time and effort - time and effort that skinners can barely afford when we are doing it in our, generally limited, spare time. (I keep a list of jobs-to-do as part of any project I am working on. One of those items was "List dialogues still to be skinned" - I listed 29 before I simply added "More(+)" to the bottom of the list...)
Dialogs are just one of the things. It gets more complicated along the way:
Descriptions are not unified so you need to check the content and vary tags accordingly. You can not rely on content checks in every situation as plugins may "lie" that they have movies, while actually using rectangle thumbs. Thus, you need to keep that in mind with posters. Sure, you can force aspectratio=keep on everything and have very functional but un-pretty skin.
Then, you can have movies mixed with sets but sets don't have description which will make your skin look half baked so you need to watch out for that one. You can turn ".." items on or off in settings so even if you force ",return" in your calls to keep navigation logical it will break when user click on parent folder
We have custom video nodes. In order to make full use of that you should be calling main library nodes. OTOH, people expect to go directly to Movies when they click it on home page and not to filters menu. I can go on...
Nice thing is you don't know this when you start to skin, so dialogs looks like a main deal breaker :-)
I was just looking at the
List of Built In Controls to see how best to update them and noticed there's still more room for improving the unification of control IDs.
EG The OK button is 4, 7, 10, 14, 18, 28, 29, and 413 over various dialogs.
Is there any particular reason it can't be 28 for all dialogs?
No reason at all, other than time taken to do it
Any other unification while I'm at it (I can probably make these backward compatible if it's deemed reasonable). e.g. what about Cancel?
We could also consider merging the OK and YesNo dialogs (replacing with a grouplist of buttons at the bottom).
Cheers,
Jonathan
A grouplist sounds a great idea.
How do you propose we go about unifying more?
eg the spincontrolex is 9 in all dialogs except DialogAddonSettings.xml where it's 5 but we can't make it 9 because that's the id of the second grouplist; on top of that grouplists are mostly 5.
As you can see it gets complicated quite quickly but I'm willing to put in the effort to get them sorted.
I dunno what Cancel is in various dialogs, but if we're altering OK to 28, perhaps Cancel should be 29 ?
Would it be possible to do the same for the Heading label? It is:
- 1 in DialogMediaFilter.xml, DialogNumeric.xml, DialogOK.xml, DialogPeripheralSettings.xml, DialogProgress.xml, DialogSelect.xml and DialogYesNo.xml
- 2 in DialogMediaSource.xml, LoginScreen.xml, SmartPlaylistEditor.xml and VideoOSDSettings.xml
- 3 in VisualisationPresetList.xml
- 10 in DialogSlider.xml
- 20 in DialogAddonSettings.xml
- 30 in DialogExtendedProgressBar.xml
- 311 in DialogKeyboard.xml
- 411 in FileBrowser.xml
And here are the ids for Cancel:
- 29 in DialogContentSettings.xml, DialogMediaFilter.xml, DialogPeripheralSettings.xml, DialogPVRTimerSettings.xml, LockSettings.xml, ProfileSettings.xml, VideoOSDSettings.xml
- 6 in DialogPVRChannelManager.xml
- 10 in DialogProgress.xml
- 11 in DialogAddonSettings.xml, DialogSongInfo.xml
- 19 in DialogMediaSource.xml, DialogNetworkSetup.xml, SmartPlaylistRule.xml
- 21 in SmartPlaylistEditor.xml
- 25 in DialogPVRGuideSearch.xml
- 301 in DialogKeyboard.xml
- 414 in FileBrowser.xml
The only potential issue I see with that is that OK is also used as ID 29 in DialogPVRGroupManager.xml which means backward compatibility is not possible.
I suggest switching to a range that is "Safe" for all dialogs for these 3 controls. e.g. maybe in the 40's ?
(2014-05-10, 11:44)Hitcher Wrote: [ -> ]A grouplist sounds a great idea.
How do you propose we go about unifying more?
eg the spincontrolex is 9 in all dialogs except DialogAddonSettings.xml where it's 5 but we can't make it 9 because that's the id of the second grouplist; on top of that grouplists are mostly 5.
As you can see it gets complicated quite quickly but I'm willing to put in the effort to get them sorted.
DialogAddonSettings.xml hasn't been aligned with the other settings dialogs yet because it's implementation doesn't use the same base (previously CGUIDialogSettings and now CGUIDialogSettingsBase) and everything is completely re-written (a lot of copy&paste as well).
(2014-05-11, 15:07)Alex... Wrote: [ -> ]Would it be possible to do the same for the Heading label? It is:- 1 in DialogMediaFilter.xml, DialogNumeric.xml, DialogOK.xml, DialogPeripheralSettings.xml, DialogProgress.xml, DialogSelect.xml and DialogYesNo.xml
- 2 in DialogMediaSource.xml, LoginScreen.xml, SmartPlaylistEditor.xml and VideoOSDSettings.xml
- 3 in VisualisationPresetList.xml
- 10 in DialogSlider.xml
- 20 in DialogAddonSettings.xml
- 30 in DialogExtendedProgressBar.xml
- 311 in DialogKeyboard.xml
- 411 in FileBrowser.xml
Is this list based on the Helix sources or on Gotham sources? Because DialogMediaFilter.xml, DialogPeripheralSettings.xml and VideoOSDSettings.xml should all have the same heading label ID.