Bug 385522 - Present Windows: Don't darken all windows and denote selection some other way than restoring original lightness
Summary: Present Windows: Don't darken all windows and denote selection some other way...
Status: RESOLVED DUPLICATE of bug 303438
Alias: None
Product: kwin
Classification: Plasma
Component: effects-present-windows (show other bugs)
Version: unspecified
Platform: Neon Linux
: NOR wishlist
Target Milestone: 5
Assignee: KWin default assignee
URL:
Keywords: accessibility, usability
Depends on:
Blocks:
 
Reported: 2017-10-09 16:11 UTC by Salva Corts
Modified: 2020-05-04 15:20 UTC (History)
24 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Present Windows on Windows 10 (65.84 KB, image/jpeg)
2017-10-09 19:29 UTC, Salva Corts
Details
Present Windows on KDE (1.63 MB, image/jpeg)
2017-10-09 19:30 UTC, Salva Corts
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Salva Corts 2017-10-09 16:11:49 UTC
Hi there!

I think I can make a pull request in order to make users able to choose unhovered windows brightness on Present Windows effect. I don'tt want to sound unpolite, but I'm very busy with university and I would like to know if I code it, will I see it on further releases?

Thanks you,
SalvaCorts97@gmail.com

P.D. Brightness is hardcoded on:
https://github.com/KDE/kwin/blob/master/effects/presentwindows/presentwindows.cpp#L312-L318
Comment 1 Nate Graham 2017-10-09 17:45:43 UTC
Why shouldn't the brightness be hardcoded? Are you seeing some visual glitches with any windows or something?
Comment 2 Salva Corts 2017-10-09 19:29:48 UTC
Created attachment 108259 [details]
Present Windows on Windows 10
Comment 3 Salva Corts 2017-10-09 19:30:50 UTC
Created attachment 108260 [details]
Present Windows on KDE
Comment 4 Salva Corts 2017-10-09 19:35:45 UTC
No, I don see any kind of glitch. It's just for aesthetics.

I can think about three main reasons:
 1) Dark windows make difficult to see whats inside that window.
 2) Not everybody likes how does it fit with their desktop design
 3) Thinkig about how tweakable is KDE; it shoud have this feature implemented.

I have attached two images to compare how does it look on Windows 10 and how does it on KDE. I would be fantastic to be able to choose between them.

Thanks you!
Comment 5 Nate Graham 2017-10-09 19:41:04 UTC
The idea is that when you mouse over a window, it becomes bright, to show that it's selected.

But I see what you mean, it's a bit dim. And not only Windows 10 that keeps them bright all the time; macOSalso keeps then un-darkened during a Present Windows operation. In macOS, selection is denoted by a blue border and the a floating box showing the window title.

While a user-facing option would resolve this issue, it may be worth revisiting the default state as well, so that people don't feel like they have to tweak anything.
Comment 6 Salva Corts 2017-10-09 20:01:17 UTC
Exactly, you are actually having the same feedback when you select a windows with dark windows as with fully bright windows. I would like to help you implementing that feature. Do I have green light?
Comment 7 Nate Graham 2017-10-09 20:03:36 UTC
You don't need my permission; patches are always welcome!

My preference would be to not lighten or darken windows at all, and use something else to show selection, like how macOS does it. Then we don't even need to add a new user-facing setting.

But it's your patch, so you get to choose. :) Once you have something working, please submit it on https://phabricator.kde.org/
Comment 8 Salva Corts 2017-10-20 21:57:32 UTC
Hi there again,

I would like you to know I have made a diff request on KDE phabricator.

https://phabricator.kde.org/D8388
Comment 9 Michael Reiher 2018-08-10 12:03:03 UTC
I just want second on this issue. Please don't dim in the Present Windows effect. 

It's really bad usability as it makes it hard to recognize a Window. I usually have to highlight one window after another to find the one I'm looking for. By scaling down you loose information anyway, and with dimming you loose even more. To an extend that it's impossible to distinguish them. This is even worse with already dark windows, like using dark color schemes or terminal windows.

