[barberio]

This has come up occasionally in the feature request forum, but has been buried under a confluence of not really understanding the problems, it being something that can be fixed by the end user (but only by editing keymapping), and relatively low priority.

The idea is that the 'ParentDir' and 'PreviousMenu' functions currently have no meaning on the Home window, because it's the root window/menu so there's nothing to go 'back' to. However, this is not what the user expects when they press the buttons tied to these functions. They expect to go 'back' to any playing media when at the Home window, and this is how these functions work on most Video Set Top Boxes/TVs, as well as WMC and Boxee.

I'd like to have a crack at fixing this, but at the moment it looks like the only way to do it is update every default keymap for all currently 'out of the box' supported devices, to add in an over-ride for Home.

Would this be the preferred way of setting this, or am I missing some easy way to do a function remap per-window across all kinds of device that doesn't involve hard coding it into ButtonTranslator.cpp which could have bad side effects.

What I'm basically asking, is am I going to have to make this a development issue that needs changes to the action handling logic, or am I best putting this in the keymap config files and having to have the function added in for all new device keymaps added.

<b>Edit</b> Actually, this doesn't look like it can be done with a simple edit to keymaps for anyway, because the function doesn't work the way I thought it would. Ignore this post while I go back and work out what I need to do to get the function working properly.

[barberio]

Right...

The problem is this, there is no current action that will toggle between showing the current window's and showing only video. The Fullscreen function only hides the window's UI elements, and doesn't bring them back if they're already hidden. Since you're still on the home window, if you remap the ParentDir/PreviousMenu key to Fullscreen on the Home window then you get stuck with the menu items hidden instead of the toggle function I'd like to implement.

It looks like what I want needs a new action created that hides/brings back the current window's UI elements. Which I think is probably beyond my understanding of XBMC's code right now.

[stagecrew]

Recently I switched to a Boxee remote (more on this later, including a massive script to make sure the remote only targets XBMC, even if other stuff is being used.) and due to the button constraint I set it up to do this.
Now, I set it up through keymaps, but I agree that XBMC should be intuitive out of the box, and this is something that should change.
It seems that the reason you are giving up on this that xbmc hides the gui, but doesn't bring it back?
I've set my remote that in fullscreen video, pressing back toggles fullscreen again, bringing the GUI back.

Does that make sense? Or am I missing your point?

- Derek

[barberio]

I've set my remote that in fullscreen video, pressing back toggles fullscreen again, bringing the GUI back.

Does that make sense? Or am I missing your point?

- Derek

Ah, I think I know what's happening there... Seems to be a subtle behaviour that lets the fullscreen-video inherit the keymappings of the last window not the defaults. So if I explicitly reset those keymaps for the fullscreen-video window, it should have the correct behaviour. I'll test that out as soon as I can.

However, I think this might be an argument that it should be hard coded in, that when a ParentDir action makes no sense a call to it should call PreviousMenu, and where a call to a PreviousMenu action makes no sense (ie, when at the root 'Home' screen) then it should fall back to Fullscreen. While PreviousMenu from Fullscreen still makes sense to bring back the GUI. But I've no idea how to implement that.

[jmarshall]

The main issue is that the existing functions really don't make sense to the majority of users. In my opinion, the best way to fix things is to:

1. Get rid of PreviousMenu action in the default keymappings, or at least ensure it's not required in any keymap in order to navigate. Internally this involves handling number 2 here (primarily in dialogs)...
2. Rename ParentDir to Back, and have it do as it does already in media windows (and most windows), i.e. parent dir by default, no parent then back out the window.
3. Introduce the use of "Home" via ActivateWindow(Home) where it makes sense to do so in keymaps.
4. In the home window, make Back toggle back to fullscreen if something is playing. You'd do that in CGUIWindowHome::OnAction.

This pretty much does everything one might want in general day to day behaviour, however there's a few cases where things aren't quite as easy - the obvious one being the file browser dialog. Here you might want to cancel the dialog out without navigating all the way up to the root. You do have the cancel button, but it isn't as fast to navigate to it.

Doing number 2 is the first step - i.e. ensuring that the existing ACTION_PARENT_DIR is handled absolutely everywhere. This can likely be done for the most part by an addition in CGUIDialog::OnAction().

