Cinnamon should support hotkeys / window shortcuts for selecting existing windows

[bobfreeman5]

KDE allows hotkeys to be set for existing windows, so they can be accessed easily. Cinnamon doesn't seem to support this, greatly reducing its usability.

[dalcde]

Bother to explain?

[bobfreeman5]

KDE has a feature called "Window shortcuts". It allows you to associate a particular key combination with a particular window (not all windows of a particular application, just one particular window). Then, whatever application is in the foreground, if you press that key combination it immediately brings the associated window to the front, and gives it the keyboard focus.

This is set by clicking the icon in the top left corner of the window, then selecting Advanced->Window shortcut.

Cinnamon does not seem to have such a feature, so to get the window you want you have to do things like look at a list of windows, wait until you have decoded it and found the one you want, then either press alt-tab exactly the right number of times, or move the mouse to the right position and then click. If you miss you then have to do part of that again. If you are using some kind of pager you may need to switch to the right desktop first. Since selecting particular windows is a common task, you have to do all this often. This may also cause you to slightly lose your train of thought, and have to reconstruct the mental plan of what you are intending to do in the next few seconds, after switching windows. It's much easier to just press the key-combination without thinking.

The apparent absence of this feature in Cinnamon is mysterious, and the apparent absence of any documentation about "Window shortcuts" (with this meaning) in Cinnamon is even more mysterious.

[dalcde]

The apparent absence of this feature in Cinnamon is mysterious

It's not mysterious. It's because we didn't implement it.

and the apparent absence of any documentation about "Window shortcuts" (with this meaning) in Cinnamon is even more mysterious.

It's also not mysterious. If it doesn't exist, there wouldn't be any
documentation.

Marking as feature request, but I doubt it would actually be
implemented.

[bobfreeman5]

What I meant was it is mysterious why it wasn't implemented.

Even if there is no such feature, people shouldn't have to search for ages before guessing that there isn't. It would be better if they could quickly find something saying so, and preferably saying why. Many things that don't exist are still talked about on the internet - for example some people say they want it, or discuss whether it's a good idea, or say they are having trouble finding it, where is it. It is such a basic feature, it's really frustrating not having it, and many people from KDE will be familiar with it, I would have expected there to be something written about it. When I searched I didn't find anything and had to guess that it's not implemented. It's a mystery to me why people haven't written more often about it.

You say it's unlikely to be implemented. Why?

[dalcde]

On Wed, May 06, 2015 at 07:20:21AM -0700, bobfreeman5 wrote:

What I meant was it is mysterious why it wasn't implemented.

Even if there is no such feature, people shouldn't have to search for ages before guessing that there isn't. It would be better if they could quickly find something saying so, and preferably saying why. Many things that don't exist are still talked about on the internet - for example some people say they want it, or discuss whether it's a good idea, or say they are having trouble finding it, where is it. It is such a basic feature, it's really frustrating not having it, and many people from KDE will be familiar with it, I would have expected there to be something written about it. When I searched I didn't find anything and had to guess that it's not implemented. It's a mystery to me why people haven't written more often about it.

You say it's unlikely to be implemented. Why?

