this conflicts with the need of e.g. bug #175521

Not sure whether this is worth an option.

I agree with the reporter of #175521 in that I am all for clear indication of current selection. I just vote to spare the actual image of the window from visual modifications beyond the necessary downscaling. IMO the thumbnail should *look like* the window it represents as much as possible. OTOH some users might want it the other way, which is why I'm asking for an option.

I'm sorry, but this sounds like featuritis to me. The plan is to have Present Windows as QML in the next version. In that case you could just modify the installed sources or easily fork it.

It's 2019 and KDE5 and the "plan to have Present Windows as QML" either didn't materialize, or the QMLization didn't involve the dimming feature. As late as November 2018 people were actually hacking in C++ to get rid of this "feature", as evidenced here:

https://www.youtube.com/watch?v=QEHC43zMIMc

If there is any "featuritis" involved, it is the inclusion of the window dimming feature in the first place. I therefore upgrade this request from making the feature configurable to removing it altogether. It harms the ability to locate the desired window visually, it is a health risk if the framerate drops too much (see 303437), and it has no redeeming qualities whatsoever.

Dimming as a GUI idiom should be applied to things that are irrelevant to the task being currently performed by the user. When the user is being tasked with examining multiple items and choosing one of them, then ALL the items are relevant, and dimming must not be applied.

*** This bug has been marked as a duplicate of bug 385522 ***

*** Bug 385522 has been marked as a duplicate of this bug. ***

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.

To whoever implemented this originally and still holds the implementation hostage: you were wrong to implement it in the first place, you shouldn't have done that, this misfeature is exactly 0% useful and exactly 100% harmful, it goes completely against the established UI semantic of dimming (you DON'T dim things that are SPECIFICALLY RELEVANT to user's current activity, you dim ALL THE OTHER THINGS), and it has no redeeming qualities. Those who want it to stay are objectively wrong. Those who want it gone are objectively right. This is not a matter of opinion. Do the right thing. REMOVE IT.

*** Bug 329223 has been marked as a duplicate of this bug. ***

*** Bug 398637 has been marked as a duplicate of this bug. ***

*** Bug 394810 has been marked as a duplicate of this bug. ***

*** Bug 398881 has been marked as a duplicate of this bug. ***

*** Bug 401196 has been marked as a duplicate of this bug. ***

*** Bug 411025 has been marked as a duplicate of this bug. ***

*** Bug 431313 has been marked as a duplicate of this bug. ***

Tone of dupes over many years; raising priority.

Clearly we need a balance between the request here and the change made in Bug 175521. Perhaps the active window could be slightly enlarged with a large and obvious glow effect, rather than darkening every other window.

(I mean, a bigger enlargement effect, since the current one already enlarges the selected window slightly)

So will 2021 be the year when this insanely stupid bug gets fixed? When I first looked up this problem I was just starting university and now I'm at a phase where I might have kids. If my kids have to search for "kde present windows disable dimming", I honestly think it means we've failed as a species.

Counterpoint: if our children's worst problem is inactive windows in KWin's Present Windows effect being dimmed, we're doing pretty well as a species. :)

Yes, hopefully 2021 will be the year!

Make other windows solid black and scale active window %900. Just a usual KDE UI/UX design idea. What a waste of time. Glad to switched to GNOME years ago.

If we've failed as a species, you shouldn't be having kids! So wait to have them until this bug gets fixed...I hope it does!

Haha, good point. Well I guess the fate of my bloodline is in the developers' hands.

Is there a workaround?
Looks like it is too easy to fix.

I'm not a C++ developer so i can't fix it as shown here: https://www.youtube.com/watch?v=QEHC43zMIMc

Could someone attach some script or Solution here?

At this point I think the devs are just trolling us. They read this comment thread and have a laugh.

There is every intention to change this, but it's simply not so simple due to the very old fashioned code involved. Someone submitted a merge request about a year ago, but abandoned it after being unable to address issues found during testing. If this were an easy thing to do, it would have already been done. Your patience is appreciated. :)

(In reply to Nate Graham from comment #26)
> There is every intention to change this, but it's simply not so simple due
> to the very old fashioned code involved. Someone submitted a merge request
> about a year ago, but abandoned it after being unable to address issues
> found during testing. If this were an easy thing to do, it would have
> already been done. Your patience is appreciated. :)

Yes Nate we understand. Sometimes the things is harder than it look.
But I have found a bug that eventually/maybe can help. "A good bug"
When we have only one workspace the thumbnails dont dim. Of course i don't know if it is enough.

