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
Why shouldn't the brightness be hardcoded? Are you seeing some visual glitches with any windows or something?
Created attachment 108259 [details] Present Windows on Windows 10
Created attachment 108260 [details] Present Windows on KDE
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!
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.
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?
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/
Hi there again, I would like you to know I have made a diff request on KDE phabricator. https://phabricator.kde.org/D8388
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.
*** Bug 329223 has been marked as a duplicate of this bug. ***
*** Bug 398881 has been marked as a duplicate of this bug. ***
*** Bug 394810 has been marked as a duplicate of this bug. ***
*** Bug 401196 has been marked as a duplicate of this bug. ***
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?
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.
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.
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.
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).
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.
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.
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.
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.
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.
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?
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...
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%).
This is a good fix, it should be adopded by kwiw developers: https://www.youtube.com/watch?v=QEHC43zMIMc
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?
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.
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.
I think it makes sense to treat them in tandem. Remove dimming AND replace with other effect, as the bug says.
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.
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
(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 ...
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.
(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.
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?
(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.
(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.
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.
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.
*** Bug 409295 has been marked as a duplicate of this bug. ***
Bug 409295 is about the grid effect, not the present windows effect.
(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
...r meant the Present Windows effect instead.
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.
*** Bug 411025 has been marked as a duplicate of this bug. ***
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.
> the bug is still here. We have more important issues to fix than this one.
(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
*** Bug 303438 has been marked as a duplicate of this bug. ***
(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.
Also there's this shady practice of marking older bugs as duplicates of newer ones in order to deliberately spread votes.
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).
(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?
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.
I have in principle approved the one patch that's there, pending a bug fix.
(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.
This is a proof that UX have to be implemented by users and designers, not programmers.
Is this bug report also about the "Desktop Grid"? If so, shouldn't its title be adjusted?
No, Desktop Grid doesn't darken windows.
It does darken the entire desktop
(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.
Time passes but nothing changes. This problem has been reported since 2013, perhaps someone has decided that it should not be solved.
*** This bug has been marked as a duplicate of bug 303438 ***
(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*
> 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.
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.
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.
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...