Bug 182897

Summary:	Allow different shortcuts for different application switchers
Product:	[Plasma] kwin	Reporter:	Todd <toddrme2178>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	andrew.dorrell
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	openSUSE
OS:	Unspecified
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Todd 2009-02-02 18:09:14 UTC

Version: (using KDE 4.2.0)
Installed from: SuSE RPMs

Currently you can only have one application switcher (box, cover, or flip) assigned at a time because they all use the same shortcut. However, there are situations where you might want to use one switcher and other situations where you might want to use another (for instance if you have a lot of graphics-intensive windows open at once). It would be nice if you could assign separate keyboard shortcuts to each of the application switchers. For instance you could use alt+tab for the box switch and meta+tab for cover or flip switch.

I have several possible solutions for this. None seem optimal to me. One is to just have a separate shortcut for each. I am not sure how this would work with the "effect for window switching" dropdown.

Another option is to have a separate shortcut for each, but if you change the "effect for window switching" dropdown the shortcut that is assigned to the previous application switcher gets switched with the one for the new application switcher, so the shortcut for the "default" application switcher (the one in the dropdown) always stays the same. This would be somewhat confusing for users, though.

Another option is that the "effect for window switching" dropdown only works when you have one window switcher checked in "all effects" tab. If you have only one selected the box works and the shortcut gets moved when you change the dropdown. If you have more then one checked, however, the dropdown box gets grayed out and says "multiple". Then each switcher gets its own shortcut. This may be the optimal solution since it is not confusing or complicated, but it renders the normal "application switcher" shortcut in the keyboard configuration menu pointless. I guess you could gray it out as well.

The final option is that there is both a general "application switcher" shortcut that is automatically applied to whatever is selected in a dropdown and a separate individual shortcut for each application switcher. That would mean that for the switcher selected by the dropdown there may be two shorcuts, a general application switcher shortcut and a second shortcut specific to that particular effect.

Comment 1 lucas 2009-02-03 04:10:21 UTC

Have two dropdowns:

1) Window switcher
2) Alternative window switcher

The alternative is identical to the other in all ways except it's assigned to a different shortcut.

Comment 2 Todd 2009-02-04 18:02:48 UTC

That could work, but there are currently 3 different window switchers (not including the Expose effect, which already supports being assigned to a separate shortcut) and there could be more in the future.  I am not sure limiting people to only two would be the best solution.

Comment 3 andrew 2009-02-06 12:47:30 UTC

Was asked to repost this here.  Sorry for getting the procedure wrong :-/

> Agree with Lucas.  There may be lots of different switchers available
> but few users will want to make use of more than two:
> 1. quick switch which is invaluable when working between 2-3 application
> windows
> 2. "slow" (heavily visual) switch which is useful when you need to find
> that other application
>
> We are all used to using Alt-Tab for 1.  IMHO there needs to be a single
> "system" shortcut for a secondary switcher (meta-tab works for me - have
> been using it for kompose for years now).  User configuration can then
> just decide which secondary switcher to use.  Might help get that ever
> growing list of effects under control  :-) 
>
> Does anyone have a use-case for more than 2 switch modes?
>  I know others have advocated a mac style application (rather than
> window) switch shortcut.  Personally I'm not a fan but it is one other
> case i can think of.

Comment 4 Todd 2009-02-10 17:50:27 UTC

The main use-case I can think of is a basic switcher for quick changes, a more advanced switcher for browsing through bigger views, and an expose-style switcher if you want to see everything in one glance.  However, if we start getting more advanced and more specialized switchers in the future, that could change substantially.

Comment 5 Martin Flöser 2009-09-13 13:36:51 UTC

SVN commit 1022861 by graesslin:

Here comes the new TabBox. It is a complete rewrite using a MVC approach. Here some highlights:
 * Models and Delegates for Clients and Desktops
 * Horizontal, vertical and tabular layout
 * Layout of one item can be configured by an XML definition
 * A desktop item can include a client list
 * An optional second list view showing only the selected item
 * A new KCM "kwintabbox"
 * An alternative TabBox with independent settings and keybindings
 * Optional Highlight Windows effect integration
 * List scrolls instead of removing items
 * Scroll wheel support
 * Cursor key support
 * Middle click on item closes window