I'd also be against making this an option (at least not in the UI). Just pick a sane default behavior. KDE already has way to many options.
Comment 10 Patrick Silva 2018-09-16 23:08:07 UTC
*** Bug 329223 has been marked as a duplicate of this bug. ***
Comment 11 Vlad Zahorodnii 2018-09-20 17:57:52 UTC
*** Bug 398881 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2018-11-13 14:29:10 UTC
*** Bug 394810 has been marked as a duplicate of this bug. ***
Comment 13 Vlad Zahorodnii 2018-11-19 09:42:31 UTC
*** Bug 401196 has been marked as a duplicate of this bug. ***
Comment 14 pemartins 2018-12-06 01:49:09 UTC
I asked for help in this issue at the Kubuntu forums https://www.kubuntuforums.net/showthread.php/74800-Present-Windows-desktop-effect-is-there-a-way-to-reduce-the-dimness and was pointed here.

It is really unfortunate that the windows are dimmed, when there are many windows I just cannot see/find what I'm looking for. I believe it should be implemented as in Compiz's Scale plugin where no dimness occurs.

In this youtube video https://www.youtube.com/watch?v=QEHC43zMIMc#t=6m00 the issue is fixed, is there a way to implement it?
Comment 15 Michael D 2019-03-18 12:17:47 UTC
There are three options:
1. Add a user-configurable option to the settings
2. Remove the hardcoded brightness values so every window has value 100
3. Change the value to something less extreme, such as 80 (which I believe is twice the value of the current default)

Option 3 might be a nice middle-ground, since the brightness hover effect remains and non-hovered windows remain bright enough to easily distinguish. The problem is whether the effect becomes too subtle to be helpful. In that case I think 2 makes the most sense since there is already another hover effect.
Comment 16 leftcrane 2019-03-18 13:38:32 UTC
Option 2, no question. Any amount of dimming is going to negatively impact the visual perception, which is vital when you're looking at small thumbnails. Not only that, but dimming provides vastly inferior feedback to a highlight box drawn around the window. The highlight box is the proper way to give feedback regarding a hovered item. There is a reason why this is the universal standard across platforms.
Comment 17 Michael Reiher 2019-03-18 20:26:12 UTC
Fully agree! It's already hard enough to spot the desired window if you have a certain amount of them. And ideally you want to spot it before hovering every window. Any kind of information reduction is counter productive here. Not sure of what help a brightness effect should be. On OSX just a blue frame is drawn around the hovered window, and I never had any issue recognizing that. Compared to spotting the window in the first place without hovering, even without any dimming... So yea, Option 2, clearly.
Comment 18 leftcrane 2019-03-18 22:37:56 UTC
Yes, Gnome is the same. I'd add that identifying windows is hard enough even at full brightness. 

The best solution I've found is to use big, centered icon overlays, like here: https://extensions.gnome.org/extension/60/overlay-icons/

