Posts: 26,215
Joined: Oct 2003
Reputation:
187
2013-06-03, 07:39
(This post was last modified: 2013-06-03, 07:42 by jmarshall.)
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.
removed151214
Unregistered
removed151214
Unregistered
Posts: N/A
(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!)
Posts: 498
Joined: Mar 2012
Reputation:
13
2013-06-05, 11:21
(This post was last modified: 2013-06-05, 11:41 by reazorFX.)
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
removed151214
Unregistered
removed151214
Unregistered
Posts: N/A
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)).
Posts: 4,060
Joined: Mar 2010
Reputation:
94
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
removed151214
Unregistered
removed151214
Unregistered
Posts: N/A
(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.
Posts: 17,547
Joined: Aug 2007
Reputation:
597
Hitcher
Team-Kodi Member
Posts: 17,547
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.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
I dunno what Cancel is in various dialogs, but if we're altering OK to 28, perhaps Cancel should be 29 ?
Posts: 26,215
Joined: Oct 2003
Reputation:
187
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 ?