| Summary: | Present Windows : Better highlight selected window | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Frando <frando2> |
| Component: | effects-window-management | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | wishlist | CC: | frelichl, pascal, smithjd15, web, yg |
| Priority: | LO | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=303438 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Stippled line effect mockup | ||
|
Description
Frando
2008-11-18 23:16:34 UTC
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. |
