I was wondering if there is possibility to create a global keyboard shortcut for window of a specific program to be brought to foreground ? (Like "Bring Main Window to Top" action for Krusader in the Global Keyboard Shortcuts settings).

Or alternatively is there possibility to set window of a specific program to always run with a specific Window shortcut set?

If by "brought to foreground" you mean "activate" (what implies the former in 99% of all cases), you can either assign a temporary window shortcut (for /that/ window - once closed, the shortcut is gone) in it's Alt+F3 (titlebar RMB) menu, or setup a "special window setting" ("arrangement & access" tab)

The latter one can be tricky (because of pot. conflict resolution) but if you just want to assign eg. "Meta+K" to konqueror, that should be no problem.

This is exactly the problem. That Window shortcuts only work until the window is closed. So far I have been using wmctrl for this but was wondering if KDE provides its own way.

You can only automatically assign shortcuts to windows via rules.

There's NO WAY to preserve the shortcut that once was assigned to a special window once that window was destroyed. Technically impossible from the WM side - each client process would have to provice shortcuts to certain windows.

luebking wrote:You can only automatically assign shortcuts to windows via rules.

Can you please elaborate on this? Where this can be set and how to go about it?

*cough*

you can either assign a temporary window shortcut (for /that/ window - once closed, the shortcut is gone) in it's Alt+F3 (titlebar RMB) menu, or setup a "special window setting" ("arrangement & access" tab)

RMB click the titlebar, "More Actions"/"Special Window Settings..."
Open the "Arrangement & Access" tab, check "Shortcut" (last item), choose eg. either "Force" or "Apply initially", click "Edit..." and "Single Shortcut" for a trivial setup.

rsupremo wrote:I was wondering if there is possibility to create a global keyboard shortcut for window of a specific program to be brought to foreground ? (Like "Bring Main Window to Top" action for Krusader in the Global Keyboard Shortcuts settings).

Or alternatively is there possibility to set window of a specific program to always run with a specific Window shortcut set?

I'm looking for answer on this question, too. Specifically I'd like such a shortcut for Konsole; that's why I raised "Provide "Bring Main Window to Top" action in Global Shortcuts in System Settings" – https://bugs.kde.org/show_bug.cgi?id=354088 It's strange Konsole does not offer such a useful feature, yet.

I'm wondering what mechanism do Krusader and Yakuake use to provide such global shortcut and if it couldn't be made generic so that one could set such shortcuts for whatever apps he wants.

Btw, clicking "Special Window Setting..." on Konsole's window does not open any dialog for me... Bugs, bugs, bugs everywhere.

Piotr Dobrogost wrote:I'm looking for answer on this question, too.

Given in the comment right above.

Piotr Dobrogost wrote:It's strange Konsole does not offer such a useful feature, yet.

Maybe because there's a general system to do this. Yakuake is different in that it really closes/opens a window by such shortcut.

Piotr Dobrogost wrote:I'm wondering what mechanism do Krusader and Yakuake use to provide such global shortcut

They register a global shortcut and show/raise themselves when it's triggered. This is in priciple available to every KDE application, but would have to be added *there*
This approach cannot be "injected" by the user.

Piotr Dobrogost wrote:Btw, clicking "Special Window Setting..." on Konsole's window does not open any dialog for me... Bugs, bugs, bugs everywhere.

https://bugs.kde.org/show_bug.cgi?id=353154 - already fixed (was about installation path assumptions)
Run "kcmshell5 kwinrules" instead.

luebking wrote:Given in the comment right above.

Yea, I saw this but thought this does not persist and couldn't actually test it (due to broken "Special Window Setting..."). Btw, you suggested using Single Shortuct but it seems there's no way to "submit" this dialog box after pressing chosen shortcut as there's only Close button and it looses shortcut when pressed (writing shortcut manually – without using Single Shortcut – works).

luebking wrote:Maybe because there's a general system to do this. Yakuake is different in that it really closes/opens a window by such shortcut.

By "general system" you mean setting shortcut in "Special Window Setting..." or something else?
Well, the fact it closes (in fact I think it only hides this window as the context is preserved when subsequently pressing shortcut) window on the same shortcut is kind of unique indeed. However the feature of _starting_ app in case it's not already running seems to be something useful regardless of app and this is something not supported by setting shortcut through "Special Window Setting...". Do you know how to achieve this with Konsole and other apps?

luebking wrote:They register a global shortcut and show/raise themselves when it's triggered. This is in priciple available to every KDE application, but would have to be added *there*
This approach cannot be "injected" by the user.

What do you mean by "This is in principle available to every KDE application"?
By *there* you mean the list of components in "Global Keyboard Shortcuts" or application itself or something else?

