Version: (using Devel) OS: Linux Installed from: Compiled sources In the Present Windows effect (both when invoked with the short cut and when using it with ALT-Tab), it would be great if the current selected window would be highlighted more prominently. Especially when using Present Windows with Alt-Tab I often find myself staring at the screen and not immediately "getting" the selected window. I am using "dim inactive windows", so currently in Present Windows the difference between the active window and the selected window (when cycling with alt-tab) is rather small. I would therefore propose as a usability enhancement to highlight the selected window more prominently, e.g. by darkening the other not selected windows, or by adding a border/background to the grid field of the selected window. Otherwise, I really love the Present Windows plugin and the changes that come with it for 4.2.
I think an accelerated light source glow with some fireflies radiating out from being the window would look nice. Or maybe even a corona if we could do it. =) Should also apply it to other effects as well for consistency.
*** Bug 185285 has been marked as a duplicate of this bug. ***
As dim inactive does not dim windows when there is a fullscreen effect... can we considere this feature request as resolved?
No, I want my fireflies!
*** Bug 190965 has been marked as a duplicate of this bug. ***
Created attachment 35719 [details] Stippled line effect mockup What about having a stippled line that runs around the active window?
[ähem... a personal comment - sorry no offense intended, but i cannot resist] NO F**** ANTLINES!!! why not just pulse the window (light->dark->light->dark) that's not very distressing, notable (due to the continuous animation) and doesn't look like F*** ANTLINES!!! ( really could not hold me back - sorry everyone ;-)
(In reply to comment #7) > why not just pulse the window (light->dark->light->dark) that's not very > distressing, notable (due to the continuous animation) pulse is bad as that requires repaints. What I have thought about is changing the way. normaly you highlight the selection and keep the other items untouched. PW does the opposite. So we could colorize the selected window and keep the other windows either unchanged or dimmed like in current version.
(In reply to comment #8) > pulse is bad as that requires repaints. "pulse" /not/ "flicker" ;-) light (~200ms, 3-5 repaints) - wait (~1300ms) - dim (~200ms, 3-5 repaints) - wait (~300ms) makes 6-10 repaints (one window and during the short time you change the window and do few else) in 2 seconds also as the key problem seems to be on init, maybe one or two (slightly faster) pulses are enough anyway, i assume you rather fear about the realtime /scaled/ paint of the window? for simple dimming it should be enough to overlay the window with a (shaped) black rect and dim that - what should not be too expensive *shrug* as for coloring: i fear that a colored outline is no option as it would likely interfere with the wallpaper (blue on blue...) so remains (as for playing on colors) tinting - not my favorite aesthetical choice though =P (and a rather bad solution for ppl w/ visual disfunctions... just assume if the tint has the same gray level as the dimming)
(In reply to comment #9) > (In reply to comment #8) > > pulse is bad as that requires repaints. > > "pulse" /not/ "flicker" ;-) > > light (~200ms, 3-5 repaints) - wait (~1300ms) - dim (~200ms, 3-5 repaints) - > wait (~300ms) > > makes 6-10 repaints (one window and during the short time you change the window > and do few else) in 2 seconds > also as the key problem seems to be on init, maybe one or two (slightly faster) > pulses are enough > > anyway, i assume you rather fear about the realtime /scaled/ paint of the > window? for simple dimming it should be enough to overlay the window with a > (shaped) black rect and dim that - what should not be too expensive *shrug* > > as for coloring: > i fear that a colored outline is no option as it would likely interfere with > the wallpaper (blue on blue...) I thought of a complete colouring instead of only an outline. Like the MacOS one: http://images.apple.com/euro/macosx/what-is-macosx/images/expose_desktop20090608.jpg > so remains (as for playing on colors) tinting - not my favorite aesthetical > choice though =P > (and a rather bad solution for ppl w/ visual disfunctions... just assume if the > tint has the same gray level as the dimming) yes good point. Although I'm pretty sure that this can be solved easily (for example configurable color, configurable dimming)
*** Bug 209045 has been marked as a duplicate of this bug. ***
KDE SC 4.5 ? It would make the present windows effect more inviting if the other windows were not a darkish grey. What about a pulsing that slowly fades in strength. Then it would not be resource problem to use the present windows effekt for continual overview.
*** Bug 260690 has been marked as a duplicate of this bug. ***
Sorry for duplicated bug, I didn't find in the first step of reporting a new bug (I guess it because this one is very old). I have read all comments carefully and I still don't think that the current state of highlighting is sufficient. Since the wallpaper is also dimmed, the argument that the border could interfere with, doesn't seem to be much of a problem, at least not in most of the cases.
*** Bug 258239 has been marked as a duplicate of this bug. ***
Git commit 4e0f11c62bdbad58de2cf038640bdff2ea396af2 by Thomas Lübking. Committed on 25/04/2011 at 17:04. Pushed by luebking into branch 'master'. fix close button side for present windows effect BUG: 262543 pint desktop as background when including desktop in switcher BUG: 262137 zoom windows as hover/selection indicaton (1/8 of the screen or 105%) BUG: 215348 CCBUG: 175521 no closer on "show desktop" desktop show closer immediately but have it disabled for a short time to allow the user realize it REVIEW: 101318 M +99 -27 kwin/effects/presentwindows/presentwindows.cpp M +9 -0 kwin/workspace.h M +15 -0 kwin/libkdecorations/kdecorationfactory.h M +11 -0 kwin/effects.cpp M +4 -0 kwin/libkwineffects/kwinglobals.h M +2 -1 kwin/libkwineffects/kwineffects.h M +6 -3 kwin/effects/presentwindows/presentwindows.h M +2 -0 kwin/effects.h M +22 -1 kwin/libkdecorations/kdecorationfactory.cpp http://commits.kde.org/kde-workspace/4e0f11c62bdbad58de2cf038640bdff2ea396af2
Git commit dbe57396853f9995a9b3d7ab5d55f88fc730512a by Marco Martin. Committed on 23/09/2011 at 17:55. Pushed by mart into branch 'active-development/screenlocker'. fix close button side for present windows effect BUG: 262543 pint desktop as background when including desktop in switcher BUG: 262137 zoom windows as hover/selection indicaton (1/8 of the screen or 105%) BUG: 215348 CCBUG: 175521 no closer on "show desktop" desktop show closer immediately but have it disabled for a short time to allow the user realize it REVIEW: 101318 Conflicts: kwin/effects.h M +11 -0 kwin/effects.cpp M +99 -27 kwin/effects/presentwindows/presentwindows.cpp M +6 -3 kwin/effects/presentwindows/presentwindows.h M +22 -1 kwin/libkdecorations/kdecorationfactory.cpp M +15 -0 kwin/libkdecorations/kdecorationfactory.h M +2 -1 kwin/libkwineffects/kwineffects.h M +4 -0 kwin/libkwineffects/kwinglobals.h M +9 -0 kwin/workspace.h http://commits.kde.org/kde-workspace/dbe57396853f9995a9b3d7ab5d55f88fc730512a
With the changes to zoom the selected window I think present windows has now enough functionality to highlight the selected window.