Unifying dialogs so simply skinning
#1
Unified dialogs would indeed speed up the process but it should still be possible to design custom dialogs if the skinner decides to do so.
Image
Reply
#2
(2013-03-14, 13:07)`Black Wrote: Unified dialogs would indeed speed up the process but it should still be possible to design custom dialogs if the skinner decides to do so.

My original idea was that we have a set of common xmls for all the dialogs compiled into the c++ and the skinner just has to have one xml called DialogCommons.xml that would contain stuff like settings catagory does with default values for buttons sliders textboxes etc etc as well as a background control that you can define the borders on. That way they still use the graphics and fonts of the skin

Then if a skinner wants to do any of them custom they can just include the original xml file and it will take preference over the inbuilt ones kind of like how scripts ship with default xml and the skins one overwrite it if it has them
Reply
#3
(2013-03-14, 13:25)Jezz_X Wrote:
(2013-03-14, 13:07)`Black Wrote: Unified dialogs would indeed speed up the process but it should still be possible to design custom dialogs if the skinner decides to do so.

My original idea was that we have a set of common xmls for all the dialogs compiled into the c++ and the skinner just has to have one xml called DialogCommons.xml that would contain stuff like settings catagory does with default values for buttons sliders textboxes etc etc as well as a background control that you can define the borders on. That way they still use the graphics and fonts of the skin

Then if a skinner wants to do any of them custom they can just include the original xml file and it will take preference over the inbuilt ones kind of like how scripts ship with default xml and the skins one overwrite it if it has them

How do we get this going again then because I'm sure a lot more skins would be made?
Reply
#4
Agreed, most of the time spend on dialogs is time better spend on something else. But sometimes a dialog just needs that integration.
I think we can all agree on that. So the question i see is: How should the basic dialogs look?
That is not trivial to people actually using them / leaving them in.
Because it's not like dialogs from Confluence and Nox are interchangable, even after you adjust color. Just to point at a random example.

How about a design competition for a set of dialogs that should work as basis with all skins? Really well balanced, simple and clean.
Photoshop only submissions so many can join without using a ton of time.

If devs are not behind actually putting this in main, i could understand that. It's skin domain.
But Hitcher could stick them in foundation so they wouldn't have to be re-done on new projects for example.
Image [RELEASE] Metroid
Image [RELEASE] IrcChat
Reply
#5
I believe that, instead of unified dialogs, web management is a way to go. Advantages are clean XBMC UI, mouse & drag-drop support, more intuitive and more flexible dialogs including more flexible and user friendly home page:

Probably not needed in XBMC UI in this case:
- dialog content settings
- dialog media source
- network setup
- file browser
- file manager
- mymusic playlist editor
- profile settings
- settingsprofile
- smartplaylist editor
- smartplaylist rule
- Include_Home_Window_Customization ;-)

Sets, tags, playlists are, what I believe, dialogs to make direct benefit from web management. Custom sections and home customizations could be saved once set and used in any skin afterwards.
My skins:

Amber
Quartz

Reply
#6
A webui alone isn't going to work pecinko its a decent idea but unless the whole app is just a browser window there is no way people on tablets and other portable things are going to want to go find another pc just so they can connect to the webui remotely and configure stuff, the same is pretty much true for any embedded system like android and openelec
Reply
#7
Regarding dialogs, what I suggest is done is:

1. A list of all dialogs that you think could be unified based on a single skin.
2. Grab some screenshots from a bunch of skins to see how much that unification applies across skins.
3. Figure out how the dialogs group together - a bunch may be able to just be special cases of others (i.e. they all have the same layout anyway) such as all the small ones (dialogyesno/ok/progress etc.) and all the settings ones (peripheral, addon setting, audio/video settings etc.) the info ones (video/musicinfo/addoninfo) and the like.
4. Figure out whether these groups (and any other unique ones) can be combined in some way, maybe by placing controls into known control groups or grouplists, or maybe by combining some new layout controls (centering of dialogs is already available).
5. At that point we can see what can be done fast (and get it done) and what will take a bit longer (and start on it), with hopefully a decent amount of backward compatibility built in.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#8
(2013-03-14, 23:39)Jezz_X Wrote: A webui alone isn't going to work pecinko its a decent idea but unless the whole app is just a browser window there is no way people on tablets and other portable things are going to want to go find another pc just so they can connect to the webui remotely and configure stuff, the same is pretty much true for any embedded system like android and openelec

