Bug: Kwin crashes when maximizing Windows with optionBorderlessMaximizedWindows=true!

I don’t want borders/Decorations on maximized windows as that is a complete waste of screen real-estate.

So I set:
[Windows]
BorderlessMaximizedWindows=true

in $HOME/.config/kwinrc (you could also set it kdeglobals).

That works fine, EXCEPT when I choose a non standard Window decoration, the “Maximize” button crashes kwin, EVERY single time, no matter which decoration I have chosen (yes, I still want to skin my window borders and have window borders for non-maximized window).

Strange thing, kwin does NOT crash, if I choose “Maximize” by right clicking on the process’ icon in the task bar, nor does it if I choose Maximize from the Window menu (invoke by right-clicking the application icon of the window).

This bug has been there in all versions of Plasma 5, but worked flawlessly in Kde 4.x.
It’s SUPER annoying as I keep forgetting it, and push the “Maximize” icon, and then have subsequently have to restart kwin.

This bug (and this only) is so annoying that I actually run Ubuntu Mate on most of my Linux boxes instead of Netrunner, because it has a “Undecorate Maximized Windows” option, and it does not crash when maximizing a window through the windows maximize button. But then I miss out on so many other things. I actually reinstalled Netrunner 14 after both Netrunner 15 and 16, but that has become so outdated by now.

Kubuntu has the same problem.

I just want to return to netrunner as in my view, it’s by far the best distro out there.

Is this bug reported to KDE already? (bugs.kde.org)
If not I would suggest to report it there with a super detailed way to reproduce. Soo what other decorations did you choose and so on.

Yes I thought so afterwards, and agree.

I posted a bug. https://bugs.kde.org/show_bug.cgi?id=362772 and https://bugs.kde.org/show_bug.cgi?id=362770

Answer from what I would assume is a KDE developer was “I know exactly what is wrong - it’s QT’s fault, who will not fix it ever, and while we could make a work-around (they did that for the close button!)”, he could not care less, and even labeled it as fixed despite it was not even fixed (he has removed that again, apparantly). and btw, he is not using QT/KDE anymore… VERY comforting.

So I guess it’s time to leave KDE for reasons I don’t understand the logic behind. Unfortunately it not only confirm my conception of KDE developer’s attitude, but preceded it.

I don’t know him. Though there are other developers working on Kwin and improving it.
As far as I understand the bug is in QML and needs to be fixes by Qt or a workaround needs be be applied in Aurorae which uses QML for its decoration.

Simplest workaround for now is either using breeze decoration or any other non aurorae decoration.

Don’t get frustrated by a few people spreading strangely pissed comments. :slight_smile:

Ok, thanks for your support. I got super frustrated that the KDE team just would ignore something so arrogantly (even if I understand it’s not their fault in the first place, but they know how to work around it), and because I really do like KDE (so much I always without exception start missing it, even with compiz and all its bells and whistles turned on).

And I have used your work-around solution, but sooner or later (mostly sooner) I always get a little tired of breeze (and the 1-2 others I have had working), not to mention before even selecting them in the first place. hehe. They are nice, stylish, just not me - too big, and too little colors in my view.

Is there an easy way for me tell which Decorations are Aurorae and which are not? When browsing the kde-get-more-decoration interface, I mean, so not directly downloading them all to check the content. I’m guessing most if not all there are Aurorae based? Many have not been updated for years and many can’t even download anymore, at least not directly.

FIXED: https://phabricator.kde.org/D1586 :smiley:
Now why didn’t I report this error a year ago instead!?!? :blush:
Now I should be able to return to KDE soon (well as soon it’s in a mainstream release) :heart:

FIXED-IN: 5.6.5

Any change we can have KDE 5.6.5 or later in Netrunner 18?

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

Wow - feels good to only speak to yourself on here, like it seems I’m doing here…
Or maybe it does not feel that good…
One things was the statements, another was the ignored question(s)…

We can’t answer on stuff we don’t know yet.
Netrunner 18 will ship whatever KDE Neon provides by the time.
This means this bugfix could be in already.

Thanks for answering, and even a “we cannot answer” would have been better than silence, but you actually answered much more than that in this reply by stating you’re following Neon (as opposed to kubuntu 16.04), if I read your reply correctly, so I’m grateful! :slight_smile:

Which brings me back to what is probably your most hated question - Do you have any estimation of a Netrunner 18 release (just in ball-game figures)?

KDE 5.6.5 was just officially released, so now that should be no stopping the Netrunner team to reealeasee a new version. :wink: