Building the Plasma6 for Slackware-current in the KTown style - a build based on the AlienBOB's KTown
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Well, when I started this Plasma6 build, I was fully aware that I will enter in Kazachok, soo ...
Ha ha! I know that "entering Kazachok" is a euphemism used by your people for a fast paced and difficult task.
But you've already entered Kazachok, so... now, dance!
Quote:
Originally Posted by LuckyCyborg
There is a patch for the second Plasma6 build of mine, in the form of a tarball named plasma6-patch-20240510.tar and sized as 185.38MB . Yep, this is a relative small one and you can find it there for the next 30 days:
This tarball contains both updated packages and a patch for the source tree. The packages includes the new KDE Frameworks 6.2.0 , also kirigami-addons-1.2.0 and 2 rebuilds for KWin and plasma-workspace.
The KWin package was rebuilt for patching the Pipepire issue on KWin, by using the upstreamed !5708 patch (aka the one made by Mr. Edmundson and based on the work of our fellow @ctrlaltca) . This fixes the PipeWire issue on Wayland/Plasma6 sessions and everything related works again. Many thanks again, @ctrlaltca!
In other hand, I have noticed that Mr. Hameleers patched the Wayland/Plasma6 session in something which is roughly similar with the Plasma (Full Wayland) session as we know on Plasma5. Well, honestly I wanted to see Plasma6 acting as intended, without forcing "wayland" for every little application. So, in a way similar to Plasma5, I have "restored" the Full Wayland sessions, while leaving the stock Wayland sessions alone, as they are intended by upstream.
Finally, the kirigami-addons-1.2.0 is an update made upstream - but I for one I consider it an important one, worth to be particularly shipped in a patch.
Thanks a lot for the patch tarball. I upgraded packages without problems, both the KDE Frameworks 6.2.0 and the other rebuilds. Of course, using your second Plasma6 build as a base.
Indeed, with the KWin patched package, the PipeWire screencast works perfectly in Wayland sessions. Many thanks to @ctrlaltca (Fabio Bas) who had this clever idea on how to fix the PipeWire link.
About the return to Plasma (Wayland) and Plasma (Full Wayland) sessions, I think it's a good idea. Probably Wayland backend forcing was necessary in KDE Plasma 6.0 beta2, but from what I've seen, the desktop works great even without this backend forcing.
However, I noticed that the Wayland backend is preferred by both Firefox and most Qt6 and Qt5 programs. So, in the end, the sessions are like Full Wayland.
To be honest, I would still prefer the desktop to let the applications choose the backend, as Plasma5 does. But, as you know, in Plasma5 this was possible by compiling Qt5 with a special parameter: -qpa "xcb;wayland"
I wonder if something like this is possible with Qt6 and KDE Plasma 6.x and if so, what is the right parameter for Qt6, which uses cmake as build system.
Last edited by ZhaoLin1457; 05-11-2024 at 01:02 PM.
Well, when I started this Plasma6 build, I was fully aware that I will enter in Kazachok, soo ...
There is a patch for the second Plasma6 build of mine, in the form of a tarball named plasma6-patch-20240510.tar and sized as 185.38MB . Yep, this is a relative small one and you can find it there for the next 30 days:
I installed the MuseScore 4.3.0 package uploaded by LuckyCyborg in post #45 of this thread and it seems that your program now has no problem with positioning the menus in Plasma (Wayland) sessions, but presents the same problem with Plasma (Full Wayland) sessions .
So it looks like your problem was caused by the Wayland backend forcing on Qt5 applications.
I installed the MuseScore 4.3.0 package uploaded by LuckyCyborg in post #45 of this thread and it seems that your program now has no problem with positioning the menus in Plasma (Wayland) sessions, but presents the same problem with Plasma (Full Wayland) sessions .
So it looks like your problem was caused by the Wayland backend forcing on Qt5 applications.
Thanks. I hadn't have time to try the patched MuseScore to provide feedback but I don't think it's due to the "Wayland backend forcing on Qt5 apps" as you said. I also compiled MuseScore 3.6.2 (latest release in the 3.6 series) using Qt5, and this app shows the menus in their right position without any need to force anything.
It's likely more as @LuckyCyborg said, MuseScore 4.x tries to do some tricks with the rendering which aren't going too well with a Qt6-based Wayland environment.
Regarding the MuseScore's menus issue on Wayland/Plasma6 sessions, I can confirm it, if it's about what you see in the attached screenshot. And this one is MuseScore 4.3.0
However, looks like even on latest version of 4.3.0 the MuseScore has NO support for Qt6 (but they work actively on porting it to) and to add insult to injury, they use a custom way on rendering the interface, which is clear that is not fully compatible with the latest support offered by the Wayland/Plasma6 sessions.
BUT, I for one I am not a C/C++ programmer, so my sincere suggestion is you to open an issue on their repository, along with the 2.5k other ones already present.
Meanwhile, I have experimented with a "special" package, which uses a script wrapper to force the XCB platform even on those Wayland sessions. This means that even on a Wayland session the MuseScore will use the X11 backend (via XWayland) and the menus will be properly rendered. For your convenience, I have uploaded a tarball containing both the package and the SlackBuild, and you can find it bellow:
Let's hope that they are aware by this issue with Wayland/Plasma6 and that they will fix it along with the porting to Qt6 which is now done on the "master" branch.
Thanks for the great help regarding the MuseScore issue. I tried your package and I can confirm that now menus render in their correct place. Yay!!
Still, menus still do not behave as they should: I cannot navigate between menus using keyboard (for example, I must use a mouse to go from the File to the Edit menu, and so on) but at least they are in their place and working as expected. Thanks again!!
Well, when I started this Plasma6 build, I was fully aware that I will enter in Kazachok, soo ...
There is a patch for the second Plasma6 build of mine, in the form of a tarball named plasma6-patch-20240510.tar and sized as 185.38MB . Yep, this is a relative small one and you can find it there for the next 30 days:
This tarball contains both updated packages and a patch for the source tree. The packages includes the new KDE Frameworks 6.2.0 , also kirigami-addons-1.2.0 and 2 rebuilds for KWin and plasma-workspace.
The KWin package was rebuilt for patching the Pipepire issue on KWin, by using the upstreamed !5708 patch (aka the one made by Mr. Edmundson and based on the work of our fellow @ctrlaltca) . This fixes the PipeWire issue on Wayland/Plasma6 sessions and everything related works again. Many thanks again, @ctrlaltca!
In other hand, I have noticed that Mr. Hameleers patched the Wayland/Plasma6 session in something which is roughly similar with the Plasma (Full Wayland) session as we know on Plasma5. Well, honestly I wanted to see Plasma6 acting as intended, without forcing "wayland" for every little application. So, in a way similar to Plasma5, I have "restored" the Full Wayland sessions, while leaving the stock Wayland sessions alone, as they are intended by upstream.
Finally, the kirigami-addons-1.2.0 is an update made upstream - but I for one I consider it an important one, worth to be particularly shipped in a patch.
PS. For those who wonder what's Kazachok, well ... it's a popular fast paced (and rather acrobatic) dance, practiced by the young ones of several Slavic nations. Supposedly, it was invented by and for the Cossack Cavalry - who hundreds of years ago was an elite force of the Tsarist Empire.
I'm a little late (and a little slow) but this past weekend brought Mothers Day, my mothers (70th!) birthday, and a lot of work for the Man, so I had not time for this adventuring!
After the latest kernel update, SDDM crashes repeatedly and after some retries, completely locks the system, forcing it to power cycle, making the filesystem dirty. The system gets usable only after switching to runlevel 3, and selecting something like Xfce 4 from xwmconfig, and then launching the graphical (X11?) desktop with startx. Otherwise is the same repeating crash.
Under Xfce4, some Plasma apps start OK while others crash with this message from the terminal:
Believe it or not, the last -current update happened for me without incidents. This while rocking a rather lame Intel i5-3570s - which at best would raise condescend smiles of many from this forum.
BTW, this "Illegal instruction" means that some nonexistent CPU instructions are tried to be executed on your CPU. So, my nose says that our BDFL messed something with this GCC build pushed on -current today.
You know, that /usr/lib{,64}/libgcc_s.so.1 is a really nasty, but nasty thing.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.