So works perfectly with only one workspace.
Easy to use.

We appreciate the KDE team effort

Great workaround.
Problem solved!

Just try this:
https://store.kde.org/p/1370195/

More details here:
https://github.com/tcorreabr/Parachute

There is no such thing as "great workaround". A workaround is at best passable, by definition.

Please don't detract from the severity of this issue by suggesting workarounds. This issue **ABSOLUTELY MUST** be fixed "in core".

(In reply to Szczepan Hołyszewski from comment #29)

You are a warrior! Almost ten years fighting for what you want.
Szczepan Hołyszewski 2012-07-12 20:55:01 UTC

> There is every intention to change this, but it's simply not so simple.

We literally want the code to STOP doing something that it currently ACTIVELY DOES. It is an extraordinary claim requiring extraordinary evidence to say that STOPPING doing something is any more complicated than, well, stopping.

Agree. Comment out the offending code. Not having an effect to show the active window is not an issue since, as it is now, this feature is unusable.

Yes, Just comment the code.


 Nate, how about give support to Parachute project? It is an excellent project that fills the gap. Maybe put in KDE incubator. Is stable but there are few bugs and could be a KDE project. The project owner agree about incubator. I could put him in touch.

(In reply to Szczepan Hołyszewski from comment #31)
> We literally want the code to STOP doing something that it currently
> ACTIVELY DOES. It is an extraordinary claim requiring extraordinary evidence
> to say that STOPPING doing something is any more complicated than, well,
> stopping.
Yes, that's the easy part, but then there's not enough of a visual highlight for the hover or selected window, and implementing that proves to be challenging. If we don't implement that, then the work is only half-finished and we will get bug reports about *that*. :)


(In reply to Leonardo from comment #33)
>  Nate, how about give support to Parachute project? It is an excellent
> project that fills the gap. Maybe put in KDE incubator. Is stable but there
> are few bugs and could be a KDE project. The project owner agree about
> incubator. I could put him in touch.
I reached out to the author last year and he said he didn't consider the code to be in a good enough state to upstream.

(In reply to Nate Graham from comment #34)
> (In reply to Szczepan Hołyszewski from comment #31)
> > We literally want the code to STOP doing something that it currently
> > ACTIVELY DOES. It is an extraordinary claim requiring extraordinary evidence
> > to say that STOPPING doing something is any more complicated than, well,
> > stopping.
> Yes, that's the easy part, but then there's not enough of a visual highlight
> for the hover or selected window, and implementing that proves to be
> challenging. If we don't implement that, then the work is only half-finished
> and we will get bug reports about *that*. :)
> 

Is it difficult to reduce the dimming effect? Right now it seems to cut a lot, what if you set it to 20% or so?

Or how about disabling this based on a setting in the Preview Windows panel?

(In reply to hvm from comment #35)
> Is it difficult to reduce the dimming effect? Right now it seems to cut a
> lot, what if you set it to 20% or so?
That's easy, but it too doesn't really solve the problem--just reduces its magnitude, in proportion to the amount by which it reduces the clarity of which window is hovered/selected.

> Or how about disabling this based on a setting in the Preview Windows panel?
That's possible.

However I will mention that KWin's effects are currently being rewritten to be able to use interactive 1:1 touchpad gestures, and once the Present Windows effect gets this treatment, the UI will be utterly trivial to change and we can finally add a damn glow or whatever instead of dimming other windows. :)

(In reply to Nate Graham from comment #34)
> (In reply to Szczepan Hołyszewski from comment #31)
> > We literally want the code to STOP doing something that it currently
> > ACTIVELY DOES. It is an extraordinary claim requiring extraordinary evidence
> > to say that STOPPING doing something is any more complicated than, well,
> > stopping.
> Yes, that's the easy part, but then there's not enough of a visual highlight
> for the hover or selected window, and implementing that proves to be
> challenging. If we don't implement that, then the work is only half-finished
> and we will get bug reports about *that*. :)
> 
> 
> (In reply to Leonardo from comment #33)
> >  Nate, how about give support to Parachute project? It is an excellent
> > project that fills the gap. Maybe put in KDE incubator. Is stable but there
> > are few bugs and could be a KDE project. The project owner agree about
> > incubator. I could put him in touch.
> I reached out to the author last year and he said he didn't consider the
> code to be in a good enough state to upstream.

e told me about your interest. 
Now the software is more mature and stable. 

He changed his mind and is read for your idea. 
We tried with the brazilian KDE community but they are too resistant to new suggestions.

Could you try again? 
Or if you prefer, he could reach you.

Sure, I can reach out again. I'd love to have Parachute as essentially a future-proof, one-stop-shop replacement for the Present Windows and Desktop Grid effects.

(In reply to Nate Graham from comment #36)
> (In reply to hvm from comment #35)
> > Is it difficult to reduce the dimming effect? Right now it seems to cut a
> > lot, what if you set it to 20% or so?
> That's easy, but it too doesn't really solve the problem--just reduces its
> magnitude, in proportion to the amount by which it reduces the clarity of
> which window is hovered/selected.
> 
> > Or how about disabling this based on a setting in the Preview Windows panel?
> That's possible.
> 
> However I will mention that KWin's effects are currently being rewritten to
> be able to use interactive 1:1 touchpad gestures, and once the Present
> Windows effect gets this treatment, the UI will be utterly trivial to change
> and we can finally add a damn glow or whatever instead of dimming other
> windows. :)

OK. Well, I understand why you'd wanna focus on the better solution if you already have it planned. Still, if that will come in, say, 1 year, wouldn't it make sense to add an option for the 'hack' in the meantime?

I'd find it reasonable, yeah. However I have no time to work on this and I'm also not a KWin maintainer.

> "David Edmundson @davidedmundson locked this merge request 3 minutes ago"
Just locking a merge request to fix this issue and silencing users is also a way of handling bugs (see https://invent.kde.org/plasma/kwin/-/merge_requests/885)...

:/

I honestly don't get it: Since 9 years (!) users are arguing in a very clear and understandable way that darkening the windows is not a good idea. Someone sends a merge request to fix it. And what happens? - Nothing. That one developer who (for whatever reason) insists on dimming windows, despite the complaints, blocks the MR and locks conversation. Rather impolite, isn't it? I thinḱ kde should rearrange who has moderating rights...

The merge request will be merged once there is a highlight effect to replace the darkening effect. If we don't do that, we're just replacing one issue with another.

All the talk in the world won't change that, sorry. We don't merge half-baked work on purpose.

(In reply to Nate Graham from comment #44)
> The merge request will be merged once there is a highlight effect to replace
> the darkening effect. If we don't do that, we're just replacing one issue
> with another.
Well, it is a matter of which issue you prioritise.
Highlighting is of rather minor importance. It is already pretty clear which window is in focus by the change in size and the mouse cursor.
The darkening, however, is a considerable annoyance to many users, for reasons outlined by Szczepan Hołyszewski and others in great detail.

The issue of darkened windows being too hard to distinguish is way more problematic than the highlighting issue; you really cannot set both on the same level. User resonance on this bug should have made it pretty clear after all.

> All the talk in the world won't change that, sorry. We don't merge half-baked 
> work on purpose.
Please, rethink this statement. Please see the view that the half-baked work is the darkening effect itself, not its removal.

I would like to repeat the following:
> I see you don't want to have it enabled by default, but what about merging it 
> as optional and deactivated by default as a compromise?
This way, users could decide on their own what they prioritise. We do not want to wait for another year unitl someone manages to implement the outline.

If there is no foreseeable highlight merge request, does it make sense to wait for one? The darkening presents a major usability issue while the lack of highlight on hover is pretty minor. Merging half-baked work would constitute a significant improvement in this case, if you ask me.

(In reply to Michael D from comment #46)

Yep, I concur.

> All the talk in the world won't change that, sorry.
Many good arguments supporting our point of view have been presented.
What's the point at continuing to ignore them? This would only demonstarte bias and incompetence.

I understand that you're upset, but insulting the people with the power do do what you're asking may not be the most effective technique. :)

I think insults are not the best way.

But clearly after this "https://invent.kde.org/plasma/kwin/-/merge_requests/885" we will not have our "dream feature" and there are forces acting against.

It blows my mind just because is a hight demanded feature. 

Huge frustration here!

(In reply to Nate Graham from comment #49)
> I understand that you're upset, but insulting the people with the power do
> do what you're asking may not be the most effective technique. :)
Don't get me wrong. I don't want to insult you, and I highly appreciate your work in general, but I disagree about Present Windows.
Indeed discussing this has been rather frustrating, since it is so obvious from my/our perspective the darkening effect just ought to be removed, and the developer responses so far were mostly not cogent and missed the point.
In particular, I would like to understand why you tend to stonewall our reasoning so much? Locking a conversation shows that you are not open to consider other views thoroughly and that you only want to enforce your own opinion...

>In particular, I would like to understand why you tend to stonewall our reasoning so much?

We made a very minor changes that were purely visuals and you opened 2 bug reports immediately

We know that this change *will* result in a usability issue, I know that I will get more feedback. I do a lot of bugzilla I will have to deal with that. If something is not a direct improvement we stick to the status quo. 

Vlad and I are also completely rewriting the tech backends on how we draw the windows so that it will be easier to adjust new effects on top without having to resort to trade-offs.

> We made a very minor changes that were purely visuals and you opened 2 bug
> reports immediately
The sole purpose of the Present Windows effect is visuals. I opened bug reports because I saw the appearance changes as disimprovements, and I expect I'm not the only one. Espeically the overlays issue is not exactly minor.

> If something is not a direct improvement we stick to the status quo. 
Making the darkening optional would be a direct improvement in our opinion.

> We know that this change *will* result in a usability issue, I know that I will 
> get more feedback.
If something is a disimprovement, why not stick to the status quo?

"We know that this change *will* result in a usability issue" <-> "If something is not a direct improvement we stick to the status quo."

Contradiction in terms?

> Yes, that's the easy part, but then there's not enough of a visual highlight
> for the hover or selected window

Enlarging the window like it's currently done is super enough. I mean it's animation. It MOVES. Its BREATHES IN in frantic anticipation of being selected.

> If we don't implement that, then the work is only half-finished
> and we will get bug reports about *that*. :)

Then you'll revert the commit and I will apologize profusely, but I'm 99.99999999999999999% sure it won't happen.

> I understand that you're upset, but insulting the people with the power do do
> what you're asking may not be the most effective technique. :)

Do you really have that power though, or do you only have veto power, i.e. the power to prevent what we're asking to from being done? Because if the latter is the case, then maybe that power should be taken away from you.

> If we don't implement that, then the work is only half-finished
> and we will get bug reports about *that*.
It was designed to be optional. No one will bother to file a bug report.
I wonder whether it is really the MR that was "half-baked" or rather the developers' decision.

I find it awkward that you [the developers] argue on an issue with 8 duplicates and lots of comments, that you *might* *possibly* get bug reports when disabling dimming and making it *optional* in the settings.
As I already suggested repeatedly, if you fear introducing new issues (which is an extremely unlikely scenario), then make it disabled by default.

> All the talk in the world won't change that, sorry.
Anyway, this discussion is getting a waste of time, as you [the developers] (apparently) will not do anything, despite lots of good arguments and constructive criticism.
Therefore, I'll look into building Present Windows myself, the version I like. I hope this procedure is documented and does not involve compiling the whole KWin.


Thanks Szczepan for your continued commitment to this issue.

(In reply to Szczepan Hołyszewski from comment #56)
> > Yes, that's the easy part, but then there's not enough of a visual highlight
> > for the hover or selected window
> 
> Enlarging the window like it's currently done is super enough. I mean it's
> animation. It MOVES. Its BREATHES IN in frantic anticipation of being
> selected.
Hmm, that's true. I hadn't thought about that. Thanks for bringing it up. Maybe it would be okay after all.

Lol, we've repeatedly mentioned this before. It's in the issue description, second sentence:
> I feel that enlarging the thumbnail under the mouse is a sufficient indication of focus
But if you're considering it now I'm certainly happy with it ;))

If I can unproblematically select windows on my workspace without any hover animation, why wouldn't I be able to do the same when present windows is invoked? Because the windows might appear smaller? If they were button-sized, okay, but...

(In reply to Manuel Geißer from comment #58)
> > If we don't implement that, then the work is only half-finished
> > and we will get bug reports about *that*.
> It was designed to be optional. No one will bother to file a bug report.
> I wonder whether it is really the MR that was "half-baked" or rather the
> developers' decision.
> 
> I find it awkward that you [the developers] argue on an issue with 8
> duplicates and lots of comments, that you *might* *possibly* get bug reports
> when disabling dimming and making it *optional* in the settings.
> As I already suggested repeatedly, if you fear introducing new issues (which
> is an extremely unlikely scenario), then make it disabled by default.
> 
> > All the talk in the world won't change that, sorry.
> Anyway, this discussion is getting a waste of time, as you [the developers]
> (apparently) will not do anything, despite lots of good arguments and
> constructive criticism.
> Therefore, I'll look into building Present Windows myself, the version I
> like. I hope this procedure is documented and does not involve compiling the
> whole KWin.
> 
> 
> Thanks Szczepan for your continued commitment to this issue.

Can we still make our own though? If you start this project, let me know, I would like to help.

(In reply to Manuel Geißer from comment #58)

> Therefore, I'll look into building Present Windows myself, the version I
> like. I hope this procedure is documented and does not involve compiling the
> whole KWin.
> 
> 
> Thanks Szczepan for your continued commitment to this issue.

Please, don't forget to share.

Or why not help this project and share? (It seems to be almost done.) https://invent.kde.org/plasma/kwin/-/merge_requests/885

@hvm @Leonardo
Apparently there is a little misunderstanding. I don't mean to develop/maintain a fork of Present Windows, I just intend(ed) to compile the version without dimming locally (from the rejected PR, which to my understanding was finished).
However, I looked into it and I think it would indeed require compiling/installing the whole kwin, but I am reluctant to tamper with essential system components.

(In reply to Manuel Geißer from comment #64)
> @hvm @Leonardo
> Apparently there is a little misunderstanding...


Ok, got.

So maybe we could hope a 10 years birthday gift. I mean a fix from KDE.

<<<<<<<<<Szczepan Hołyszewski 2012-07-12 20:55:01 UTC>>>>>>>>>

(In reply to Nate Graham from comment #59)
> (In reply to Szczepan Hołyszewski from comment #56)
> Hmm, that's true. I hadn't thought about that. Thanks for bringing it up.
> Maybe it would be okay after all.

@Nate

Talking about that project: https://invent.kde.org/plasma/kwin/-/merge_requests/885

STARTING--------------------------------
1 - And if it starts with all thumbnails not showing effect(not dimming) it gets easy and very fast to find your target thumbnail. (as already happens in the mentioned project). 
2 - And if it starts with all thubnails not showing it's names and icons.


THEN------------------------------------
Now if "on mouse over" the SELECTED thumbnail:
1 - Dims
2 - Shows the icon
3-  Shows the window name 
4 - Increases it's size (as already happens in the mentioned project)


I'm talking to the dev and if you say yes he will work on it.
I just don't wanna make him waste time.

Is it enought to accept the fix and the merge request?

>I just don't wanna make him waste time.

Then please don't.

We have decided we want an outline or some other clear visual representation. There is a lot of active work going into making long term solutions to do things properly.

(In reply to David Edmundson from comment #67)
> >I just don't wanna make him waste time.
> 
> Then please don't.
> 
> We have decided we want an outline or some other clear visual
> representation. There is a lot of active work going into making long term
> solutions to do things properly.

Ok, no problem. 
gonna wait

(In reply to David Edmundson from comment #67)
> >I just don't wanna make him waste time.
> 
> Then please don't.
> 
> We have decided we want an outline or some other clear visual
> representation. There is a lot of active work going into making long term
> solutions to do things properly.

Okay, no problem.
Let's wait

Heh, as it turns out, a QML-based replacement is actually in active development over here: https://invent.kde.org/plasma/kwin/-/merge_requests/1177.

So this may get fixed to *everyone's* satisfaction sooner rather than later. :) Let's see how that plays out. If it looks like it's getting stuck, I can nudge it if need be.

I know we're asked for a lot of patience, but I think the end is in sight soon here. :)

(In reply to Nate Graham from comment #69)
> Heh, as it turns out, a QML-based replacement is actually in active
> development over here:
> https://invent.kde.org/plasma/kwin/-/merge_requests/1177.
> 
> So this may get fixed to *everyone's* satisfaction sooner rather than later.
> :) Let's see how that plays out. If it looks like it's getting stuck, I can
> nudge it if need be.
> 
> I know we're asked for a lot of patience, but I think the end is in sight
> soon here. :)

Thanks dude!

Interesting. Thanks for sharing it.

(In reply to Nate Graham from comment #69)
> Heh, as it turns out, a QML-based replacement is actually in active
> development over here:
> https://invent.kde.org/plasma/kwin/-/merge_requests/1177.

How long between "initial bits of QML-based present windows effect" and "final bits that will allow it to be merged"? My prediction: INFINITY. This project will be abandoned before the next fashionable technology of the day arrives to supplant QML, at which point it will be restarted with the new technology, and this will continue long after we all return to the ecosystem. 

COMMENT OUT THE OFFENDING LINE OF C++ CODE THAT DIMS THE WINDOWS. OR SET THE END VALUE OF THE OPACITY ANIMATION OF THE DIMMING OVERLAY TO 0 JUST LIKE THE START VALUE. OR WHATEVER, DEPENDING ON HOW IT IS CURRENTLY IMPLEMENTED AND WHICH NECESSARY CHANGE WILL BE TRULY MINIMAL. JUST STOP DIMMING THOSE WINDOWS. STOP. DO STRICTLY LESS THAT YOU CURRENTLY DO. DON'T START NEW A NEW PROJECT FOR THIS. DON'T DO ANYTHING NEW. JUST STOP DOING SOMETHING OLD AND TIRED AND UNIVERSALLY VISCERALLY HATED. JUST STOP.

I agree that dimming should be disabled (or at least there should be an option added to do so) in the classical Present Windows, as it will yet take time until the new QML replacement is ready for use. It would be a pity to leave Present Windows in the unusable state it is in right now. I would (again) vote for rolling back to Commit ff3cb599 and merging in PR 885.
However, the videos shared by Vlad Zahorodnii look really promising, and the code of the old Present Windows seems somewhat messed up, so in general I think this is the right path forward. **But please, please, please do NOT get the terrible idea of adding a dimming effect to the new QML Present Windows.**

(In reply to Szczepan Hołyszewski from comment #72)
> (In reply to Nate Graham from comment #69)
> > Heh, as it turns out, a QML-based replacement is actually in active
> > development over here:
> > https://invent.kde.org/plasma/kwin/-/merge_requests/1177.
> 
> How long between "initial bits of QML-based present windows effect" and
> "final bits that will allow it to be merged"? My prediction: INFINITY. This
> project will be abandoned before the next fashionable technology of the day
> arrives to supplant QML, at which point it will be restarted with the new
> technology, and this will continue long after we all return to the
> ecosystem. 
> 
> COMMENT OUT THE OFFENDING LINE OF C++ CODE THAT DIMS THE WINDOWS. OR SET THE
> END VALUE OF THE OPACITY ANIMATION OF THE DIMMING OVERLAY TO 0 JUST LIKE THE
> START VALUE. OR WHATEVER, DEPENDING ON HOW IT IS CURRENTLY IMPLEMENTED AND
> WHICH NECESSARY CHANGE WILL BE TRULY MINIMAL. JUST STOP DIMMING THOSE
> WINDOWS. STOP. DO STRICTLY LESS THAT YOU CURRENTLY DO. DON'T START NEW A NEW
> PROJECT FOR THIS. DON'T DO ANYTHING NEW. JUST STOP DOING SOMETHING OLD AND
> TIRED AND UNIVERSALLY VISCERALLY HATED. JUST STOP.

With this MR the windows aren't dimmed though, you can check this here: https://invent.kde.org/plasma/kwin/-/merge_requests/1177#note_279987

I'm sure you're annoyed by this but being disrespectful towards developers is not very nice (or clever).

There is absolutely nothing constructive or helpful in this bug report. Closing.

>**But please, please, please do NOT get the terrible idea of adding a dimming effect to the new QML Present Windows.**

Noted.

> There is absolutely nothing constructive or helpful in this bug report. Closing.
No. This is completely wrong (and quite instuling towards the reporters). There have been lots of constructive, reasoned and elaborate comments. I would like to list some of them:

> I feel that enlarging the thumbnail under the mouse is a sufficient indication 
> of focus, and there is one big argument against graying out: it reduces 
> thumbnails' visual similarity to the windows they represent. I think this 
> defeats the purpose of Present Windows, which is to let the user quickly
> visually locate the desired window *by what it looks like*.

> When the thumbnails are grayed out, the user's brain must perform additional 
> processing to ungray them for comparing with the image of the desired window 
> held in memory.

> It harms the ability to locate the desired window visually

> Dimming as a GUI idiom should be applied to things that are irrelevant to the 
> task being currently performed by the user. When the user is being tasked with 
> examining multiple items and choosing one of them, then ALL the items are 
> relevant, and dimming must not be applied.

> you DON'T dim things that are SPECIFICALLY RELEVANT to user's current 
> activity, you dim ALL THE OTHER THINGS

> Highlighting is of rather minor importance. It is already pretty clear which 
> window is in focus by the change in size and the mouse cursor.
> The darkening, however, is a considerable annoyance to many users

> The issue of darkened windows being too hard to distinguish is way more 
> problematic than the highlighting issue; you really cannot set both on the 
> same level. User resonance [8 duplicates] on this bug should have made it 
> pretty clear after all.

> The darkening presents a major usability issue while the lack of highlight on 
> hover is pretty minor.

> Enlarging the window like it's currently done is super enough. I mean it's 
> animation. It MOVES. Its BREATHES IN in frantic anticipation of being 
> selected.

--

> I'm sure you're annoyed by this but being disrespectful towards developers is 
> not very nice (or clever).
This is not the full reality. Developer's behaviour towards users has not been very respectful, either. Sometimes I have the impression that you don't actually read or don't think about what we are writing - we are merely ignored or silenced.

> > **But please, please, please do NOT get the terrible idea of adding a 
> > dimming effect to the new QML Present Windows.**
> Noted.
Thanks.

In any case, closing this report and claming it were not a bug is wrong.
You need to acknowledge that too strongly dimmed windows clearly are a usability issue, there can be no doubt whatsoever. Since this issue is not fixed, you may not close the bug report.
@NateGraham, or any other unbiased KDE developer: Please reopen. Keeping this bug open can only be in your own interest to avoid further duplicates (no one searches the closed issues).

* Developer's -> Developers'

Once the new QML Present Windows without dimming effect is merged, I would be fine with closing the report, but as long as this is not the case, it should be kept open.

David is simply frustrated that nobody will just shut up and let us do our work in peace. All the inflammatory comments people post here end up in our inboxes and depress us. ...Pointlessly so, because the QML replacement that implements the proposed change is in progress and close to completion, which is what you all want! When the change is merged, this bug report will be marked as fixed.

Therefore you just need to stop posting comments. There is nothing to be gained by more comments, really. Just stop posting comments. The change is in progress, just be patient and stop posting comments. Did I mention to stop posting more comments? Really. Be patient for another few weeks. It's not that hard. C'mon guys. You can do it. I have faith in you.

> There is absolutely nothing constructive or helpful in this bug report.

This is a lie.

> Closing.

Retaliatory closing is a whole new low.

> Therefore you just need to stop posting comments. There is nothing to be
> gained by more comments, really. Just stop posting comments. The change is
> in progress, just be patient and stop posting comments. Did I mention to
> stop posting more comments? Really. Be patient for another few weeks. It's
> not that hard. C'mon guys. You can do it. I have faith in you.

To mock is the job of a clown.

Git commit 6132329c2c48e22d48a37e7ec40028f6faefa1fd by Vlad Zahorodnii.
Committed on 19/08/2021 at 06:30.
Pushed by vladz into branch 'master'.

Add Overview effect

This effect is meant to be as a replacement for the present windows and
the desktop grid effect. It is written using QML.

So far, this effect implements only the basic features of the present
windows effect. Desktop management features will be added later.
Related: bug 295775

M  +5    -0    autotests/test_builtin_effectloader.cpp
M  +4    -0    src/effects/CMakeLists.txt
M  +17   -0    src/effects/effect_builtins.cpp
M  +1    -0    src/effects/effect_builtins.h
A  +7    -0    src/effects/overview/CMakeLists.txt
A  +794  -0    src/effects/overview/expolayout.cpp     [License: GPL(v2.0+)]
A  +142  -0    src/effects/overview/expolayout.h     [License: GPL(v2.0+)]
A  +20   -0    src/effects/overview/kcm/CMakeLists.txt
A  +79   -0    src/effects/overview/kcm/overvieweffectkcm.cpp     [License: GPL(v2.0+)]
A  +12   -0    src/effects/overview/kcm/overvieweffectkcm.desktop
A  +32   -0    src/effects/overview/kcm/overvieweffectkcm.h     [License: GPL(v2.0+)]
A  +70   -0    src/effects/overview/kcm/overvieweffectkcm.ui
A  +20   -0    src/effects/overview/overviewconfig.kcfg
A  +9    -0    src/effects/overview/overviewconfig.kcfgc
A  +326  -0    src/effects/overview/overvieweffect.cpp     [License: GPL(v2.0+)]
A  +94   -0    src/effects/overview/overvieweffect.h     [License: GPL(v2.0+)]
A  +110  -0    src/effects/overview/qml/ScreenView.qml     [License: GPL(v2.0+)]
A  +339  -0    src/effects/overview/qml/WindowHeap.qml     [License: GPL(v2.0+)]
M  +5    -0    src/kcmkwin/kwinscreenedges/kwinscreenedgesettings.kcfg
M  +5    -0    src/kcmkwin/kwinscreenedges/kwintouchscreensettings.kcfg
M  +16   -0    src/kcmkwin/kwinscreenedges/main.cpp
M  +1    -0    src/kcmkwin/kwinscreenedges/main.h
M  +16   -0    src/kcmkwin/kwinscreenedges/touch.cpp
M  +1    -0    src/kcmkwin/kwinscreenedges/touch.h

https://invent.kde.org/plasma/kwin/commit/6132329c2c48e22d48a37e7ec40028f6faefa1fd

The new QML-based Present Windows effect has been merged for Plasma 5.23, and it does not dim the inactive/un-hovered windows. :) See https://invent.kde.org/plasma/kwin/commit/6132329c2c48e22d48a37e7ec40028f6faefa1fd

Good things come to those who wait. :)

hallelujah!

Wow, thanks!
When approximately will the QML present windows land in Neon User, and how does one activate it?

(In reply to Nate Graham from comment #84)
> The new QML-based Present Windows effect has been merged for Plasma 5.23,
> and it does not dim the inactive/un-hovered windows. :) See
> https://invent.kde.org/plasma/kwin/commit/
> 6132329c2c48e22d48a37e7ec40028f6faefa1fd
> 
> Good things come to those who wait. :)

Now, would be great some rude people saying thanks

(In reply to Manuel Geißer from comment #86)
> Wow, thanks!
> When approximately will the QML present windows land in Neon User, and how
> does one activate it?
The new effect will be shipped in Plasma 5.23. It will be called "Overview". Currently its keyboard shortcut is Meta+Ctrl+D.

Currently it is shipped alongside the existing Present Windows effect and disabled by default while we sort out a few remaining issues to bring it up to feature parity. If we manage to make it in time, the existing effect will be replaced completely by the new one, with the same keyboard shortcut and everything. If not, then this will probably happen in Plasma 5.24 while we refine it over the next 3 or 4 months.

(In reply to Szczepan Hołyszewski from comment #82)
> > Therefore you just need to stop posting comments. There is nothing to be
> > gained by more comments, really. Just stop posting comments. The change is
> > in progress, just be patient and stop posting comments. Did I mention to
> > stop posting more comments? Really. Be patient for another few weeks. It's
> > not that hard. C'mon guys. You can do it. I have faith in you.
> 
> To mock is the job of a clown.

Yep, I wanted to say something similar :D

And yes, it's great that it got fixed but it could have been done without power trips and mocking.

Plot twist: Plasma 5.23 is apparently a "prestige" anniversary release and they are going to chisel and polish it for further MONTHS before this fix is available to end users.

> Plot twist: Plasma 5.23 is apparently a "prestige" anniversary release and they 
> are going to chisel and polish it for further MONTHS before this fix is 
> available to end users.
Yeah, if developers had acknowledged what an annoyance this dimming is, they could just have commented out the problematic line and release an updated package nine years ago, or they could have merged PR 885 five months ago...
It appears that fixing usability issues is just regarded as an unimportant side-effect of the Present Windows replacement; primarily it's just the move to a different underlying technology.

(In reply to Szczepan Hołyszewski from comment #90)
> Plot twist: Plasma 5.23 is apparently a "prestige" anniversary release and
> they are going to chisel and polish it for further MONTHS before this fix is
> available to end users.

What do you mean? Nate said the effect is being shipped with Plasma 5.23 though it "may" (which I guess is now "will") not replace it until later. Is this wrong?

> What do you mean? Nate said the effect is being shipped with Plasma 5.23 though 
> it "may" (which I guess is now "will") not replace it until later. Is this 
> wrong?
The problem we're talking about is that it will take even longer for this usability issue to be fixed, due to Plasma 5.23 getting additional months of polishing and QA.

No, actually the problem is that the issue is 9 years old, the decision to implement the dimming was undisputedly and objectively wrong, and people responsible for it not being correctly fixed on DAY ONE have actively, maliciously harmed KDE and should be fired.

> Plot twist: Plasma 5.23 is apparently a "prestige" anniversary release and they
> are going to chisel and polish it for further MONTHS before this fix is
> available to end users.
Well, actually that turns out to be wrong. It got released today (that is, in KDE Neon).

Well, the bug can be closed 10 years after. A long journey!
KDE 5.24 has released the overview functionality.

In my opinion the thumbnails are a little small.
And there is no option to hide krunner or the virtual desktops.

But it works pretty well.

Thanks

It turns out the Overview effect won't replace Present Windows after all. Instead, Present Windows has been rewritten to use the same modern, maintainable backend technology found in the Overview effect.

One advantage of this is that the bug here gets fixed automatically. No more darkening for unselected windows! It's been done by Marco Martin with https://invent.kde.org/plasma/kwin/-/commit/376ee357dbc50fec3b6e71c40938171ddb2e726a!