Cheers,
Jonathan

[topfs2]

Personally I kindof like the MCE paradigm over apple but I guess it depends on how you began. MCE uses home to take you home but when in home this button takes you to fullscreen video. I guess it also depends on what someone defines as base, I want pressing back unlimited times to bring me back to my origin, for me this is home, not toggle between fullscreenvideo and home.

So:
Press home from any window except home-window -> go home.
Press home from home-window -> go fullscreenvideo

I just find the mce paradigm to be a lot more clear, obviously personal view

Anyways, the points 1-3 I totally agree with.

[barberio]

Personally I kindof like the MCE paradigm over apple but I guess it depends on how you began. MCE uses home to take you home but when in home this button takes you to fullscreen video. I guess it also depends on what someone defines as base, I want pressing back unlimited times to bring me back to my origin, for me this is home, not toggle between fullscreenvideo and home.

MCE actually does use 'back' from the home screen to toggle between home and fullscreen video tho.

[barberio]

The main issue is that the existing functions really don't make sense to the majority of users. In my opinion, the best way to fix things is to:

1. Get rid of PreviousMenu action in the default keymappings, or at least ensure it's not required in any keymap in order to navigate. Internally this involves handling number 2 here (primarily in dialogs)...
2. Rename ParentDir to Back, and have it do as it does already in media windows (and most windows), i.e. parent dir by default, no parent then back out the window.

I think I agree on removal of PreviousMenu, I don't even have that mapped to a key on my remote, and am always annoyed when I use a control device that has PreviousMenu mapped to the obvious back key instead of ParentDir.

ParentDir can retain it's internal name just to make it less of complicated change for UI developers. To try to make the transition as soft as possible, and because the name ParentDir still makes sense to the programmers, I'd consider deprecating PreviousMenu and making it an alias of ParentDir.

In user visible UI elements and documentation, ParentDir can of course be referred to as 'Back'. While the documentation for UI developers says that ParentDir provides the Back Functionality, and has certain special cases.

[barberio]

Having said that, I wonder if it might be a better idea to move to abstracting the direct actions, from the user functions.

So that a 'back' key function is a virtual one that results in 'previous menu' 'parent dir' or 'full screen video' actions dependant on context.

This layer would then allow for a review of all the actions, to work out which ones can be triggered from single context-dependent user functions. Making key mapping on all devices a matter of selecting the right set of abstract functions for the keys, not assigning direct sets of actions and contexts for those actions to each type of device. This would allow for a 'virtual remote' model which has the keys we expect remotes/keyboards/gamepads of various kinds to have.

Then there could even be work on creating a set of eight major user functions by which the entire system can be controlled, which would be a great improvement for using XBMC from smaller remotes.

[topfs2]

MCE actually does use 'back' from the home screen to toggle between home and fullscreen video tho.

hmm, I only ever used mce 2k3 or what its called, never the vista/w7 one, so perhaps it was a bad example Anyways, I find back toggle fullscreen kindof weird but as said it might just be personal taste.

This is something I'd really liked tested against the masses and not the enthusiasts here though (me included).

[barberio]

hmm, I only ever used mce 2k3 or what its called, never the vista/w7 one, so perhaps it was a bad example Anyways, I find back toggle fullscreen kindof weird but as said it might just be personal taste.

This is something I'd really liked tested against the masses and not the enthusiasts here though (me included).

Mashing the back key to reach a steady-state isn't really a user friendly concept tho. If you want to have a steady-state, then it makes more sense to have a single button that brings the user to this steady-state from where ever they are.

[topfs2]

Mashing the back key to reach a steady-state isn't really a user friendly concept tho. If you want to have a steady-state, then it makes more sense to have a single button that brings the user to this steady-state from where ever they are.

My argument is this really, you have two kind of people (or cases).
a) You have the guy who thinks "I want to go home" -> "press home"
b) And the one who thinks "I want to go back home" -> "press back multiple times"

My thinking (no evidence to support it) is that the case a) is less likely to press more than once than b) which might miss and press back one to many and get confused.

Obviously non of our suggestions have steady state, and ideally I guess back multiple times and home multiple times bring you home, then to get to now playing you press a "now playing" button.

