Reworking the kwin tabbox

[Thomas Lübking]

Am Thursday 16 July 2009 schrieb Martin Gräßlin:
> My idea is that with alt+tab it should work as ever known. But that it is
> not required to keep alt pressed (keeping it pressed shouldn't harm).
that's not gonna work.
right now the selected window gets activated (i.e. the switch is performed) as 
soon as you release the modifier (i.e. ALT)
If pressing ALT is no more mandantory you'll have to either
- press some extra key to effectively switch windows (e.g. ENTER to switch, 
ESCAPE to cancel) what makes alt+tab switching pretty annoying (press ALT+TAB 
to enter the switching, TAB around and press ENTER to apply your change)
- press ALT again to explicitly perform the switching (instead ENTER) - i 
foresee trouble by this (as keeping ALT pressed should work as well)
- introduce a timer .. UAHHHH ;-) -> it will be either to slow or to fast 
(relative to the situation, not the user - so a config won't help)

> I would prefer giving focus directly to the line edit (window switching is
> a keyboard task, so everything should be possible without mouse usage).
This does not work w/o supporting released ALT modifiers (well, it does - but 
do you want to keep pressing ALT with your left and enter the search term with 
your right digit... ;-)
-> see above

> That would of course require some magic that tab switches the tasks and the
> line edit keeps the focus :-)
No magic, just add an eventfilter to the lineedit, eat TAB keys and trigger 
the change instead

> I just would like to get rid of the keyboard grab. I think Chani will
> understand that :-D
i'm not right in this issue, but what's the problem?
just release the Keyboard when the tabbox closes and if there's a heuristic, 
add a (some) timer based recall(s) (like 50,150,300,1000,5000 ms)


now my 2¢ on the whole suggestion:
------------
imho there two different approaches to switch windows.
- one is "on the fly" - which is good if you've got 2 up to 4 open windows, 
therefore the current concept is pretty much ok.

- the other one is to find out of your window mess - basically the exposé 
approach
the problem we face is top provide sth. like this (where window switching is a 
single task job) for an uncomposited environment

-> (regarding the fulltime job switch)
- whatever we do: not using the entire available screen is waste. (otherwise 
it would just be another taskbar :-(

- the task is not bound to mouse or keyboard usage (i.e. you want to use both 
input devs)

- as it's a fulltime job, there can (and should) be an explicit leave 
statement (clicking a window, pressing enter, etc.)

- therefore there's no problem with a searchline either =D

the key backdraw is that we cannot rely on compositing i.e. a miniversion of 
the window.
all we have are title and icon and the icon is probably ambigious (right now 
i've got 5 kmail windows opened...) and the text (maybe ambigious as well) is 
a rather "slow" visualization :-(

to improve this we could include the window geometries (or rather aspects) to 
draw some boxes and strip stuff like the app name from the displayed window 
titles (as they're implicated by the icons anyway) <advert>the bespin deco has 
such feature implemented ;-)</advert>

Sidenote:
---
imho a WM may take advantages from other running process but not rely with 
some core functionality on them (even if we assumed the "plasma/KDE only!" 
variant (what's pretty un-unix).
what if krunner crashes, and a user who never uses it otherwise "magically" 
looses some functionality of his/her WM? s/he might search a whole day for the 
option to reactivate it :-(

(i've general objections against plasma and krunner dragging too much "non 
core" tasks into their processes, but that's OT)

Regards,
Thomas