Right Windows key not opening Menu

[thomasthorsen]

The left Windows key (or Super_L) correctly opens the Menu, however the right Windows key (Super_R) does not. This is especially inconvenient when you have a keyboard that does not have a left Windows key (this is the case on some laptops and some normal keyboard where the location is used for an "fn" key).

For reference this is the xev output from pressing the right Windows key is:

KeyRelease event, serial 34, synthetic NO, window 0x3c00001, root 0xbc, subw 0x0, time 842862216, (316,-118), root:(317,400), state 0x50, keycode 134 (keysym 0xffec, Super_R), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

[AlbertJP]

Hi Toomler. On my laptop it's the opposite, I only have a Windows key (as well as Fn) on the left. But probably I can try to get this fixed om my desktop which has two keys with Windows 98 logo.

[thomasthorsen]

Yes, i recon that most laptops is like yours, and that my keyboard is probably a little bit odd. For reference, this is the keyboard in question: http://images.pricerunner.com/product/image/74456556/ACE-KL300-Slim-Multimedia-Keyboard.jpg Thanks for looking at this, a fix would be highly appreciated!

[rjanja]

To accept both Super_L and Super_R will probably require modifying the source of Muffin, Cinnamon's window manager.

If your keyboard only has a right Windows key you can switch the Muffin binding to use it by opening a terminal and: $ gsettings set org.cinnamon.muffin overlay-key Super_R (then Alt+F2, r)

