Version: (using Devel) Compiler: gcc 4.4 OS: Linux Installed from: Compiled sources When I turn on the "Highlight Window" desktop effect, and hover my mouse over a taskbar entry, it takes perhaps 1 second before the highlighting actually happens. The rest of my desktop effects are extremely responsive, so I assume this is intentional. However, it makes the effect feel less fluid, and for me, sort of defeats the point of using that effect in the first place. If I'm going to hover over a window (without clicking it), it's usually because (a) that window is covered by other windows, and (b) I want to very quickly check what's in that window without having to switch my focus, bring it to the front, etc. Having a small delay makes it more cumbersome to use in this way. Instead, I think the hover effect should happen immediately (or after a configurable delay, which can be set to 0). Thanks.
Delay is controlled by Plasma.
"it takes perhaps 1 second before the highlighting actually happens." it actually takes exactly one second. :) the reason for this is when we did user testing with this new feature and it was turned to instant display, people found it disorienting: just moving your mouse over the taskbar items would result in windows flicking about. so we introduced a small delay, and test again. feedback was good once we tried 1s. what i'm going to do is back this off to .7s so it's the same amount of time as the tooltips, which probably makes sense.
SVN commit 987924 by aseigo: backport 1000->700 delay change to make the hover effect happen in tandem with tooltips BUG:197980 M +1 -1 abstracttaskitem.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=987924
Unfortunately, this seems to have made it worse by exposing a possibly-unrelated bug. When I hover over a taskbar entry, one of three things happens: 1. Nothing. 2. The windows flicker translucent, the tooltip pops up and the windows become almost immediately opaque again. 3. The windows become (and stay) translucent, but there is a longer (!) delay before this occurs. (It's as if the translucent-delay is started only after the tooltip appears.) If I should file a separate bug for this, please let me know. In any case, 0.7sec is still a very noticeable lag, so I can't consider this as "fixed" for me. Indeed, I'm asking for exactly what user testing told you NOT to do. (Pesky user, I know ;P) "Windows flicking about" is a good thing for me, because I KNOW exactly what I want when I start waving my mouse around over the taskbar. ;) Having to wait the extra second breaks my flow. If I need to check something quickly in a covered window, I'll spend more time waiting on the delay KDE is imposing than I will actually scanning the window to retrieve what I need. (The latter takes maybe a half-second, depending.) I suspect that ultimately a configure option will be needed to keep everyone happy. I would suggest setting the default to 0.7s or 1s, and put the configure option in the Window Highlight effect. Then, only people who care about it need even see it's there.
"one of three things happens:" ha! race condition. ok, that's easy enough to fix, if somewhat hackishly. "and put the configure option in the Window Highlight effect" yes, that's a sane idea. however, this would mean probably having a set of controls for this feature specifically for used by taskbar type things. the kwin folk should have more idea on that part of it.
Any settings should be done in Plasma config panels as both window highlight and taskbar thumbnails are "dumb" effects, as in they are activated by other programs remotely. This includes any setting to enable/disable the effect as ultimately it would be nice if the effects were permanently enabled and hidden in the KWin effect list. Many users cannot easily work out that something that happens on the taskbar can be controlled by the "desktop effect" system settings panel.
and how is plasma supposed to know it is best to trigger this behaviour? it can't do nearly as good a job as kwin can. see the issue above with the tooltip and the effect happening at the same time. moreover, these settings only matter when the effects are enabled in kwin. so if the settings are put in plasma, you still have to visit kwin to get it all right. should something change in kwin, we then have to change the settings in plasma ... no, this seems like a poor road. so, the issue is that it is too hard to go from the taskbar to the appropriate window manager settings. let's think about how we can solve that issue .. i don't have any ideas right at this moment, but hopefully if we all let it roll around in our heads for a bit we can come up with something.
"would be nice if the effects were permanently enabled and hidden in the KWin effect list" talking with Lucas on irc, i came to understand that he means _completely_ gone from the kwin UI. in that case, i really think we are going to need a library in kdebase/workspace/ that will enable us to poke, prod and tweak these things. IME having settings in one application that alter another one leads to bad things as you have to change every application in tandem. much better to hide it behind an API and rely on it there. plasma<->kwin is tenuous enough, but if we add a third application in there it will start to get really messy. (i have ambitions to write a krunner plugin that does basic window management control things and these effects would be useful there.) with a library, the users of kwin can then just poke at it via the library and if things change in kwin, we can tweak the library and be done with it. this would include configuration details. Lucas: i'm willing to write the API bits for 4.4, but i'd appreciate some participation and help on it from you with regards to KWin interaction.
Suggestion: Is it possible to use an 'activator' of sorts i.e., a button to hold to make the highlight effect happen when the cursor is on the chosen taskbar entry. E.g, Holding Meta (probably not) over the entry will make the highlight effect occur, while not holding it will display the regular tooltip (depends on if these are enabled, of course). If possible, allow configuration of this, so that the default action could be either.
Some extra thievery from opacify (compiz): If the effect is already active,remove the delay. E.g 5 windows open, window 1 in foreground. Moving cursor to window 2 taskbar entry (and optionally, pressing activator key ;-)) enables effect after time delay. Moving cursor then to window 4 taskbar entry immediately shows window 4, ignoring the delay. Very seamless to the eye.
I did not understand the technical relations where to implement what. But I vote for this wish, because activation time currently is to long (KDE4.3) and it would be nice to have a configuration parameter to try different activation speeds: 1) A parameter to configure the delay for the initial highlighting is important (maybe 0.7 seconds is fine, maybe not). 2) Comment #10 sounds great. (No delay between different highlights) 3) Also a keyboard shortcut to only highlight a window on demand might be nice (comment #9), but I think this is not that important. just my 2 cents, Thank you, Gert
I second the comment 10 and comment 11 ideas. Currently in plasma 5.4.0, highlight window is instant ... after a while makes me dizzy and left wondering whats real and what highlight. ( specially as i have auto hide panel ). Really need an Initial only highlight delay. Thanks !
5.9.x, still no delay, not even a configurable one. Delay does not need to be that long, but the instantaneous effect is jarring.
If you are talking about Plasma 5, please report this issue for 'plasmashell', not 'plasma4'.
Since the original bug report is now resolved (there is no longe a delay), I'm closing this. New bug reports should be filed against a Plasma 5 component.