Easiest is probably to have it keymapped so it depends on the remote (as the one with apple remtoe is more likely to like the way apple works).

[barberio]

Obviously non of our suggestions have steady state, and ideally I guess back multiple times and home multiple times bring you home, then to get to now playing you press a "now playing" button.

The problem with your idea, is you have now created a new action that requires yet another button map. XBMC can't keep adding on new button maps, or expect the user to 'just map that to a button' when they are very likely already using every button on their remote.

People don't make remotes with a button for every possible function in every possible context, and they actually try to keep the number of buttons down to the minimum possible because each extra button is an extra cost to production. You may well have a giant remote with tons of buttons, or as some people would call it "a keyboard", but usability should be based on the minimum interface being used not the biggest and best one.

XBMC needs to be controllable from a small remote with a minimum of buttons. Image trying to control XBMC with a remote that only has nine buttons; Power, Rec, Up, Down, Left, Right, Play, Record, OK and Back; and being able to access all the common functions of a Media Player and PVR immediately. Extra buttons than these major ten are convenience buttons, not major functions.

Also think about using XBMC with an Apple remote and only *six* buttons, but still being able to navigate and access the important functions.

I'm going to suggest the following. Devs are forbidden from introducing a new function with the phrase "to [do something] you press a '[do something]' button.", and instead have a moratorium on introducing new actions and instead work on consolidating down to the minimum set of actions needed, and context sensitive functions instead of direct one-to-one button-action maps.

Easiest is probably to have it keymapped so it depends on the remote (as the one with apple remtoe is more likely to like the way apple works).

This again is causing problems since it loads a lot on having to produce tons of special cases for every possible input device imaginable.

The basic set of ten key functions should be device independent, and act the same way across all devices. Or it'll produce user confusion.

[jmarshall]

If you want to do it just pick up PARENT_DIR in the windows that don't do it and map it to close the dialog/window.

Then change the define in Key.h to ACTION_BACK (separate commit).

Then change the keymap definition so that "back" can be used as a replacement for "parentdir" and "previousmenu" - parentdir will still do back, and previousmenu will still do previousmenu.

The key is to get "back" the action that is there by default and works everywhere, thus ensuring we adhere to the 7 button principle, and ensuring everyone's control device works out of the box. This same principle then requires BACK on home to go to fullscreen (when playing, ofcourse) as there's no other options.

Am more than happy to comment/critique any changes.

There should be no need for abstraction - it's already contextual to the window anyway, and improving the context is "just" a matter of redefining those contexts (which is a separate patch - you'd be more than welcome to work on that as well!)

Cheers,
Jonathan

[barberio]

If you want to do it just pick up PARENT_DIR in the windows that don't do it and map it to close the dialog/window.

Hmm... I'm not sure I'm up to auditing through every dialogue and windows to find the ones that don't close when they receive a parentdir without any directory to move back on.

But the one's I've find just by looking over 10.1, I only found the Add Sources dialogue and the Music OSD as the only windows and dialogues that don't use parentdir as an all-purpose back. (but oddly, the Video OSD does)

Also, I'm still slowly picking my way through the code working out how it all hangs together. And I'm not the worlds greatest coder. So if you wait on me for this, you might be waiting a looooooong time since I don't have a clue where to start on that.

Then change the define in Key.h to ACTION_BACK (separate commit).

Then change the keymap definition so that "back" can be used as a replacement for "parentdir" and "previousmenu" - parentdir will still do back, and previousmenu will still do previousmenu.

There's no reason to rename 'parentdir' or create a new 'back' action, if 'parentdir' is going to be implementing that function.

Wouldn't it then be a good idea to depreciate 'previousmenu', is there a reason to keep it? To the non technical user, this function just drops them back to an apparently random level, because there's no obviously consistent definition of what the 'previous menu' is over the 'previous UI layer'. In fact, taking 'previousmenu' out all together in a test build, to work out what depends on it, then fixing those to use context appropriate 'parentdir' might be a plan, but that needs to be done during a period of stability. And should perhaps come as a push to consolidate actions and eliminate those that don't make sense, are redundant or are extraneous.

There are currently 227 defined actions.