BUG: 195745
BUG: 197187
BUG: 201103
FEATURE: 118184
FEATURE: 156723
FEATURE: 177441
FEATURE: 182897
FEATURE: 193882
GUI:

 M  +12 -2     CMakeLists.txt  
 M  +6 -0      client.cpp  
 M  +8 -0      client.h  
 M  +23 -15    effects/boxswitch/boxswitch.cpp  
 M  +3 -0      effects/boxswitch/boxswitch.h  
 M  +8 -2      effects/coverswitch/coverswitch.cpp  
 M  +2 -0      effects/coverswitch/coverswitch.h  
 M  +3 -2      effects/flipswitch/flipswitch.cpp  
 M  +1 -0      effects/flipswitch/flipswitch.h  
 M  +4 -0      effects/highlightwindow/highlightwindow.cpp  
 M  +4 -3      effects/presentwindows/presentwindows.cpp  
 M  +1 -0      effects/presentwindows/presentwindows.h  
 M  +1 -0      kcmkwin/CMakeLists.txt  
 M  +32 -26    kcmkwin/kwincompositing/main.cpp  
 A             kcmkwin/kwintabbox (directory)  
 A             kcmkwin/kwintabbox/CMakeLists.txt  
 A             kcmkwin/kwintabbox/kwintabbox.desktop  
 A             kcmkwin/kwintabbox/layoutconfig.cpp   [License: GPL (v2+)]
 A             kcmkwin/kwintabbox/layoutconfig.h   [License: GPL (v2+)]
 A             kcmkwin/kwintabbox/layoutconfig.ui  
 A             kcmkwin/kwintabbox/main.cpp   [License: GPL (v2+)]
 A             kcmkwin/kwintabbox/main.h   [License: GPL (v2+)]
 A             kcmkwin/kwintabbox/main.ui  
 A             kcmkwin/kwintabbox/previewhandlerimpl.cpp   [License: GPL (v2+)]
 A             kcmkwin/kwintabbox/previewhandlerimpl.h   [License: GPL (v2+)]
 M  +2 -0      kwinbindings.cpp  
 M  +7 -1      lib/kwinglobals.h  
 A             tabbox (directory)  
 M  +391 -898  tabbox.cpp  
 M  +64 -120   tabbox.h  
 A             tabbox/DefaultTabBoxLayouts.xml  
 A             tabbox/clientitemdelegate.cpp   [License: GPL (v2+)]
 A             tabbox/clientitemdelegate.h   [License: GPL (v2+)]
 A             tabbox/clientmodel.cpp   [License: GPL (v2+)]
 A             tabbox/clientmodel.h   [License: GPL (v2+)]
 A             tabbox/desktopitemdelegate.cpp   [License: GPL (v2+)]
 A             tabbox/desktopitemdelegate.h   [License: GPL (v2+)]
 A             tabbox/desktopmodel.cpp   [License: GPL (v2+)]
 A             tabbox/desktopmodel.h   [License: GPL (v2+)]
 A             tabbox/itemlayoutconfig.cpp   [License: GPL (v2+)]
 A             tabbox/itemlayoutconfig.h   [License: GPL (v2+)]
 A             tabbox/tabboxconfig.cpp   [License: GPL (v2+)]
 A             tabbox/tabboxconfig.h   [License: GPL (v2+)]
 A             tabbox/tabboxhandler.cpp   [License: GPL (v2+)]
 A             tabbox/tabboxhandler.h   [License: GPL (v2+)]
 A             tabbox/tabboxview.cpp   [License: GPL (v2+)]
 A             tabbox/tabboxview.h   [License: GPL (v2+)]
 M  +17 -2     useractions.cpp  
 M  +2 -2      workspace.cpp  
 M  +14 -4     workspace.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1022861