We don't document every single thing we don't implement (lemme
document one now - we don't solve world hunger). At best, we document
features we have. The fact that no one wrote about it is good evidence
that it is not as popular as you thought (as opposed to, say, vertical
panels). In fact I have never heard of it, and I doubt many people here
have.

I also believe that not many people would actually be interested in this
feature, and no one is likely to go and implement it. Of course, if
anyone wants to do so, feel free. But I'm not.

[dandv]

Asked on AskUbuntu which Desktop Environments can switch among windows.

[dandv]

I've just added a $100 bounty for this:

To win the bounty, Cinnamon must

• support switching with Super+0..9 among existing windows, without attempting to create a new instance of the task
• handle reordering of the windows in the task bar
• not garble the taskbar (don't do this)

[dandv]

Also, the solution must not mangle notification windows or introduce new bugs vs. what the Window-List-Hotkey applet already has.

[mtwebster]

Your mangle notification windows I think you're misunderstanding what that is maybe? I'm not 100% sure since you were a little overzealous with your image cropping, but when a program wants attention or sets its 'urgent' hint, the stock cinnamon window list applet flashes or blinks the item in the window list. If that program is in another workspace, a new item in the window list temporarily is added to the current workspace, where clicking it will send you to that application. This is intended behavior - if that other applet is based on any relatively recent version of the stock applet, then it may have the same behavior.

If this is not the behavior you're referring to, then nevermind.

[dandv]

you were a little overzealous with your image cropping

Unfortunately the notification contained sensitive data, so I didn't include it in the screenshot.

In any case, no taskbar button should be created with the title "winXXX". If a taskbar button does need to be created at all, its title should be the name of the originating application, or the notification title if available.

[mtwebster]

In the stock window list applet, this doesn't happen. That applet is by a third-party developer, I'm not sure how that name is being generated. In the stock applet, if an off-workspace program demands attention, the window list entry 'notification' looks just like its normal window list entry, when you're on that program's workspace.

That said, to the original issue of assigning hotkeys, it's reasonably easy to add at this point (I've actually meant to for quite some time, but it's easy to get sidetracked,) and I'll probably implement some form of it here soon in our stock window list.

A few caveats I'll probably impose:

• The window list can be used on multiple monitors currently. For simplicity's sake I'll probably limit this functionality to whichever window list is on the primary monitor.
• Don't expect any sort of fancy 'hold down super and see the window list entries show their current numbers temporarily until you release it or select one' - if anything, the current shortcut might show up in the item's tooltip/window hover preview.
• Currently, a window demanding attention from another workspace appears as a transient on either end of the window list, depending on the direction their workspace is from the current one. Illustrated:

Let's say I'm on workspace 2, these programs open and on the workspace, they're Super-0, 1, 2 I guess:

I get an alert from hexchat on workspace 1:

... should that alert (we call it 'transient') become -0 temporarily?

The other case, I'm on workspace 1, and I get an alert from workspace 2:

... the transient is temporarily assigned -3

I don't have experience using any type of feature like this (I'm a bit of a neanderthal when it comes to managing my desktop) - it would seem confusing to me to have these reassignments happening, especially in the first case, but possibly not to you (or folks that have used this before) - I'll likely make it an applet option for transient items to be assigned a shortcut or not.

Btw, this didn't require a bounty really... sometimes it's just the squeaky wheel gets the grease. There are only a handful of us, and lots of requests.

[dandv]

@mtwebster, thanks for looking into this. Reassignments should only happen when windows originally assigned shortcuts to are closed. New windows entering the taskbar shouldn't change existing assignments.

Unity lets you pin shortcuts to the taskbar as launchers ("Lock to launcher"), which makes for an easy to read the order of tasks to launch when Super+1..9,0 is pressed. Otherwise, if you have [1, 2, 3] assigned and window 1 closes and it's not locked, windows 2 and 3 would shift to Super + 1 and Super +2 - which may or may not be what the user wanted.

In any case, Unity has set the UX practice in this area, and its behavior should be followed in order to not break user's expectations.

[dandv]

Turns out the "winXX" notification issue happens on Unity as well, and is probably the fault of that proprietary (Java) application.

[mainmachine]

I respectfully disagree with this statement:

In any case, Unity has set the UX practice in this area, and its behavior should be followed in order to not break user's expectations.

From it's derivation from Gnome, Cinnamon is more likely to follow those paradigms, rather than Unity or KDE's. While the default on Ubuntu, it's not the default for Linux... there are many other expectations depending on where a user is coming from...

I like Cinnamon for it's simple, clean aesthetics, subtle graphical niceties, stability, customizability and small footprint. It has sane and incredibly usable defaults, tiling and snapping work really well. Basically it looks good, stays out of my way and gets the job done.

That said, if it's a feature that enough of the userbase wants, or if there's enough attention and development bandwidth, or if it's an easy add/fix, then someone will likely make it happen.

[dandv]

@mainmachine: I also prefer Cinnamon's simple aesthetics (and not being a dick about where the taskbar should be), but I was talking about switching to windows based on Super+1..9. As far as I (and a bunch of other people) know, Unity is the only Linux DE that implements this functionality, so it has set the bar and created muscle memory. (Whether Windows was first in supporting window switching via Super+numbers and Unity copied that, I don't know.)

[gzm0]

As a workaround, you can use jumpapp in the meantime.

[icoloma]

It seems that Icing Task Manager also includes keyboard switch shortcuts (plus application pinning).

[JosephMcc]

Many thanks for contributing to Cinnamon. Your suggestion was reviewed. Your job is done and we'll take it from here :)

For more information on our workflow and feature requests, read https://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/faq.html

[dandv]

It seems that Icing Task Manager also includes keyboard switch shortcuts (plus application pinning).

Icing's page says that it's "deprecated for Cinnamon 4.0+".

[d9k]

Now, how to disable this feature for grouped windows list widget via settings?

[trizt]

On Tue, May 05, 2015, dalcde wrote:
I also believe that not many people would actually be interested in this
feature, and no one is likely to go and implement it. Of course, if
anyone wants to do so, feel free. But I'm not.

I would agree that most people wouldn't need this, but there is a user case (at least for me) where it's quite important to be able to disable hotkeys for an application window, when you run Virtualbox you have an alternative OS and it's applications which have their setup of hotkeys which you may or may not be able to change, so disable the host's hotkeys while the window is open allows you simply use hotkey combinations which otherwise would have interrupted by the host OS. Sure you can change the hotkeys in cinnamon, but then you need to figure out all the hotkeys in the guest OS and it's applications so you don't prevent another hotkey.

Sure there is a workaround in using fullscreen mode (think there still are some hotkey that will take over from cinnamon), but this don't give the flexibility to switch between application from the different OS:es as running things in either windowed mode or seamless mode.

Alternative would be to allow the user to change the WM, that way for those who needs this feature, they could run with kwin.

[bobfreeman5]

I didn't write that, dalcde did.

dalcde also said "The fact that no one wrote about it is good evidence that it is not as popular as you thought" but the whole thread has no explanation of why people wouldn't want it.

[mtwebster]

Doesn't the grouped window list applet do super-# switching of open windows?

[trizt]

@bobfreeman5 sorry to make it look as it was you who had written the quoted text, things just didn't go as expected when I replied with quotes. I did update so that it says dalcde.

@mtwebster as far as I can see, the windows list applet has support for selecting hot keys for "tabbing" trough the current windows , this not the same as setting up a specific hotkeys to access a specific window, say you want ctrl-alt-f to switch to your firefox window while ctrl-alt-c would give you chromium window, also you may want to be able to just get the firefox incognito window then you maybe press ctrl-alt-shift-f.