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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
