jmarshall Wrote:While the "Home" button makes sense for many skins, there's nothing inherent in the XBMC codebase that requires it to be this way. Indeed, some skins (mc360 for instance) work quite differently with respect to this, so a home button makes little sense for them, so we have to be a little careful about how things tie in.
Ok, makes sense.
jmarshall Wrote:If we have a back button on the UI for mouse users, then mouse users have 2 actions available separately: They can go up a directory or can go back a screen. This is no different than allowing this through the keyboard mapping as we do now.
Agh, I don't know man, I think there's just something wrong with the design. As a user I don't see why there needs to be a differentiation between screens and directories... When I navigate I really don't think of it that way. Personally, I'm used to the notion of going forward one screen, going back one screen regardless of type, as in the iPod, Apple Tv, Media portal.
This to me is more evident in Library mode, especially when navigating TV Shows. When you select a show, it shows you the seasons, then when you select a season it shows you the shows. If I want to select another TV show I go back a couple of "screens". As a user I just see them as screens, I don't think of them as directories.
By forcing the user to have Esc and Backspace for navigation, he's forced to think about which of the screens are screens and which are directories. I think this is just confusing and completely unnecessary.
What if we were to have users familiarize with the concept of a "home" which most already are? And then have everything being a "screen"? Then the navigation would be much easier. I think most if not all skins can accommodate to this.
I don't know.. you probably have more ideas than I do; how can this be made such that there is only 1 back button? Media Portal does this, Esc does bring you back 1 level, whether it's files or screens. And media portal also has a home button. I think it works really well.
jmarshall Wrote:What we really need to think about, though, is whether or not we allow something like "backspace" which is the current "up directory" action to also function as a "previous menu" in some areas. I have no real issue with doing so - indeed, it's already done for the B button on the xbox gamepad. The next issue is whether or not "backspace" is the key to use for this, or whether or not "escape" or some other key is more useful. Backspace is the default mapping on a windows machine for going up the heirachy in explorer for instance - I'm not sure whether this is the same on linux or os x machines (os x machines generally not having separate backspace and delete keys.)
Right, on OSX the key is ⌘↑ (command up), it's not too popular though. Backspace on OSX is just reserved for deletion.
As for backspace vs esc vs other button, I see a couple of issues on choosing backspace over esc for a back button. Currently backspace does not close context menus or OSDs, nor does it stop playback. In fact during playback it's mapped to SmallStepBack (really hate that one lol). Also it doesn't "go back" in the settings page. Even if we were able to change this, there might be a problem in cases where text is being input with the keyboard. In such cases backspace obviously acts as a deletion key. This would conflict with the notion that the back button should work everywhere since in this case it wouldn't. Ideally the user should always be able to get back to something by pressing the back button.
jmarshall Wrote:To address your other changes:
1. I agree that "C" should close the context menu.
2. "A" to toggle audio settings is fine - does "V" then toggle video settings? The visual feedback of "AudioNextLanguage" is a separate issue - mind trac'ing that one - it applies to all button presses in fullscreen that have no visual feedback currently.
3. "C" to bring up the OSD's is inconsistent with in-UI OSD's. This is why we use "M" in this case - it always brings up the OSD if something is playing, no matter where you are, so I'm in two minds about this one.
4. I disagree about "escape" from home. The problem is that users may "overrun" and get back to fullscreen when they were wanting to get to home. It also defeats the "previous screen" notion as you can actually get in to a loop toggling between home and fullscreen.
Visual feedback is indeed a separate issue. It'd be really nice to have visual feedback when a subtitles or AudioNextLanguage key is pressed for example.
V toggle for video.. definitely good idea.
"C" to bring up the OSD's is inconsistent with in-UI OSD's, what do mean?
About esc going to fullscreen in home, I agree, this is just a personal preference. Some users might like esc to bring up the shutdown menu. I don't think there is any perfect mapping in this case, I just didn't like it not doing anything, and I found it useful to be a fullscreen toggle. Also it's not "harmful", ie, if there is nothing playing then it won't do anything. But yea, this is just a personal preference.