OK, so I waited a bit to see if there will be some thought as to how t unify dialogs. Sure enough, not an easy task to do if at all possible in a reasonable way.

The way I see it, phones, tablets or embedded systems are accessing media that are stored on PC or NAS. There are probably some border use cases but this holds true for 98% of users. If XBMC server/streamer backend existed you would simply manage you stuff on NAS through web interface. Then, when you launch XBMC on your phone or PC you would just use it.

Yup, you could argue that this is somewhat more difficult to install as you would need to setup and configure XBMC in two places. OTOH, I have never even tried to run XBMC on my phone because I would need to setup all things on it using small dialogs that are not quite comfortable to use on a touch device with small screens.

Furthermore, I often hear that for most of XBMC users (non geeky part of them) backend would be more difficult to use. Is this really true? Let's take iOS as an example - jailbreak, install XBMC, set it up. Backup you settings, jailbreak, install new iOS version, install XBMC, copy settings from backup. XBMC Live experience was same for me (not being Linux expert) as I was never able to upgrade from a previous version smoothly.

Let's go a step further - say that you are using smart playlists as an officially recommended way of separating movie library. Once you split your media into a few sections, how do you access them from your home page? Custom links through favourites? What if you want to switch skin? Now, add another htpc to a bedroom. Prepare to do it again. Using tags or currently discussed custom sets? Set that as well on your bedroom htpc. Good, now do the same on you phone of choice. Oh.. and remember to use a touch skin with customisation possibilities if you want to have your tags, sets and smart playlists.

Would XBMC backend really be a more difficult way to go? I don't really think so.
My skins:

Amber
Quartz

Reply
#9
IMO both are needed. You'd still want a bunch of dialogs even if a heap of the settings ones were removed to some other app (which ofcourse would need to have those dialogs anyway, just perhaps within some web or native interface).

Thus, we mayaswell start with the dialogs we have and reduce as many of them that are possible, as I suggested in my post above.

I have no doubt that we could reduce the count of dialogs by 5-10 without much work - it's just a matter of identifying them and getting the code written.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#10
Maybe someone could make a call as to what dialogs we should be looking at?
As in, a list. So we can begin with the, running into problems.
Image [RELEASE] Metroid
Image [RELEASE] IrcChat
Reply
#11
Anyone experienced with jQuery UI? I think there's some benefit to that approach here. There's a standardized list of images that each theme must provide and all dialogs are built from those images. The important part is that there isn't a yes_no_dialog.png, but there is a dialog_top_left_corner.png, a dialog_top_center.png, a dialog_top_right_corner.png and etc.

Ideally, this would further separate the concept of skins and themes. The skins provide the physical layout and placement of the components of a dialog, then themes provide the actual images to show.

Take a look at the Theme Roller gallery to get a feel for what I'm getting at: http://jqueryui.com/themeroller
Reply
#12
I think it's easiest to start with the dialogs that have most in common.

e.g. all the small dialogs:

YesNo, OK, Progress, PlayEject.

Did I miss any?

For these, we need basically a background (set of textures) a progress bar, a label for the header, a textbox (or labels) for text, and some buttons. I suggest skin provides the backdrop stuff, any close button for the upper right (touch), position of header + textbox for content, position of progressbar, then maybe a grouplist for OK/Cancel/Yes/No etc.

Then we could move onto all the settings dialogs perhaps?
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#13
Any news on this?

