[thedeadman]

Greetings,

With list controls (any flavour), the last focussed item is maintained when the user leaves the control (say to go and navigate an adjacent menu).

I need to turn the focussed item off when a given list control loses focus... i.e I need to be able to set all items in a given list to their <itemlayout> state as opposed to their <focusedlayout> state.

I managed to do this by accident once, but try as I might, I can't remember how the hell I did it - any suggestions?

Thanks as ever,
theDeadMan.

[phil65]

<visible>Control.HasFocus(LISTID)</visible> for the focustexture for example.

[thedeadman]

Thanks phil65,

That works. However, the <itemlayout> texture is not maintained, and I would also need to revert the colors for the infolabels as well (i'm using a monochromatic scheme - white on black / vice-versa on focus).

Not that i'm griping - I can add the extra conditions / controls to overcome this issue, but is there a simpler solution? Say 'on unfocus, set focussed item as -1' or something?

[phil65]

not really.

depending on use case you could
- move your itemlayout into an include and also include that into focusedlayout inside a group which also contains the vis condition as mentioned.
- use vars for colordiffuse tags in focusedlayout.
- try to work with fade as onfocus effect.

[thedeadman]

Hmm. Clever fixes all - thanks again phil65.

This is something that needs attention below the skinning level methinks - might be one to raise on Trac? Currently there is no simple way of indicating which list is currently in focus - leaving the skinner with few clean options other than using fades etc. From a usability perspective, this is far from ideal!

Thoughts?

[`Black]

Sometimes you want the list loose focus (visually), sometimes you don't. It's up to the skinner. Also the focusedlayout can have a different size and completely different layout than the itemlayout so you can't simply use the itemlayout if a container looses focus.

[thedeadman]

Black,

If a control does not currently have focus, it should not indicate to a user that it does! If there is more than one list on an active window, how can the user know which is currently active?

I do take your point that a focusedlayout can (and should be able to) maintain a very different physical appearance to the itemlayout, and that the skinner should ultimately retain the flexibility to retain the focussed state when the user leaves the control. However, the current way in which this is managed by default is plain wrong IMHO.

[`Black]

The problem is if you add some default behavior (e.g. set the opacity to 50%), you take the flexibility away. It would be better if the wiki would clearly give examples how a certain things should (preferably) be handled and when. This is something what Apple does for example... they have very good UI guidelines which developers should have in mind when they design an iOS application.

[thedeadman]

I'm not sure that it does in this particular case to be honest - though I agree wholeheartedly with your suggestion for better general UI guidelines (font sizes in particular - a killer of many a beautiful skin, though I should add not any of yours :-) )

Try as I might, I cannot think of a situation where 'if control not focussed, maintain focussed state' would be an appropriate default action for a list control in XBMC or any other UI. 'when return to control, return to last focussed position' is fine - and indeed quite useful - but the former makes absolutely no sense.

[`Black]

I agree with you that there aren't many situations. But look e.g. at the banner list view in my skin. How would you indicate that the list doesn't have focus if for example the scrollbar is selected? You could reduce the opacity (doesn't look so good) or remove the background texture (doesn't look good either) so you see it's not really easy to do and even harder to add a default behavior. The latter is the main problem because you can't have a default behavior if a container is unfocused because there are so many different layouts possible... you can only try to make it clear to skinners that it should (if possible) always be clearly recognizable for the user which element has focus at the moment.

[thedeadman]

"you can only try to make it clear to skinners that it should (if possible) always be clearly recognizable for the user which element has focus at the moment"

Couldn't have put it better myself.

I'll think on this some more - there must be an easier solution that keeps duplication of controls at bay (skin vars can only do so much).

[pecinko]

Use panel container if you can. It behaves differently than lists in this regard.

[jmarshall]

The main reason for this (the decision was made back in 2004 IIRC) was that we used to have a "large list" which showed a different sized item than the main list. When you unfocused it, it would shrink up again, which looked a bit naff as well as being distracting. Thus the concept of still showing "this item is selected" while the control is unfocused.

Technically, the focusedlayout is in fact the selected layout. You normally have some other effect available for when the list itself is in focus. This is normally done via the HasFocus() conditions inside the (misnamed) focusedlayout.

Suggestions are always considered, so if you have a better idea, let us know

EDIT: And yes, panels behave differently as they can't have a differently sized item slot (They can be bigger as they render on top, but the base "slot" is the same size).

Cheers,
Jonathan

[Jezz_X]

The simple solution here is turn it into a panel control instead and it works just fine with 1 row or 1 column and to the user looks just like a list

[thedeadman]

All,

Panel controls work as described, thanks (though I do lose the niceties of fixed lists - can't have everything I guess).

I'll think on this some more as I continue to work through the skinning engine.

Cheers,
Chris.