(the screenshot isn't showing ideal behavior, but you can tweak it so it just shows a very faint icon with no gray padding around it - that way it clearly marks the app without obscuring window content too much).
Comment 19 hvm 2019-03-20 09:49:29 UTC
If it matters, I vote for option 2 as well. Having all the windows show normally with an outline for the selected one will help a lot. Right now, it's difficult to see which window I'm looking for.
Comment 20 hvm 2019-03-20 09:52:50 UTC
Sorry for the double comment but I thought of another idea. The windows' titles would be better put below or above the windows. 

Writing on top of the window obstructs the window and again makes it more difficult to find.
Comment 21 leftcrane 2019-03-20 11:58:41 UTC
re HVM, you can make a big translucent icon overlay right on top of the windows. It won't actually obscure the content at all. When I was on gnome, I relied on this extension to make the overview usable for more than 4 windows (they become really hard to tell apart): https://extensions.gnome.org/extension/60/overlay-icons/

I can't show what my setup looked like cause the extension requires an old version of Gnome, but it basically looked like that screenshot, except the icons were much more translucent and didn't have that gray box around them. It didn't prevent you from seeing the window content but it helped a lot to zero in on the app that you wanted.
Comment 22 hvm 2019-04-26 10:06:09 UTC
So is there a decision on what will happen with this feature? 

Is there some way in which I could help? I could help writing the code but building and testing kwin is a daunting task for me.
Comment 23 Saverio Brancaccio 2019-05-23 13:23:44 UTC
Pease, consider to implement this feature allowing the user to:
- diable the windows dimming;
- enable windows dimming and in such case: regulate the brightness with a GUI control in the effect settings.

Many thanks.
Comment 24 leftcrane 2019-05-24 00:25:29 UTC
Why even have an option for dimming? 

All it does is make it harder to identify windows (virtually impossible in desktop grid) - why would anyone ever want this?
Comment 25 Saverio Brancaccio 2019-05-24 09:43:01 UTC
As already said, the advantages to have a configurable dimming are many from a genaral UI point of view. Some of them:
- Dimmed windows that illuminates on mouse hovering is eye popping on the long run and causes eyes fatigue. Imagine using the computer at least for 3 hours a day and switching the windows in such manner... it's better to have a setting.
- People are different so, for one could be ok for another not... it's better to have asetting.
- KWin should be universal, so adaptable to any needs...
Comment 26 hvm 2019-05-24 09:52:51 UTC
I agree, this is why I like KDE and why I always choose it over any other desktop/window manager - because it's so configurable and I can tailor it to suit me.

So even though I don't like the dimming feature, I don't want it taken away because I'm sure some people like it that way. 

I just want a setting to disable it or have a scale for it (0-100%).
Comment 27 Saverio Brancaccio 2019-05-24 14:00:25 UTC
This is a good fix, it should be adopded by kwiw developers: https://www.youtube.com/watch?v=QEHC43zMIMc
Comment 28 leftcrane 2019-05-25 14:00:35 UTC
Saverio Brancaccio,

You have only presented arguments AGAINST dimming. That's what I am saying nobody needs dimming - it's just bad. No other system does this.

The correct solution imo, is to draw a box around the hovered window and desktop There is no value in dimming at all. All it does is obscure content and cause eyestrain.

Why create and maintain bad/useless settings? Just to confuse users?
Comment 29 leftcrane 2019-05-25 14:02:58 UTC
If someone can present a use case for dimming, then it could be kept as an option. But don't think a use case exists. There are only arguments AGAINST it, i.e. only downsides with no conceivable upside.

There is no reason to have a setting that can only make your desktop interaction worse.
Comment 30 Michael D 2019-05-25 14:32:23 UTC
I agree to just remove dimming, and I would even be happy if nothing else about the effect were changed. A separate wish could be filed requesting to add a further hover animation like a border around the hovered window.
Comment 31 leftcrane 2019-05-25 14:34:18 UTC
I think it makes sense to treat them in tandem. Remove dimming AND replace with other effect, as the bug says.
Comment 32 Michael D 2019-05-25 14:37:00 UTC
Sure, but it's very easy to remove dimming and requires more work to add another hover effect, so if just removing dimming is the fastest possible fix until someone is found to implement another hover effect, I would prefer that. I would rather not wait on someone finding the time to implement another hover effect.
Comment 33 Saverio Brancaccio 2019-05-28 05:30:30 UTC
Sirs, considering all the comments here, it is clear this windows dimming is wrong. For sure it's clear that it must be removed or at least regulated through a simple setting... Now my questions are:
1) When this issue will be adressed? Discussions are going on from 2017!
2) Who is the developer responsible for this functionality?
3) What does think the developer about fixing the issue?

Thanks
Comment 34 antonio.guadagnin 2019-05-28 10:26:20 UTC
(In reply to Saverio Brancaccio from comment #33)
> Sirs, considering all the comments here, it is clear this windows dimming is
> wrong. For sure it's clear that it must be removed or at least regulated
> through a simple setting... Now my questions are:
> 1) When this issue will be adressed? Discussions are going on from 2017!
> 2) Who is the developer responsible for this functionality?
> 3) What does think the developer about fixing the issue?
> 
> Thanks

I just wanted to make it clear that this discussion started in 2013 and not only in 2017.

See:
https://bugs.kde.org/show_bug.cgi?id=329223