Btw, why don't we fallback to Confluence dialogs if dialogs are missing?
Image [RELEASE] Metroid
Image [RELEASE] IrcChat
Reply
#14
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.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#15
Love the idea of unifying some of the dialogs. I'm at the stage now with my first skin of working through, one by one, all of the dialogs. Anything to make that easier is much appreciated.

Unfortunately I suspect the best way to unify dialogs is to use the tools already provided, notably $VAR and <include> tags, to share as much code as possible between the different files. There's an awful lot of power in those two tags (though it would be amazing if $VAR's could be used within the tags themselves - e.g. <texture fallback=$VAR[fallbackImage]>)...

Of course, the difficulty in doing that is that it takes a lot of time and even more preparation and organisation to actually achieve. I've been able to go back over a lot of my skin and add this stuff, but until I actually got to know the skinning engine and understood all of the different views, it was nearly impossible. It would be great if this was build into an empty skin, like the foundation skin, so that new skinners (and new skins) take advantage of these great features by default.

In terms of actually combining multiple XML files, the only one's that have really struck me as being combinable thus far are the various media navigation files (MyVideoNav.xml, MyMusicNav.xml, MyPrograms.xml, MyPictures.xml and - arguably - AddonBrowser.xml). For me, these files have just 2 differences between them - a list of which views are available for that view, and the contents of the bar that's normally on the lefthand side (changing view, sorting, search and so forth.)

Obviously combining these would need an extra tag straight away - something along the lines of:
<videoviews>50,51,52</videoviews>
<musicviews>50,52,54</musicviews>

And it would then need some way of displaying different menus to the left. How about copying the way DialogAddonSettings.xml works (because I've just finished designing it) for example. The combined view would provide a grouplist, along with default definitions for controls that may appear in tht list, which XBMC then populates itself. Most every skin I've seen provides the same controls in that list. The biggest difficulty I can see is for those skins with a kiosk mode - perhaps XBMC itself would need a kiosk mode, rather than it being on a skin-by-skin basis.

(Actually, a similar setup could possibly be used to combine the various media information dialogs as well...)

Having said all that, I stick by my original statement - $VAR and <include> is the way to go, and should be promoted to beginner skinners from the word go!

Edit - the other thing that could be done to simplify skinning, though nothing to do with unifying dialogs I freely admit - is massively improving the documentation. (By documentation I mean wiki.xmbc.org - if there's other documentation than this then my suggestion changes to simply improving its visability!) Taking DialogAddOnSettings.xml again as an example. I know it uses a grouplist to display the buttons to change which setting area you're viewing, and another for the actual settings the addon exposes because I looked at other skins to see how they present the dialog.

Yes, there's a list of the controls and ID's needed at http://wiki.xbmc.org/index.php?title=XBM...ttings.xml, and that's great for those who understand the skinning engine - though even then I challenge you to tell me the difference, and use of, ID's 2 & 9 based off the wiki For a newbie, which I still consider myself to be, it's so much hokum. It would be great for there to be individual wiki pages for each xml file, and a decent description and example of each of the expected ID's.

Yes, I know this one needs to be a community effort, and I also know it's easy to say these things need to happen and not contribute. So, I'd be willing to write it for this dialog, if others would contribute to all the other dialogs! (And perhaps more importantly, those providing patches to the skinning engine also provide such specific updates to the wiki!)

Increase the documentation, and you reduce the need to start unifying dialogs to simplify skinning in the first place. I'd put money on most peopl being attracted to skinning XBMC being used to searching for and then following documentation.

Final edit (I promise): I've written said wiki page at http://wiki.xbmc.org/index.php?title=Dia...ttings.xml, though you'll notice I've left ID's 3 and 13 the same, again to prove a point - tell me what the difference is (the skinning manual defines them both as "Button Template") based on the wiki...
Reply

Logout Mark Read Team Forum Stats Members Help
Unifying dialogs so simply skinning0