Bug 175521 - Present Windows : Better highlight selected window
Summary: Present Windows : Better highlight selected window
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: effects-window-management (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: LO wishlist with 2 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 185285 190965 209045 258239 260690 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-18 23:16 UTC by Frando
Modified: 2021-01-08 20:08 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Stippled line effect mockup (856.42 KB, image/png)
2009-07-29 16:22 UTC, Pascal d'Hermilly
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frando 2008-11-18 23:16:34 UTC
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.
Comment 1 lucas 2008-11-18 23:55:17 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.
Comment 2 lucas 2009-02-23 02:16:38 UTC
*** Bug 185285 has been marked as a duplicate of this bug. ***
Comment 3 Martin Flöser 2009-03-14 23:10:06 UTC
As dim inactive does not dim windows when there is a fullscreen effect... can we considere this feature request as resolved?
Comment 4 lucas 2009-03-15 04:41:10 UTC
No, I want my fireflies!
Comment 5 Martin Flöser 2009-06-28 20:17:23 UTC
*** Bug 190965 has been marked as a duplicate of this bug. ***
Comment 6 Pascal d'Hermilly 2009-07-29 16:22:32 UTC
Created attachment 35719 [details]
Stippled line effect mockup

What about having a stippled line that runs around the active window?
Comment 7 Thomas Lübking 2009-07-29 16:58:08 UTC
[ä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 ;-)
Comment 8 Martin Flöser 2009-07-29 17:35:44 UTC
(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.
Comment 9 Thomas Lübking 2009-07-30 00:02:38 UTC
(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)
Comment 10 Martin Flöser 2009-07-30 09:58:18 UTC
(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)
Comment 11 Martin Flöser 2009-10-01 08:18:25 UTC
*** Bug 209045 has been marked as a duplicate of this bug. ***
Comment 12 Pascal d'Hermilly 2010-02-26 15:00:37 UTC
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.
Comment 13 Martin Flöser 2010-12-19 11:01:48 UTC
*** Bug 260690 has been marked as a duplicate of this bug. ***
Comment 14 Lukas Frelich 2010-12-19 11:20:18 UTC
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.
Comment 15 Martin Flöser 2011-03-19 10:39:26 UTC
*** Bug 258239 has been marked as a duplicate of this bug. ***
Comment 16 Thomas Lübking 2011-08-09 21:48:58 UTC
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
Comment 17 Marco Martin 2011-09-23 15:53:24 UTC
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
Comment 18 Martin Flöser 2012-03-11 15:09:08 UTC
With the changes to zoom the selected window I think present windows has now enough functionality to highlight the selected window.