Six years have passed and we are still here with these discussion where it seems that on the other side there is someone who does not want to understand ...
Comment 35 Saverio Brancaccio 2019-05-28 12:29:56 UTC
Considering the number of votes (only 2 since 2017) on this issue, I suppose it's not an interesting feature to fix. 
Therefore, I reported a suggestion on a 3rd party site to have at least an extension that performs the function in subject:
https://github.com/Zren/plasma-applet-presentwindows
The author is the same of the video I already reported here in a previous message: 
https://www.youtube.com/watch?v=QEHC43zMIMc

Regards.
Comment 36 Kishore Gopalakrishnan 2019-05-28 12:39:32 UTC
(In reply to Saverio Brancaccio from comment #35)
> Considering the number of votes (only 2 since 2017) on this issue, I suppose
> it's not an interesting feature to fix. 
> Therefore, I reported a suggestion on a 3rd party site to have at least an
> extension that performs the function in subject:
> https://github.com/Zren/plasma-applet-presentwindows
> The author is the same of the video I already reported here in a previous
> message: 
> https://www.youtube.com/watch?v=QEHC43zMIMc
> 
> Regards.

As far as I understand, that extension doesn't do anything about the dimming. It just adds a button to trigger the 'Present Windows' shortcut.
Comment 37 pemartins 2019-05-28 13:49:53 UTC
Some points for consideration:
1. This issue exists since it was implemented, 6 years ago or whatever. I have no idea how the dimness was implemented in the first place because it's obviously a bad job, it's worst than finding Waldo: https://i.imgur.com/cARsxD7.jpg
2. This issue can be fixed faster than it takes to type any of the posts in this thread, change the 0.3 to 0.9 and it's done. Nevertheless it's been going on for years.
3. It was mentioned that this only had a couple of votes or something. It literally takes longer to count that couple of votes than to change a 3 to a 9.
4. A fix for this issue was posted some time ago. A good fix as shown on comments 14 and 27 above.
5. How are we still talking about this?
Comment 38 hvm 2019-05-28 13:54:30 UTC
(In reply to pemartins from comment #37)
> Some points for consideration:
> 1. This issue exists since it was implemented, 6 years ago or whatever. I
> have no idea how the dimness was implemented in the first place because it's
> obviously a bad job, it's worst than finding Waldo:
> https://i.imgur.com/cARsxD7.jpg
> 2. This issue can be fixed faster than it takes to type any of the posts in
> this thread, change the 0.3 to 0.9 and it's done. Nevertheless it's been
> going on for years.
> 3. It was mentioned that this only had a couple of votes or something. It
> literally takes longer to count that couple of votes than to change a 3 to a
> 9.
> 4. A fix for this issue was posted some time ago. A good fix as shown on
> comments 14 and 27 above.
> 5. How are we still talking about this?

Exactly. All good points and I'd also like to add that this is the kind of issue where it's difficult to figure out what is even wrong. 

I've been using KDE since the 2000s and I've never realised why I never really used the present windows feature, not until recently when I thought about it with my more recent experience in UX.

My point is that the amount of votes or whatever (I don't even know how you vote) is not necessarily relevant to how needed the change is.
Comment 39 Saverio Brancaccio 2019-05-28 14:49:33 UTC
(In reply to pemartins from comment #37)
> Some points for consideration:
> 1. This issue exists since it was implemented, 6 years ago or whatever. I
> have no idea how the dimness was implemented in the first place because it's
> obviously a bad job, it's worst than finding Waldo:
> https://i.imgur.com/cARsxD7.jpg
> 2. This issue can be fixed faster than it takes to type any of the posts in
> this thread, change the 0.3 to 0.9 and it's done. Nevertheless it's been
> going on for years.
> 3. It was mentioned that this only had a couple of votes or something. It
> literally takes longer to count that couple of votes than to change a 3 to a
> 9.
> 4. A fix for this issue was posted some time ago. A good fix as shown on
> comments 14 and 27 above.
> 5. How are we still talking about this?

At this point, 
1) what is the meaning of the votes on bugs here?
2) Solving this bug making tweakings in a text config file like kwinrc is not an acceptable solution for a normal user of a GUI system like KDE. Other Kwin effects have a GUI setting, introducing a GUI setting also for PresentWindows effect is a correct way to solve the bug from a system integration point of view.
Comment 40 pemartins 2019-05-30 20:29:33 UTC
Can we please just change the default dimness value for now, so that Present Windows can be usable?
Set it to 90%, because I believe even 80% is too dark.

And then we can go on brainstorming on how to improve it, but at least for now I beg than someone just solve this 6 years bug by changing the default value.
Thank you very much in advance.
Comment 41 Brian 2019-06-02 20:00:16 UTC
Agreed. This bug definitely needs to be fixed. At least set the brightness a tad higher. A better solution however would be to offer the ability to change the brightness of the feature.
Comment 42 Nate Graham 2019-06-30 14:21:59 UTC
*** Bug 409295 has been marked as a duplicate of this bug. ***
Comment 43 Michael D 2019-06-30 18:55:52 UTC
Bug 409295 is about the grid effect, not the present windows effect.
Comment 44 Nate Graham 2019-06-30 20:07:28 UTC
(In reply to Michael D from comment #43)
> Bug 409295 is about the grid effect, not the present windows effect.
Yes, but the Desktop Grid effect doesn't darken the windows the way the Present Windows effect does, so I assumed the reporte
Comment 45 Nate Graham 2019-06-30 20:07:50 UTC
...r meant the Present Windows effect instead.
Comment 46 Michael D 2019-06-30 20:11:01 UTC
Grid effect does dim non-hovered desktops and their windows. But the description isn't very clear and does sound like the reporter is referring to the present windows effect.
Comment 47 Nate Graham 2019-08-19 15:20:21 UTC
*** Bug 411025 has been marked as a duplicate of this bug. ***
Comment 48 Saverio Brancaccio 2019-09-01 09:21:32 UTC
From our last discussion and agreements on the motivations that confirmed our common vision to see this bug fixed, three further months have passed...

the bug is still here.
Comment 49 Vlad Zahorodnii 2019-09-01 10:03:29 UTC
> the bug is still here.
We have more important issues to fix than this one.
Comment 50 postix 2019-09-01 11:31:46 UTC
(In reply to Vlad Zahorodnii from comment #49)
> > the bug is still here.
> We have more important issues to fix than this one.

Not entirely true, there's a fix in the pipeline, but it still needs some time until it becomes good enough to be approved: https://phabricator.kde.org/D23480
Comment 51 Christoph Feck 2019-09-11 18:19:37 UTC
*** Bug 303438 has been marked as a duplicate of this bug. ***
Comment 52 Szczepan Hołyszewski 2019-10-10 09:43:58 UTC
(In reply to Saverio Brancaccio from comment #35)

> Considering the number of votes (only 2 since 2017) on this issue, I suppose
> it's not an interesting feature to fix.

The apparent lack of voters' interest is due to votes being spread among probably dozens of separate reports of this problem. Counting the sheer number of times it was independently reported is a better measure of how big a nuisance it is than counting votes on a single report.
Comment 53 Szczepan Hołyszewski 2019-10-10 09:46:13 UTC
Also there's this shady practice of marking older bugs as duplicates of newer ones in order to deliberately spread votes.
Comment 54 Nate Graham 2019-10-10 13:30:22 UTC
There's no conspiracy to hide a bug's severity. We're well aware that this is a pain point for users and are working on the political angle to get it done (the former maintainer declared this code off-limits pending a rewrite that never happened, so we need to either do that much-needed rewrite. or talk through reversing that policy).
Comment 55 hvm 2019-10-10 13:40:59 UTC
(In reply to Nate Graham from comment #54)
> There's no conspiracy to hide a bug's severity. We're well aware that this
> is a pain point for users and are working on the political angle to get it
> done (the former maintainer declared this code off-limits pending a rewrite
> that never happened, so we need to either do that much-needed rewrite. or
> talk through reversing that policy).

As far as I understood, the fix that would just take away the dimming (or set it to 90%) is rather simple to implement. Would that not be a good solution for now while the politics are sorted?
Comment 56 Nate Graham 2019-10-10 13:43:17 UTC
In fact we have a patch (mentioned earlier: https://phabricator.kde.org/D23480) that does just that. It caused visual artifacts that we haven't figured out how to fix yet. So in fact it turned out not to be so simple. :(

Don't worry, this *will* get done.
Comment 57 David Edmundson 2019-10-10 13:43:36 UTC
I have in principle approved the one patch that's there, pending a bug fix.
Comment 58 hvm 2019-10-10 13:50:20 UTC
(In reply to Nate Graham from comment #56)
> In fact we have a patch (mentioned earlier:
> https://phabricator.kde.org/D23480) that does just that. It caused visual
> artifacts that we haven't figured out how to fix yet. So in fact it turned
> out not to be so simple. :(
> 
> Don't worry, this *will* get done.

Hmm. I can't promise anything but I will try to help with this patch in the following days.
Comment 59 Murat Çileli 2019-10-12 12:17:58 UTC
This is a proof that UX have to be implemented by users and designers, not programmers.
Comment 60 postix 2019-12-17 12:44:28 UTC
Is this bug report also about the "Desktop Grid"? If so, shouldn't its title be adjusted?
Comment 61 Nate Graham 2019-12-17 23:54:00 UTC
No, Desktop Grid doesn't darken windows.
Comment 62 David Edmundson 2019-12-17 23:55:25 UTC
It does darken the entire desktop
Comment 63 postix 2019-12-18 12:53:39 UTC
(In reply to Nate Graham from comment #61)
> No, Desktop Grid doesn't darken windows.

(In reply to David Edmundson from comment #62)
> It does darken the entire desktop

So strictly speaking, it does darken windows as well. However, if you treat this as a different issue, I would reopen #409295.
Comment 64 antonio.guadagnin 2020-01-31 19:10:03 UTC
Time passes but nothing changes. This problem has been reported since 2013, perhaps someone has decided that it should not be solved.
Comment 65 Szczepan Hołyszewski 2020-03-26 22:08:47 UTC

*** This bug has been marked as a duplicate of bug 303438 ***
Comment 66 postix 2020-04-15 11:03:38 UTC
(In reply to Szczepan Hołyszewski from comment #65)
> 
> *** This bug has been marked as a duplicate of bug 303438 ***

Please let's keep this one the main bug as here already 23 people subscribed (vs 3 in the other) and the discussion was more intensive and it links to more related bugs -- even if you reported first. *thumps up*
Comment 67 Szczepan Hołyszewski 2020-04-17 13:20:33 UTC
> 1) When this issue will be adressed? Discussions are going on from 2017!

Actually it dates back to KDE4 and the ancient times when the frame rates were so low that visible "pulsing" increments/decrements of brightness over large areas of the screen posed a seizure risk.
Comment 68 Michael D 2020-05-04 09:07:46 UTC
Out of curiosity, I just ran a contrast check on the darkening effect. For black text on an almost white background, the darkening effect yields a 1.9:1 contrast ratio which is awful: https://webaim.org/resources/contrastchecker/?fcolor=1C3D5C&bcolor=666462. For the sake of usability, I would love to see this bug get squashed soon.
Comment 69 Michael D 2020-05-04 09:10:31 UTC
Actually what I just wrote isn't true--I didn't hit the darkest part of the text. Sorry: it's more like 3.34:1 which is still bad.
Comment 70 Vladimir Yerilov 2020-05-04 15:20:48 UTC
I don't know why the code of Present Windows is called "fragile", but changing a couple of digits didn't cause a disaster: it compiles and it works.
0.3 to 0.5 and 0.40 to 0.60 in `presentwindows.cpp`.
Yeah maybe I did something wrong because I am dummy in coding and stuff, but it worked for me.
However, the entire approach of dimming inactive windows is awful for any user who has a laptop. I don't understand how anyone can use this effect when setting brightness to 50% or lower. It could be such a great feature, just imagine yourself doing a multitouch gesture and seeing windows with, okay, sane dimming defaults...