Bug 44268 - dynamic keybindings for windows
Summary: dynamic keybindings for windows
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Other
: NOR wishlist
Target Milestone: ---
Assignee: Lubos Lunak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-06-23 12:48 UTC by Oswald Buddenhagen
Modified: 2005-10-20 14:58 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oswald Buddenhagen 2002-06-23 12:34:37 UTC
(*** This bug was imported into bugs.kde.org ***)

Package: kwin
Severity: wishlist

every new window would be assigned the first free hotkey from a list so
it could be directly focused+raised. this would be be almost the same as
the alt-<n> keysbindings from the good ol' borland IDEs and recently
ctrl-<n> from kdevelop just with the difference that it would work on
top-level windows not documents (whichever way represented). an
exclusion/inclusion list of window classes/titles to (not to) assign a
key to would exist. also popups and similar wouldn't get a hotkey of
course.
Comment 1 Lubos Lunak 2004-10-01 12:40:15 UTC
Note also bug #82986.
Comment 2 Lubos Lunak 2005-01-17 16:53:28 UTC
CVS commit by lunakl: 

Window-specific rules for dynamic windows shortcuts, so that it's
possible to always have certain shortcuts assigned to their windows
if such windows are open. Still few TODO items left, but let's consider
it enough for #44268 to be marked as done.
FEATURE: 44268


  M +2 -9      client.h   1.174
  M +2 -4      manage.cpp   2.69
  M +9 -2      rules.cpp   1.34
  M +4 -0      rules.h   1.23
  M +1 -1      sm.cpp   2.10
  M +1 -2      sm.h   2.9
  M +80 -1     useractions.cpp   2.27
  M +1 -1      workspace.cpp   1.498
  M +1 -0      workspace.h   1.190
  M +14 -0     kcmkwin/kwinrules/ruleswidget.cpp   1.22
  M +2 -0      kcmkwin/kwinrules/ruleswidget.h   1.13
  M +150 -87   kcmkwin/kwinrules/ruleswidgetbase.ui   1.21



Comment 3 Oswald Buddenhagen 2005-01-17 18:05:26 UTC
no. this is not a bit what i wanted. you basically replicated the "activate window" action with a "shortcut" trigger from khotkeys. not to mention that the config dialog behaves strangely (because it has no own frame).
Comment 4 Lubos Lunak 2005-01-20 13:52:16 UTC
Ok, thanks for telling me what I should not have done. How about telling me what I should have done? And the shortcut dialog is reasonably fine.
Comment 5 Oswald Buddenhagen 2005-01-20 14:57:32 UTC
there would be a set of shortcuts (let's call it a shortcut pool). every shortcut is assigned to a slot.
every time a (non-excluded) window is opened, it is assigned to the first free slot. the first opened window gets win+1, second win+2, etc.  dynamic, see?
closing windows frees up slots, of course. for total overkill one could add some management dialog to re-assign open windows to different slots.
to make things more interesting, one could create several shortcut pools from which one would be chosen depending on the window class, etc.

> And the shortcut dialog is reasonably fine.
>
for me it behaved like a popup without any kind of frame. that's not reasonable.
Comment 6 Lubos Lunak 2005-01-21 14:58:45 UTC
That is implemented. Visit the window-specific rules control module, play with the matching rules, and specify e.g. '*Win+[1234567890]' as the shortcut. Your help with making the 'Edit' button work is welcome. So is welcome your help with solving few non-trivial problems with making the dialog work more like you want, whatever that is.
Comment 7 Oswald Buddenhagen 2005-01-21 20:00:11 UTC
either i'm too stupid to understand how to use this feature (in which case the configuration is just too complicated), or you still don't understand what i want. so let's try it this way: please explain to me in your own words what you think i want to do and tell me how exactly to configure it.