Kodi Community Forum
XBMC "BACK" verses the "ESCAPE" button? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Windows (https://forum.kodi.tv/forumdisplay.php?fid=59)
+---- Thread: XBMC "BACK" verses the "ESCAPE" button? (/showthread.php?tid=38692)

Pages: 1 2 3 4 5


XBMC "BACK" verses the "ESCAPE" button? - Sukebe7 - 2008-10-09

I am using XBMC with my MCE XP remote and I have mapped the Back button to the same action as hitting backspace on the keyboard. Everything works fine, I can navigate the menus very well, but once I play a video hitting the back button doesn't go back to the video selection menu. All it does is rewind the video a little bit. I would have to hit escape in order to go back to the video selection menu. That would mean mapping an additional button on the remote and making everything very unintuitive.

Is there anyway to get the back button to actually go back to the previous video selection menu instead of rewinding the video?

I am using Atlantis Beta 2.


- jmarshall - 2008-10-09

Keymap.xml is your friend. Remap the keys how you wish.


- Sukebe7 - 2008-10-09

This is not a key remapping issue though. I can map the buttons on my remote to whatever I want. The issue I am having is that I don't want to map both "back" and "escape" on the remote. I want the back button to go back to the video selection screen instead of it rewinding the video. If I map the back button to escape, then I won't be able to navigate the menus, since escape would goto the main menu.

Since there is already a rewind button AND a step back button, I don't understand why the back button doesn't go back to the menu by default.


- jmarshall - 2008-10-09

Your keymapping is either:

1. Mapping directly to xbmc actions in keymap.xml, whereby you just need to modify those actions.
2. Mapping indirectly to xbmc actions via an additional mapping to keyboard keys, remote buttons or whatever, whereby you need to modify those actions.

What is the method you are using to map your remote?

Note that BACK on the xbox gamepad is mapped by default to "small step back", which is not the same as rewind or step back or large step back.

Cheers,
Jonathan


- migueld - 2008-10-09

Sukebe7 Wrote:This is not a key remapping issue though. I can map the buttons on my remote to whatever I want. The issue I am having is that I don't want to map both "back" and "escape" on the remote. I want the back button to go back to the video selection screen instead of it rewinding the video. If I map the back button to escape, then I won't be able to navigate the menus, since escape would goto the main menu.

Since there is already a rewind button AND a step back button, I don't understand why the back button doesn't go back to the menu by default.

Yes you are right, there is a problem when one tries to map a back button to a remote in XBMC. I asked for a fix and there has been progress and I hope there continues to be.

In the meantime I recommend that you map the back button to Escape. You can modify the keymap.xml file such that Esc behaves like Backspace when browsing your files/media.

The Plex team actually implemented this, and you can probably use their keymap, or at least look at it to see the changes. I did one myself, you can look into it here: http://forums.plexapp.com/index.php?showtopic=1118&hl=universal+back

jmarshall, any idea on when this will come to XBMC? Is there any resistance to change :p Wink? If it's up to discussion let me know Wink


- jmarshall - 2008-10-09

Everything is always up for discussion, though ofcourse the outcome of said discussion is not necessarily to everyone's liking. Fortunately we're completely open about what we do, and anyone at all is welcome to contribute in whatever capacity they wish.

If one is several levels deep in a directory hierarchy, there's a large benefit in being able to exit directly out to the previous screen without having to go all the way up through the hierarchy. It has the added benefit that when you return to the category you were in you stay exactly where you were last time around - no need to go all the way back down the hierarchy.

Whether this is done using the same set of keys we have at the moment is up for debate. I personally think the keys we have make some sense:

Escape: always takes you back a screen.
Backspace: always takes you up a folder. If there's no folders left it takes you back a screen.

Whether or not there's merit in "double mapping" backspace so that it doubles up on what escape does in fullscreen views is up for debate. I have no preference either way.

What I do dislike is the hack that is mapping remote control buttons to keyboard keys. This IMO is not a solution that works long term - the user should be able to map their remote keys directly as much as is feasible. Unfortunately remote control manufacturers don't tend to make this easy!

Cheers,
Jonathan


- migueld - 2008-10-09

Thanks for the insight. Let me ask you, when you mention "exit directly out to the previous screen" aren't you really meaning the Home screen? I can't think of another screen that meets your criteria with respect to the advantages you mention, other than the home screen. Having said that, wouldn't that be addressed by the Home button?

Suppose that you are browsing files deep into a directory and you then hit Home; it'll take you back to the home screen. Then, next time you go to the file manager, you'll be exactly where you left off. That would be consistent with advantages you mention, on which I agree.

Having said that, if the Esc button were made so that it always takes the user to the previous thing (whether it's home, or a directory, osd, etc), then when you need to exit directly to the home screen you can still do so by using the Home key.

Jumping right to the home screen is probably the most significant use case, if not the only one, where the user would choose to "skip" screens.

Putting this into perspective, this would be consistent with a request that was made not too long ago made by Gamester17, to have a "Home" and "Back" button in every screen to enhance mouse support. If that were to be implemented then the GUI would have a keyboard equivalent.


- d4rk - 2008-10-09

The primary issue I think is definitely related to the fact that the remote commands, in this case, are being mapped into keyboard commands (like jmarshall mentioned). Thus, you need to modify the keyboard mapping to affect your remote mapping, and that's not always desirable.

The issue can however be resolved by using an event client (assuming there exists on for this case) and have the event client use a map other than the keyboard map (joystick, universal remote etc), where each remote command can be mapped per window and globally without interfering with the keyboard mapping. This is how the event clients for the PS3 BluRay Remote, PS3 Sixaxis, Apple Remote and most of the other event clients work (for Linux and OS X).

In addition, if an event client ends up using a joystick mapping, the map can be given any name so there is absolutely no chance of conflicts with other keymaps.

In this case, for Win32, I'm assuming you're using something like Event Ghost or IR Server Suite. If the suite supports plugins, then a plugin can be written so that the remote commands it received are directly transmitted to XBMC's event server instead of virtual keyboard commands. Of course, someone still have to write the plugin, but that would definitely solve the issue permanently IMHO.


- DragonFly - 2008-10-09

migueld Wrote:I did one myself, you can look into it here: http://forums.plexapp.com/index.php?showtopic=1118&hl=universal+back

Could you post it here. The attachment is blocked if you're not a member.....


- Sukebe7 - 2008-10-09

migueld Wrote:Yes you are right, there is a problem when one tries to map a back button to a remote in XBMC. I asked for a fix and there has been progress and I hope there continues to be.

In the meantime I recommend that you map the back button to Escape. You can modify the keymap.xml file such that Esc behaves like Backspace when browsing your files/media.

The Plex team actually implemented this, and you can probably use their keymap, or at least look at it to see the changes. I did one myself, you can look into it here: http://forums.plexapp.com/index.php?showtopic=1118&hl=universal+back

jmarshall, any idea on when this will come to XBMC? Is there any resistance to change :p Wink? If it's up to discussion let me know Wink

Thanks Miguel,

That thread you posted describes exactly what I wanted to accomplish. I will try taking a look at the modifications and mappings and see if I can do something similar. I am still puzzled that something like the "universal back" button was not implemented by default. It makes the GUI way more intuitive.


- migueld - 2008-10-09

Here's my keymap with some tweaks:

http://www.mediafire.com/file/nmulyiozwzm/Keymap.xml.zip

Tweaks are:
• Pressing "a" during video playback will toggle the Audio/Subtitles osd. I liked this better than the current "AudioNextLanguage" since it gives visual feedback.

• Pressing "c" toggles the contextual menu (before it'd only open it, now it can also close it), and also brings up the video OSD, and music OSD. I think of this as the "universal options" button. I like it better than having another key "m".

• Pressing Esc in the home screen will toggle fullscreen if there is something playing.

Edit: Also the "Home" key now works in a Mac keyboard.


- migueld - 2008-10-09

d4rk I completely agree that it'd better to be able to map to something other than the keyboard mappings. However, the issue isn't just when mapping remotes, I think the issue also applies to users that use the keyboard exclusively. Think of users of the Logitech Dinovo mini, or Apple's wireless aluminum keyboard for example. Personally I use a remote (PS3) but I still use the keyboard from time to time and it'd be nice to have a streamlined set of keys for easy navigation.

Also, think of new users who are trying out XBMC and find that to do simple navigation they are required to use multiple keys. It's not too user-friendly. I think it makes more sense to have Esc act as a "Back" button, have the "Home" button act as a shortcut to the home screen.

Many users are used to the iPod-like navigation, where one moves forward or backward one step. I think this implementation would feel more familiar to most users. And it's not just the iPod, there is also Media Portal and Apple TV which come to mind, that feature this implementation.


- jmarshall - 2008-10-09

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.

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.

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.)

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.

Cheers,
Jonathan


- kricker - 2008-10-10

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.)
This is the biggest change I hope for. I am often in context menus or some other dialog and escape closes some of them and backspace closes others. I'll make a list if it is helpful.


- migueld - 2008-10-10

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.