I've tried setting up keyboard shortcuts to launch favorite apps (i.e. Ctrl+Alt+D for dolphin), but to tell you the truth, the way it works in KDE isn't too useful.

In Windows, when you set up a keyboard shortcut, not only does that key combination launch the app, but it remains associated to the window that it launched. So, when I've used Ctrl+Alt+D to open a DOS prompt window, I can also navigate to that open window by hitting Ctrl+Alt+D again. And you know what, that secondary activation feature is much more useful than the original launch action.

So why doesn't KDE work that way? Is the reason technical?

I've been thinking more about this - what it would take to do it, and I'm wondering if I've stumbled onto a real weakness in they way desktop GUI software rides on top of Linux. Well, a minor weakness, I guess. But one that would be a real pain if I were using Linux the way I use Windows at work (3 or more different development windows open at once and constantly switching between them). At home, I run Linux exclusively, but I mainly use it for web browsing, and Alt-Tab gets the job done.

Anyway, getting to the technical problem...

Re-activating a launched app on the second occurrance of the shortcut keystroke requires that the launcher (or whatever process is trapping keystrokes and interpreting shortcuts) know what window to activate. But in Linux, the windowing system is not the same thing as the process launcher. The launcher knows the process id of the process it launched, but does it have a reliable way to associate that with the desktop window that's ultimately created by the app? Maybe, if the app keeps the same process id throughout. But there are lots of ways apps get launched in Linux. I vaguely remember a time when /usr/bin just contained short scripts for launching GUI apps. In that scenario, the ultimate app would have a different PID than the one the shortcut key launched. I just checked, and my PCLOS system no longer seems to use that trick. But that's not up to KDE to determine, so how can KDE track a launched process through to window creation?

Then again, how does KDE's taskbar 'launch feedback' know when to replace the temporary launch indicator with the real task. Does it just guess? Remove the temporary entry when the next real entry is created? That'd be pretty kludgy. If it actually knows that the window that ultimately opens is the one it launched, then there should be know reason why the shortcut key handler can't know too.

So what's the answer? Is this kind of shortcut key behavior even possible in KDE? If not, is it the kind of thing people would like to be possible, and how much would have to change to make it so? Could it be done in a way that works with all the various X toolkits?

You can (at least temporarily) associate a shortcut to a window through Right Click on Window Decoration > Advanced > Window Shortcut. You may be able to assign shortcuts via Special Window Settings / Special Application Settings, not sure though, but any settings made in those dialogs will be persistent.

<i>You can (at least temporarily) associate a shortcut to a window through Right Click on Window Decoration > Advanced > Window Shortcut. You may be able to assign shortcuts via Special Window Settings / Special Application Settings, not sure though, but any settings made in those dialogs will be persistent.</i>

Interesting. But it begs the question of why the window association has to be separate from the app launcher. If you have to do it in 2 places, then you can't use the same key combination for both. And since the KDE folks have bothered to provide both capabilities, it implies that a single 'launch or activate as appropriate' function is simply not possible. Is that because of X? Because of toolkit differences? Or because KDE is trying to be cross-platform?

The Window Assocation is seperate from the Application Launcher because it is not known by the application launcher if a window is shown, as the responsibility of managing windows belongs with the Window Manager, not the application launcher.

It is therefore not possible for the Window Manager to know which process is providing which windows due to the design of X ( which doesn't require that all windows belong to processes on this machine )

It is therefore not possible for the Window Manager to know which process is providing which windows due to the design of X ( which doesn't require that all windows belong to processes on this machine )

Right. That's what I was afraid of. Not just that X doesn't require all windows to belong to processes on this machine, but also that the window manager might not even know which processes own which windows even if they are running on the local machine. It's an unfortunate consequence of the X architecture (I wonder if Weyland would help here).

Anyway, it wouldn't be so bad if some windows (i.e. remote machine) couldn't be tied to hotkeys, as long as it worked in the common, everything local case. As far as client-server X goes, it seems mostly useful in LTS mode - i.e., where the entire desktop runs remotely to a dedicated X terminal. In that mode, the window manager and window apps are on the same machine.

The point I'm trying to make is that Linux users (and especially the KDE variety) are always talking about how wonderfully customizable Linux is. But other than simple theme tweaks, the single most useful customization I've encountered is the ability to tie keyboard shortcuts to apps for launching as well as window switching. And sadly, that ability seems to be a Windows-only thing (I don't know - can the Mac do this?). Certainly nothing to give up on Linux over, but maybe something to acknowledge as a problem worth solving.

It likely is solvable (with the appropriate scripting), however KWin's D-Bus interface is not sufficient for this.

This is now possible for running applications, see: https://userbase.kde.org/KWin_Rules_Window_Attributes.

Right click the window border > More actions > Special Window/Application Settings > Arrangement & Access tab. Choose Shortcut, select Force and set the shortcut key.

There is a short discussion at http://askubuntu.com/questions/354779/m ... -permanent.