Bug 493739

Summary: The windows are stacked in the wrong (reverse) order on the back surfaces of the cube presentation
Product: [Plasma] kwin Reporter: sulfinu
Component: effects-variousAssignee: Plasma Bugs List <plasma-bugs-null>
Status: CONFIRMED ---    
Severity: minor CC: kdedev, nate, paul.brown, vlad.zahorodnii, xaver.hugl
Priority: LO    
Version First Reported In: 6.0.0   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description sulfinu 2024-09-27 15:57:26 UTC
STEPS TO REPRODUCE
1.  Preparea a few desktops for your Plasma environment (3 should suffice, don't know if it works with just one).
2.  In one of the desktops, open three windows and make sure that none of them is maximized or minimized and no two of them overlap completely.
3. Trigger the cube presentation of windows and look at the desktop prepared at step 2., both from front and from back.

OBSERVED RESULT
The windows are stacked in the SAME order on the back surface of the desktop as on the front surface (albeit their contents is correctly mirrored).

EXPECTED RESULT
The Z order of windows on the back surface must be the INVERTED Z order of the front surface (i.e. the REVERSE order), because that's the natural appearance of the 3D scene that the cube effect is trying to show.

SOFTWARE/OS VERSIONS
Operating System: Gentoo Linux 2.15
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2
Kernel Version: 6.10.11-gentoo (64-bit)
Graphics Platform: Wayland
Graphics Processor: AMD Radeon Graphics
Comment 1 TraceyC 2025-03-17 20:42:55 UTC
Migrated to kwin
Resetting version
Comment 2 sulfinu 2025-10-21 10:24:39 UTC
Honestly, the beauty of the Cube effect was the 3D realism, which is severely affected by the wrong Z-order of windows. Is this issue so unimportant?
Comment 3 TraceyC 2025-10-21 15:00:19 UTC
Please be patient. Many KDE developers are volunteers, working in their spare time. There are literally thousands of opened bugs. This will be addressed when someone with the appropriate knowledge has the time.
Comment 4 sulfinu 2025-10-22 12:24:33 UTC
(In reply to TraceyC from comment #3)
> This will be addressed when someone with the appropriate knowledge has the time.

While I appreciate the effort that volunteer developers are putting into this project, I cannot help noticing that the huge number of bugs is partly due to the lack of accountability (or personal responsibility) within this humongous project called KDE.
Yes, I'm a developer and I know what I am talking about: I do not sleep peacefully until all known bugs introduced by the code I wrote are solved. Especially when they are relatively easy to solve, as I reckon this one is, in spite of its 13 months of age. By the way, setting the importance to "LO minor" is incorrect, as it actually implies that the Cube effect should be rather removed altogether than mended.

I suggest you change the management policy for confirmed issues: assign them to whoever is in charge of that area (kwin in this instance) and they will re-assign to whoever is likely responsible for the problem. For example, I suspect the Cube effect was rewritten for KDE 6 by one person (see https://github.com/zzag/kwin-effects-cube).

I hope you take this message to the higher levels in your organization, instead of dismissing it as rude or whatever. My message means to be constructive, from a KDE fan since the beginning of the century. Really 🙂
Comment 5 Paul Brown 2025-10-22 16:49:01 UTC
(In reply to sulfinu from comment #4)
> (In reply to TraceyC from comment #3)

> Yes, I'm a developer and I know what I am talking about:

Maybe you could lend us a hand

https://community.kde.org/Get_Involved

and solve it yourself. KDE is a woolly collective of volunteers with frilly and porous edges. You can nip in, solve the issue, and nip out. That would be grand, would it not? Imagine how satisfying that would be and the dev cred you would earn.

> I suggest you change the management policy for confirmed issues: assign them
> to whoever is in charge of that area (kwin in this instance) and they will
> re-assign to whoever is likely responsible for the problem.

And have them do what? You cannot force a volunteer to do anything they don't want to. If there is nobody who wants to solve a bug because... well, for any reason, there is not much anyone can do about that. We are not a company. We can't fire a volunteer, or dock their pay, or whatever you think we should be doing to make people do stuff.

> I hope you take this message to the higher levels in your organization,
> instead of dismissing it as rude or whatever. My message means to be
> constructive, from a KDE fan since the beginning of the century. Really 🙂

More the reason to finally give back. Here it is again:

https://community.kde.org/Get_Involved

I hope you can contribute to KDE. It is kinda fun!
Comment 6 sulfinu 2025-10-25 06:38:57 UTC
(In reply to Paul Brown from comment #5)
> Imagine how satisfying that would be and the dev
> cred you would earn.
> ...
> We can't fire a volunteer, or dock their pay, or whatever you think
> we should be doing to make people do stuff.

Can you see the contradiction that you've placed yourself in? You are trying lure me with sweet talk about "fun" and "dev cred", yet you won't use the same harangue when it comes to getting people to OWN their contribution, along with the included (programming) mistakes. Probably because you're afraid that KDE might lose a few contributors if they are not only given praise for what they've contributed to the project, but also held responsible for the flaws they introduced in the product.

How is it beneficial for KDE or any other open source endeavour to have flimsy contributions being included in it, without any commitment to maintain those code changes at the very minumum level of fixing totally attributable bugs (i.e. those caused exclusively by the contributed code)? It is not.
No matter how shiny such a product looks, people stop using it, sponsors start dropping off, the community enthusiasm fades and... the project falls into oblivion.

So, if somebody really cares about this project, especially since they do it for free, they should always have this sense of responsibility when contributing and genuinely care about the quality of their implementation. It is simply a matter of attitude that the KDE steering people should show to the community and thus educate the contributors. A simple gesture like assigning bugs will not "force" order in chaos, but will send a message about responsibility and will start decreasing the rate of bugs that pile up here.

Any project stems from a vision, but it is the commitment to that vision that makes the difference.
The most prominent example of what I'm talking about is Linux, the OS kernel initially developed and now overseen by an arrogant, highly intelligent and extremely disciplined guy. I'm not a fan of him, but one must admire his stubbornness which gave us one of the most influential pieces of software in the history of mankind. If you think these are big words, just try to imagine the world without Linux.

> More the reason to finally give back. Here it is again:
> 
> https://community.kde.org/Get_Involved
> 
> I hope you can contribute to KDE. It is kinda fun!

Yes, I was expecting this invitation. I am ALREADY contributing to this project just by having this conversation. As for the programming part, I cannot afford to lose months just to learn C++, some Qt, the inner workings of KWin and 3D graphics and whatever else is necessary just to understand the code that produces the Cube effect.
I haven't even found the time to implement in a language that I know (JavaScript) a Kwin script to restore a functionality you, the KDE decision makers, have taken away from us, users, namely walking through desktops in the most recently used order. There are some scripts in the wild, but imperfect.

Ironically, I saw your comment right after I noticed (again) a Plasma panel bug. I configured it to avoid windows; if it is visible and I move a window over it, it hides but never pops up again, no matter how much I push the mouse pointer to that edge of the screen. How did this go unnoticed during QA and why hasn't it been reported and fixed in Plasma so far (version 6.4.5 here), beats me. Should I place a bug and wait for some deity to inspire the proper volunteer to repair this sometime in the next decade?!
Comment 7 Paul Brown 2025-10-25 08:03:43 UTC
You write a lot just to say "I want unpaid volunteers do for me for free things I can't be a**sed to do myself".