[phil65]

IIRC context menu doesn't work either because

• it doesn't allow multi-selection
  
• it simply grows with every additional item and can get bigger than the screen size and you end up not seeing all the options
  

so as you can see from a GUI point of view the code is simply not ready to handle this properly.

Yeah the sliders aren't ideal either but if you want range selection it's the best we can do. Using a list of choices is simply not intuitive for selecting a range (at least that's what I thought when I tried it when I implemented the filter dialog).

we can define the size of the grouplist so the list would not grow endlessly (scrollbar would not be possible though)
you´re right about multiselection though.

[phil65]

I understand that often times there would be empty space, but I fail to comprehend why this is inherently a bad thing. As I illustrated it comes with virtually zero downsides and a couple of significant benefits from a user experience perspective.

Well I simply think that something like

looks crappy so IMO until that dialog can auto-resize with the number of items (and to a maximum size) you have the downside of a bad looking dialog. Every time I open a selection dialog with very few items I hate the way it looks.

EDIT
@phil65
Yes, I agree slider controls feel weird in many places. They should probably be spinners instead. They make a lot of sense to arbitrarily increase or decrease numeric values. Sliders are a more natural choice if you have to balance a setting between two fixed values.

AFAIK most of the sliders we use are range selections which you can't do with a spinner

if a skinner invests the time he can adjust the size of DialogSelect to the number of items now already. (Stringcompare(Container.Numitems,X))
If you want I can set up a PR with those changes for Confluence. shouldn´t be too hard to get it look nicely.

Idea for two-sided sliders: they should have the same layout as SpinControls, with two buttons. The first button of that new control type would open DialogSelect with all options for the lower limit, the second button would open DialogSelect with all options for the upper limit. would make navigation much more streamlined (in my opinion pressing any directional button should always only change the focus and never trigger some kind of action) and also much better to use because DialogSelect has a scrollbar so you can navigate faster through a large list (at the moment you have to press onright a lot of times to get into the higher ratings when adjusting the rating filter for example)

[phil65]

@ Montellese:
you could try this DialogSelect.xml for Confluence:
http://pastebin.com/fCXFEWyz
it contains 4 different dialog sizes depending on the number of listitems. could be fine-tuned even more, but this would be sufficient already I guess. Needs approx. 30 lines of xml code so it´s not really a big deal for skinners to add it.

[Hitcher]

Anything that is part of the settings window in XBMC (i.e. what you see under System --> Settings but not e.g. the video or audio playback settings when playing a video) can easily be adjusted in settings.xml by changing the control type from "spinner" to "list" so it doesn't even need C++ skills. But I'm against such a change for settings with a very limited number of options due to the above reason. It works perfectly fine for things like language etc where there are a ton of options though.

Just tried this out and it just breaks the settings.

[Montellese]

Anything that is part of the settings window in XBMC (i.e. what you see under System --> Settings but not e.g. the video or audio playback settings when playing a video) can easily be adjusted in settings.xml by changing the control type from "spinner" to "list" so it doesn't even need C++ skills. But I'm against such a change for settings with a very limited number of options due to the above reason. It works perfectly fine for things like language etc where there are a ton of options though.

Just tried this out and it just breaks the settings.

Which setting did you try? I just tried with e.g. "lookandfeel.font" and it works perfectly fine.

[Hitcher]

Are you talking about changing them in the skin or core?

[Montellese]

Are you talking about changing them in the skin or core?

I'm talking about core settings.

[Hitcher]

Sorry, when you mentioned an XML I thought we could simply change the default spin control to a list.

Thanks.

[Montellese]

In the settings.xml (in the system directory) describing XBMC's core settings you can simply change the occurance of

Code:

<control type="spinner" ...>

to

Code:

<control type="list" ...>

but yeah that only covers core settings not skin or addon settings.

[un1versal]

dynamic dialog been merged, so I guess the spinners can be changed now.

Ill see about doing the settings.xml ones the remainder for skin no idea how.

---

see https://github.com/xbmc/xbmc/pull/5638 some feedback on which to keep/change would be good and hints on what other files to change as well.