luebking wrote:https://bugs.kde.org/show_bug.cgi?id=353154 - already fixed (was about installation path assumptions)
Run "kcmshell5 kwinrules" instead.

Good to know – thank you.

Generally I recall seeing in the past some script using dbus with the aim to activate given session/tab in Konsole and I'm wondering if KDE implements some dbus service for every KDE app which would allow to show (or run if not already running) and hide/close given app?

"More Actions/Window Shortcut" does *not* persist, but a window rule will re-apply whenever a matching window is added.
To configure this from "kcmshell5 kwinrules" you've to make a "New" rule and "Detect" the desired window and "Force" a shortcut

You can bind a shortcut to start an application in "kmenuedit" (the rightclick-edit thing on the kickoff button)

By "there" I mean, the application needs to implement this, should be around 4 LOC, but it can of course not implement a shortcut to be started (since it's not running to interpret the shortcut

There's the KMainWindow interface.
[code]
qdbus org.kde.konsole /konsole/MainWindow_1 hide
qdbus org.kde.konsole /konsole/MainWindow_1 show
qdbus org.kde.konsole /konsole/MainWindow_1 raise
[/code]

Sorry if my questions seem to drill to much but I'm trying to understand the whole picture and this often means understanding many moving parts and how they interact with each other. If there's some article/documentation explaining design of different KDE parts/subsystems (shortcuts and application life cycle management in this case) I would love to know where it is. Thank you for your patience and time you spend answering my questions.

(...) it seems there's no way to "submit" this dialog box after pressing chosen shortcut as there's only Close button and it looses shortcut when pressed

Should I file a bug for this?

luebking wrote:"More Actions/Window Shortcut" does *not* persist, but a window rule will re-apply whenever a matching window is added.
To configure this from "kcmshell5 kwinrules" you've to make a "New" rule and "Detect" the desired window and "Force" a shortcut

Thanks, I get it. I set here the same shortcut I set globally (System Settings > Shortcuts > Custom Shortcuts > Exmaples > Run Konsole) for staring Konsole with the hope it would overwrite/hide the global one after the first window is created. This way I would get the behavior I'm for; starting or bringing window to front; both with one and the same global shortcut. This however does not work; it seems that you can't reassign global shortcut.

luebking wrote:You can bind a shortcut to start an application in "kmenuedit" (the rightclick-edit thing on the kickoff button)

After assigning shortcut for Konsole this way, saving, closing and opening KDE Menu Editor again the shortcut is gone. Am I doing something wrong?

luebking wrote:By "there" I mean, the application needs to implement this, should be around 4 LOC, but it can of course not implement a shortcut to be started (since it's not running to interpret the shortcut

Well, I'm again kind of lost here as now I don't know what do you refer to by "implement this" Do you mean the feature of closing app in response to some shortcut?

luebking wrote:There's the KMainWindow interface.

Code: Select all

qdbus org.kde.konsole /konsole/MainWindow_1 hide
qdbus org.kde.konsole /konsole/MainWindow_1 show
qdbus org.kde.konsole /konsole/MainWindow_1 raise


Thanks, I missed this. Looking in QDBusViewer it looks like this is in fact part of QWidget's interface not KMainWindow's interface (I'm aware the latter inherits from the former). Playing with these methods it looks like `raise` does not bring Konsole's window to the front. I found out that to bring Konsole's window to the front one has to first hide it and then show it. This works but is clearly a workaround and in fact ugly workaround as Konsole disappears for a moment from taskbar. Am I missing something?

Nevertheless this is Konsole specific. The question is if it would be possible and useful to have such generic methods like hide/show exposed under some well known dbus path (like /kde/services/window_management/[show|hide]) in each app's object (org.kde.konsole here) so that every KDE app could be controlled in generic way.

> Should I file a bug for this?
If you feel there's sth. wrong, sure. Please enrich it with one or two screenshots, though
(At least I do currently not understand what you mean)

> hope it would overwrite/hide the global one after the first window is created.
No. That's not how it works. KWin won't steal shortcuts (that would be permanent)
You're asking for https://bugs.kde.org/show_bug.cgi?id=89178

> After assigning shortcut for Konsole this way, saving, closing and opening KDE Menu Editor again the shortcut is gone. Am I doing something wrong?
Is it a localized system? => https://bugs.kde.org/show_bug.cgi?id=66109
May also be https://bugs.kde.org/show_bug.cgi?id=339446 or https://bugs.kde.org/show_bug.cgi?id=343891 (khotkeys somehow lacked maintainance over years and we just started to get it back in shape)

> I'm again kind of lost here as now I don't know what do you refer to by "implement this"
The application needs to register a shortcut and then "do something" (in case of eg. yakuake, check state and show => activate => hide)
Doing that "from outside" will fail on the "show" problem (unless you script a program via dbus)

> I found out that to bring Konsole's window to the front one has to first hide it and then show it.
Not required here, but sounds like you're running into some focus stealing prevention.
Try to delay the call briefly

sleep 0.5; qdbus org.kde.konsole /konsole/MainWindow_1 raise

> under some well known dbus path
Is: "org.kde.foo /foo/MainWindow_x" - the "problem" is that applications can have an infinite amount of "MainWindows" (and this is not available for dialogs) - ie. to select the interesting window.

luebking wrote:If you feel there's sth. wrong, sure. Please enrich it with one or two screenshots, though
(At least I do currently not understand what you mean)

Will do. Again, when you click Single Shortcut button the dialog to enter (by pressing keys on keyboard) shortcut appears. After pressing shortcut (which is then visible in the input field on this dialog) and clicking Close button (the only button present on this dialog) the shortcut is lost as it's not visible in the "Edit Shortcut" window. In this window in the input field there's what was there before pressing Single Shortcut button and choosing new shortcut; either nothing or old shortcut.

luebking wrote:No. That's not how it works. KWin won't steal shortcuts (that would be permanent)
You're asking for https://bugs.kde.org/show_bug.cgi?id=89178

Yes, it looks like the feature I want. Are there any plans to implement this?

luebking wrote:After assigning shortcut for Konsole this way, saving, closing and opening KDE Menu Editor again the shortcut is gone. Am I doing something wrong?
Is it a localized system? => https://bugs.kde.org/show_bug.cgi?id=66109
May also be https://bugs.kde.org/show_bug.cgi?id=339446 or https://bugs.kde.org/show_bug.cgi?id=343891 (khotkeys somehow lacked maintainance over years and we just started to get it back in shape)

It's localized as far as region is set to Polska. However changing region to None (which resulted in region after logout/login being set to UnitedStates (en_US)) did not change anything so I think it's different than bug Bug #66109.
It looks like Bug #339446 but that bug is marked as dupe of Bug #337230 which a) has some non obvious (from user perspective) title and description b) is marked as solved... Maybe Bug #337230 should just block Bug #339446 which should now be reopened as it looks like this still/again does not work?

luebking wrote:Not required here, but sounds like you're running into some focus stealing prevention.
Try to delay the call briefly
sleep 0.5; qdbus org.kde.konsole /konsole/MainWindow_1 raise

Sleep does not help but changing Focus stealing prevention in Window Management > Window Behavior from Low to None makes raise work even without any sleep. I'm going to leave it at None and see if it causes any issues. I found your Focus Stealing Prevention but have to admit I can't follow as I don't quite get the whole problem. Applications by themselves should behave properly; they should not grab focus without user action/intention and I can't see how any prevention could work and why it's even needed (Just don't run misbehaving apps and raise bugs for those apps which do misbehave).

luebking wrote:Is: "org.kde.foo /foo/MainWindow_x" - the "problem" is that applications can have an infinite amount of "MainWindows" (and this is not available for dialogs) - ie. to select the interesting window.

Btw, what's the point of repeating foo in /foo/MainWindow_x as this path (and all others) are already under org.kde.foo object?

> the only button present on this dialog
Ah, ok - somethings completely broken here (also ok+cancel of the parenting dialog are on top)

> Are there any plans to implement this?
khotheys has been virtually unmaintained over the past decade (I just randomly stumbled over that fact myself very recently)

> It looks like Bug #339446 but that bug is marked as dupe of Bug #337230
There was the more severe problem which could cause random asignment failures (bug #343891)
I suggest to re-try with 5.5 (should be released in november or so) or install khotkeys from git to see whether it's still a problem.

> Sleep does not help but changing Focus stealing prevention
Ah, that's because I run https://git.reviewboard.kde.org/r/124130/
Focus stealing is a very prominent issue and actually quite some clients (with firefox and thunderbird on the forefront) think of themselves as super-important.
The problem is less about the stacking order, though (see my patch) but that a client adds a window (eg. a dialog) that immediately gets input focus (or takes it explicitly to an existing window since it feels like thats required now). If you're just typing, you'll hit the enter button in the wrong momemt...

> Btw, what's the point of repeating foo in /foo/MainWindow_x
Disambiguation, I guess (that layout had afair existed even in dcom times) - Random parts/libs can add random objects, so it's probably good practice to not add them all to the root object. (And any change away would cause massive incompatibilities anyway)