It would be nice if it worked out of the box on systems with only a right Windows key. (It's a pretty big feature to have missing!)

[thomasthorsen]

Thanks for the workaround, but it doesn't seem to work here:

gsettings set org.cinnamon.muffin overlay-key Super_R No such schema 'org.cinnamon.muffin'

[AlbertJP]

@Toomler org.cinnamon.muffin exists on Mint 13's version of Muffin. On Mint 12's default muffin you indeed don't have it yet.

[thomasthorsen]

Right, I am using Linux Mint 12

[phw]

Indeed Cinnamon (or muffin) should bind to both keys. E.g. my laptop also only has Super_R (the button is on the left, but it triggers Super_R nonetheless), and at home I attach a USB keyboard which only has Super_L. So even if I would change the keyboard binding I could not satisfy my needs for both keyboards.

[thomasthorsen]

So I'm guessing this is not fixed in Cinnamon 1.6?

[AlbertJP]

It indeed isn't.

[mtwebster]

You can re-define the menu key now in Cinnamon settings. Note as of 1.6.3 this will work only in Ubuntu-based distros (Ubuntu, Mint, maybe LMDE) - pure GTK environments cannot do this unfortunately.

[anandrkris]

@thomasthorsen - Could you close the issue? It can be achieved using the below steps. Navigate to System Settings > Keyboard (Hardware) > Keyboard Shortcuts > System

[thomasthorsen]

@anandrkris sorry, but that's not a solution to the problem, that is merely a (bad) workaround.

[anandrkris]

@thomasthorsen You want Menu function to be binded to both Super_L and Super_R keys by default? Apologies, to me changing to the required key-binding seems like a perfect solution.

[mtwebster]

Fixed in current master. All system and custom hotkeys can have up to 3 bindings, applets can have 2 for each action.

[thomasthorsen]

@mtwebster what is the default setting for the Menu button?

[mtwebster]

Default right now is still just Super_L

[thomasthorsen]

So this issue is not fixed then

[anandrkris]

@mtwebster - If it not too much of a hassle, can we have Super_R mapped to Menu by default?

[ghost]

Hi, there are several keyboards configurations, with several similar keys (that it's not the same key). This occurs normally, and this problem is not related with cinnamon, is relate with user preferences... Some user want to have differents behaviors to the similar keys in right and left, another users only want to have one behavior for similar keys.

@mtwebster has made some options to modify the keybindings and also now you has multiples keybindings. Just for me, is to much...

The problem here it's not cinnamon, is how user want to have the keys. If I have two windows keys and I only want to have one for the menu, why then i need to have by default the two keys active on cinnamon menu...

Please see that one thing will be flexibility (that now cinnamon has to much of this), and another will be the user desition.

Really the correct solution for this problem, is modify the map of keys, in your computer, to be used like you want. All programs uses only one windows key, and ofcourse that @mtwebster can not fix all external programs... So please, if your intentions will be that the right and left windows key could working at the same way, you need to remap your keyboard using xmodmap. Please see: http://blacketernal.wordpress.com/set-up-key-mappings-with-xmodmap/

or simple search for xmodmap in google or other way to remap your keyboard.

[thomasthorsen]

@lestcape sorry I do not agree with you at all. This has nothing to do with user preference, this has something to do with common keyboards flat out not working out of the box for reasons that are completely beyond the control of the user. The problem is that with the current default settings there is absolutely no clue as to why it is broken - nothing happens when you click the Windows/Super button, it could be hundreds of different things that are the reasons for that. If both the Windows/Super keys are mapped by default and a few people, for some reason I cannot understand, does not like that, it is easy enough for those people to determine what is going on and adjust accordingly. There is a far greater probability that novice users will not be able to figure out how to make it work for them, than users who wants to disable one of the buttons cannot figure out how to do that.

[ghost]

@thomasthorsen I understand what you say, but not its different of what I say... Maybe a solution will be check if the key exist and if this key do not exist, then using another key for initializing the menu key bindings. But not have several keys at the same time by default, only use one. Could we agree now?

[thomasthorsen]

@lestcape sounds like a really fragile and unnecessarily complex solution. I doubt it is even possible to check if a key exists. I don't see the problem in binding both keys. What are you trying to fix by not doing that?

[ghost]

@thomasthorsen For the special keys, that may not appear in some keyboards and are used by cinnamon as default in some places, needed to have a list with priority of alternatives keys that could be used, in the case of that primary keys do not exist...

Do you know that are some keyboard that do not have windows key(not left and not right)? What do you try to solve, your problem only? This is your robust solution?

It's possible that you can not know if really your keyboard have a key, but if you set your keyboard layout correctly, you can see if the key appear if you check the current keyboard layout.

[mtwebster]

@lestcape I think you're under the assumption that if I allow two keybindings per applet setting, you must use both. This is not true - you can have just one, or both, or none set. The point is, it's completely up to the user, and no messing around with keymaps. Ideally, of course there's a way to pick your exact keyboard, and all the keys work as expected.

This is simply not possible in the real world, especially in the linux world, where very little effort is expended by hardware manufacturers to support the OS, compared to Windows.

So, we could adopt the old-school Linux mentality, and expect users to learn how to change the keyboard mappings using scripts and config files, or simply let them do what they want, and make it easy. It's not the perfect solution, but it's a decent solution. For the keys this is usually an issue with, they're not generally used for anything but one or two purposes.

Super/Windows key isn't used by many applications on its own - as a modifier, yes, but that is not an issue here. Super as a modifier does not distinguish between left and right, only as a standalone key value do we run into this problem.

[ghost]

@mtwebster, I'm not speaking now about keymaps. This clear is not for all user, i speak about keyboard layout(this is other thing) that is a thing that all users need to know.

Like example: You can not translate an applet to russian language if user have a locale on english.

In the same way, you can not know if a key exist or not if user have a wrong keyboard layout(not the same that keyboard map), but you can do actions thinking that user know what he/she are doing when select the keyboard layout in the installation process or later. So you can have a plan of actions base on this, and if user select a wrong keyboard layout it's a user problem(not a bug)... But if user select the correct keyboard layout, you can know in about 99% if a key it's present on the keyboard or not. In the worse case, problem will be linux keyboard layouts list, and not of cinnamon and user have a way to report the problem in the correct place.

I guess not all is well, but I do not think you need to do unnecessary things or shoddy, if there are an standard way. I hope someone can understand me and can explain what I mean, because I think it is not understood.

[ghost]

Just an example:

Oposite to that idea of duplicate the key and more related with my idea, of change the hotkey for other (but only one hotkey at the same time) there are some applications like firefox, open office, Gtk, KDE, where the hotkeys are related with the language. This is clear more hardly than only check for keyboard layout and the existence of a key in it, and clear that they do not add all possible hotkeys in all languages. I will be happy to know, that other people, desktops, applications, or any thing, have two or more different keys for the same action by default. This will be another perspective for me, and this will convince me that i'm totally wrong.

https://bugzilla.mozilla.org/show_bug.cgi?id=69230

[mtwebster]

Well Cinnamon has allowed multiple bindings on all but media-keys since 1.8, Gnome-Shell, gnome-panel before it have always allowed it as well. This isn't something remotely new for Cinnamon, I just made everything behave more consistently.

[mtwebster]

https://github.com/linuxmint/Cinnamon/commit/9dc27e0c5ac61017a066e769c4eda7fb9e74442f

[thomasthorsen]

Thanks @mtwebster!

[ghost]

I don't say that duplicate keybinding could be wrong(i really don't know), is only out of standard(confused), and it's needed by a few, and is confused for several... For me it's good that user can define multiples keybindings, if this is present like an alternative, but not by default.

My intention is not to argue or to force done as I say. It's to show my point of view (which I think is not only my own). I think now it was understood, here I stop.

[collinss]

@lestcape I'm with @thomasthorsen on this one. My keyboard only has one super key, but if I did have a second one (or if it was on the other side of the computer), I would expect that it would behave EXACTLY the same UNLESS I set it up to behave differently. As an example, you wouldn't expect the right and left shift keys to behave differently just because they are on different sides of the keyboard.

The nice thing about the current implementation is that if you want a different behavior, you can always remove the keybinding and use it elsewhere. Anyone who would want to mess around with keybindings should be able to figure out how to change them easily enough, or at least be willing to do some digging for the proper solution. On the other hand, a novice user will be very confused by the 'menu' key not opening the menu, and will likely have no idea how to make that key work the way they expect.

As for your keyboard layout argument, that sounds like a different issue entirely to me, and would still be an issue whether you have one keybinding set by default, or two.

[ghost]

@collinss you are new, i think that all people want to have : 1- A way to change the keybindings. 2- Multiples keybindings if they want. 3- By default all keybindings work.

Here we talk about the default way of keybindings, and how could be implemented in the best way.

Currently problems that i see: 1- A keyboard without Super key do not have a keybinding active for the menu. 2- There are more than one keybinding active for the same action by default and this is could be confused, for some users like me: https://github.com/linuxmint/Cinnamon/issues/3416

This is all.

[collinss]

@lestcape I may be new to the conversation, but I have been following the issue and I did read all the previous posts. I don't think anyone is arguing with you on your three points. What I'm saying is that most people expect that a menu key opens the menu, regardless of where it is on the keyboard. If, on the other hand, they have no menu key, they would expect (I imagine) to have to set a keybinding themselves if they want to have that functionality. IMO the current implementation by @mtwebster is the best way to handle all cases.

In any case, I was trying to frame my comment in the context of the OP, which is why I said that I thought the keyboard layout problem is a different issue - super_L and super_R are both fairly standard keys AFAIK. It seems to me that what you were saying about the keyboard layouts was dealing with less common and less standard layouts. Dealing with this issue (while not a bad thing) is different than setting the default action for more standard buttons, and so should be opened as a separate issue.

[ghost]

@collinss this is the problem, you don't understand what i say, because you speak a differents things... The solution of @mtwebster it's not a solution for this problem. Can be used as a partially solution, but it's not a solution. Here we speak for a solution for what? For a particular problem of a keyboard with one right windows key? if it's true, then the solution of @mtwebster also resolve this problem, but cloud be resolved called internally another keybindings more, and this is complete separate of all work that @mtwebster do. Also a desktop can not be do things by things and patch by patch, you need to thinking in a general solution that resolve all similar problems, like @mtwebster try to do...

If the problem will be have a general mechanims to resolve this type of problems, duplicate de keybindings it's not a good solution. How many keybindings do you want to duplicate? Will be complete wrong use this for resolve all similar problems. So, there are not right now a good general way to resolve this type of problems with a good general mechanims.

[ghost]

Also the this mechanims don't resolve all keyboard problems similar to this problem, like for example a keyboard without Super key... So, the thing that @mtwebster do, it's an intresting thing and can be used by user to resolve particular problems, but it's not a general mechanims to resolve this type of problems...

[ghost]

This is not easy for me test a better solution, because global do not share the gdk_display for cinnamon. Only the metadiaplay, and i can not construct the keymap without the cinnamon gdk_display. Try to use the default keymap (Gdk.Keymap.get_default()), but cause several inconsistencies, could not be the current display used by cinnamon, and sometimes translate keyboard state, or lookup_key, return a different things... I need to try also with IBus, imports.gi.IBus but appear to be more complex...

[collinss]

@lestcape I understand what you are saying, but you can't possibly cover all possible keyboard layouts in the defaults. Even if the code were changed to check for the existence of a particular key before setting a keybinding, and then changed to something else, what would it be changed to? (I certainly wouldn't expect the escape key, for example, to open the menu just because I don't have a menu key.) In most (if not all) situations, the answer is not obvious, which means that the user will probably not know the answer anyway, so it defeats the purpose of having such a feature, since the user will have to open the settings to know what that keybinding is.

An even worse scenario is if the keybinding is changed to something else and the user accidentally activates the feature while trying to do something else. This could be extremely confusing and frustrating to the average user. On the other hand, if a keybinding is set by default, and the keyboard doesn't have that particular key, there should be no problem, since there is no way to activate the key anyway. The keybinding will merely be rendered useless until the user changes it to something they actually have on their keyboard.

Besides all of that, this issue is specifically about the default menu keybinding, a fix has been implemented, and this issue is closed. That is why I'm saying a separate issue should be opened to handle alternate keyboard layouts.

[ghost]

@collinss This issues cause this commit: https://github.com/linuxmint/Cinnamon/commit/9dc27e0c5ac61017a066e769c4eda7fb9e74442f also closed.

Why you prefer speak in an open thread? I prefere speak in a closed thread, to not affected cinnamon.

This code not work yet, but this is my first idea about how you can replace not valid key for a valid key in current keyboard layout...

Simple you can have a list of alternatives keys predefined on order of priority and use other key if the first fail... Example: Super_L fail use Super_R, if also Super_R fail use Control_R...

//keybindings.js

const Gdk = imports.gi.Gdk;

const ALTERNATIVE_KEYS = {
    "Super_R": ["Super_R", "Super_L", "Control_L", "Control_R"],
    "Super_L": ["Super_R", "Super_L", "Control_L", "Control_R"]
}

function get_valid_key(key_name) {
   let resultKey = key_name;
try {
   let keymap = Gdk.Keymap.get_default();
   //let keymap = Gdk.Keymap.get_for_display(global.gdk-display); //global not export the display
   for(pos in ALTERNATIVE_KEYS[key_name]) {
      let key_code = Gdk.keyval_from_name(ALTERNATIVE_KEYS[key_name][pos]);
      let val = keymap.lookup_key(keymapKey);
      if(val != 0) {
         resultKey = ALTERNATIVE_KEYS[key_name][pos];
         break;
      }
   }
 } catch(e) {}
   return resultKey;
}

function KeybindingManager() {
    this._init();
}

KeybindingManager.prototype = {
//.... more code
   addHotKey: function(name, bindings_string, callback) {
        if (!bindings_string)
            return false;
/*code added*/
        let key_list = bindings_string.split("::");
        let new_key_list = [];
        for(pos in key_list)
           new_key_list.push(get_valid_key(key_list[pos]));
/*code added*/
        return this.addHotKeyArray(name, new_key_list, callback);
    },
//... more code
}

[ghost]

There are standards key that all keyboard have, so the last key in the list, could be an standard key. This is not to be used always, it's only for initialize the keybindings...(the default key bindings). When user select a keybindings, it's clear, that the key exist... So, could not be problems like you say of errors selecting things.

[collinss]

I still think it's a bad idea to use alternates like that. If I had a keyboard that didn't have a menu key, I would NOT want ctrl to open the menu as the default action (or any other key for that matter), and I would be extremely annoyed by such a behavior. I can think of no key that I would expect to open the menu by default except the super key. However, I would expect the super key to open the menu by default, regardless of where the super key is. I think it would be better to let the user set such things themselves if they lack the standard key for a particular function.

[thomasthorsen]

@lestcape can you please take your proposal and related discussion to another issue, I have no interest in it and it has only a very vague relation to this issue which is now closed.

[ghost]

@thomasthorsen there are a button that say "Unsubscribe", just for this problem...

[ghost]

@collinss you are who define what key could be used as a replace in the list or not... This is only a general idea, that can be use like you want. What switch? You don't have Super key... The user don't see the changed because only occurs when you don't have the key in your keyboard, like also occurs now. When he open the menu, he see a default key, and this key never changes. The only way to change the key, will be change the keyboard. And with other keyboard it's clear that other things need to happen. Any way, in any case this would be my implementation, not of cinnamon and only if I can do it. If you think of something better and you have time, we can continue speaking it in my github profile, or elsewhere, to not keep bothering.

[thomasthorsen]

@lestcape I don't want to unsubscribe just because you decided to hijack this thread. I am interested in this issue and any comments on it that are actually related to this issue that may come at a later point in time by other people. I am however not interested in your unrelated discussions and don't want to reader any further about it, so please take it somewhere else instead of annoying the hell out of me. You are even welcome to post a link to wherever you take the discussion, just stop it here.

[ghost]

@thomasthorsen, sorry for try to resolve the war of keybindings in your threads, without any good result. Your thread will be popular when the war begin, and i send the user to the source of the problem. Here!

[AlbertJP]

@lestcape you cannot see which keys are missing on somebody's keyboard, the key will not fail but just never be triggered.

[ghost]

Thanks @AlbertJP I've already bothered too much, but I want at least say thank.

I know that, but i expected at less, that exist a way to check the keyboard layout (that could be incorrectly selected or redefined by user). An specific keyboard layout have a unique map of keys, but i do not find a way to do that. I only want to reduce the number of keybinding in conflict and the number of keybinding in use. I refrain for now.

[ghost]

@thomasthorsen maybe this is interesting for you:

https://github.com/linuxmint/Cinnamon/issues/3643 https://github.com/linuxmint/Cinnamon/issues/3609 https://github.com/linuxmint/Cinnamon/issues/3485 https://github.com/linuxmint/Cinnamon/issues/3480 https://github.com/linuxmint/Cinnamon/issues/3643 https://github.com/linuxmint/Cinnamon/issues/3210 https://github.com/linuxmint/Cinnamon/issues/3511 https://github.com/linuxmint/Cinnamon/issues/3512

And please see the Roadmap for cinnamon: https://github.com/linuxmint/Roadmap cinnamon
fix regression on umounting HDD in Nemo fix regression not possible to use Super_R for keyboard shortcuts fix possible regression with mobile broadband? https://github.com/linuxmint/Cinnamon/issues/3640
update cinnamon-translations