This week we released a beta of Plasma 6.8, and it’s ready for testing. Before branching, the team landed a lot of great improvements to make sure it’s an awesome release. Check it out:
That’s quite disappointing, but I guess it’s cool that there are some theoretical mystery apps that may be able to be restored. Fingers crossed I’ll either be able to live with it or that it’ll be resolved in the near future.
Separate question, is there some kind of “let apps handle their own scaling” setting for Wayland like there is for X11 apps? SDL for example is not great in Wayland mode because of “scaling” messing up the works. And how is that for image editors like Krita? Are they able to display non-blurry pictures no matter what scaling settings?
Can Wayland touchpad gestures be disabled or adjusted?
No, that might be a compositor feature, telling or assuming a different scale factor for an application, but in the grand scheme of things it shouldn’t be necessary.
The application can render itself however it sees fit in window size * dpi pixels, and that’s the point. It just needs to acknowledge the size passed is logical size and not a physical one.
Then thanks to dpi you can have crisper fonts and images with the rest of the UI unchanged.
Probably SDL wayland support has not matured yet. Can you be more specific.
Yes, that’s exactly the point of fractional scaling.
That’s how it’s worked for decades, yes, and I hope it’ll continue to do so for decades more. On 6.7 at least (but dating back to 5.x) there’s something iffy about the window size in Wayland in combination with games: you request one and it ends up at two or three times the desired size. What you (or at least I) want is 1x “scaling” with the DPI passed along rather than prescaled window sizes. I.e., if I ask the game to start in 800 × 600 I don’t want it to be 1600 × 1200 because of some “scaling factor”, and the game having to calculate that backwards by dividing through the scaling factor seems weird. Ime there’s something off here in (KDE?) Wayland that’s handled correctly in Windows, but it could be SDL3’s fault. Anyway, for the most part this is merely a minor detail insofar as excessive GPU usage and low performance is a minor detail; it doesn’t lead to anything blurry.
Alright, last time I tried Krita in Wayand it was a blurfest and I think my tablet might not even have worked properly.
Copying text in LibreOffice apps now adds it to the persistent history every single time, rather than only every other time.
Thank you! I think I was going crazy with this one. I see it took a lot to figure it out and fix it, thank you for getting into the unglamorous guts of the system.
Just wanna say that whoever made the change in Dolphin’s built-in batch renamer to remember the last renaming method deserves a glass of refreshing water.
I did not know how much I needed this to be the default until it became the default.
Thank you very much!
That said, not all changes to default functionality are welcome, so asking the community is always a great idea.
I am putting a lot of time into improving Klipper. It shows that it is more than twenty years old, but I believe it will come into a nice shape once 6.9 comes . I also have some cool ideas for it, let’s hope they come into fruition and are accepted (besides the 15 open MRs now :-)).
I would suggest removing the “Details” button. Two of the three labels are already shown somewhere else in this window, and I would say the third (“X GB of Y GB”) should not be hidden.
Rounding the Y-axis labels to at least the nearest whole number (here, more like to the nearest 10) would also look nicer, IMO.
I would suggest the details button stay and that when the dialog first pops up it only have the information it use to before the graph was added, then one can press the details button to get the graph.
The Details button is what make progress bar being replaced with a the graph, so it needs to stay.
Although I improved the graph display, https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6963 now it will always have data from the beginning regardless of when the user clicked on details.