This week no major new features were merged, so we focused on polishing up what we already have and fixing bugs. That's right, Phoronix readers; we do in fact regularly do this! And let me also remind folks about our ongoing 2024 fundraiser: in it, you can adopt a KDE app to have your name displayed as an official supporter of that app. If you love KDE or its apps, this is a great way to show your appreciation.
Let’s all pray to saint Harald to inspire Harald, that seems to be in the wave of fixing update-related-bugs, to get to that nasty auto-updates bug ( #447245 ) that keeps preventing us from having an always updated system without having to babysit discover, shall we?! Ahahah
Nice work! Plasma keeps getting better!
(and now it will even have it’s own edition on fedora… nice!!!)
Is it possible to adjust the Z-axis value, - the cube (when you press Meta+C sits really low on the screen.
In and of itself, as a desktop effect, it doesn’t really serve a purpose because it’s no longer tied into the Virtual Desktops switching process which is in System Settings - Virtual Desktops.
Before, you could choose from the dropdown where it currently just says Slide, - and choose cube, which would visualise the switching effect. That, was the beauty and power of the cube, that you could use it to visualise your virtual desktops in 3d in a way that was relevant to your workflow.
If there’s any way to bring it back to that function? It would make so much more sense. Thanks!
Keep in mind that €200 still isn’t very much money. Ultimately a lot of this work isn’t getting done because it’s just really hard to do. In the case of that Klipper feature for example, it is very much not trivial; doing it properly requires first re-architecting the entire problematic world of input methods first. That’s not a €200 project, it’s at least a €50,000 project.
I’m not a programmer, but in my view it is a trivial fix, just make an option “paste on selection”, as Windows and other clipboards do.
Now in KDE I have to:
Press Meta-V to open the clipboard history dialog
Select the desired history entrance
Manually press CTRL-V.
In Windows there is no 3 step needed, it automatically pastes on selection. And as I do a lot of CTRL-C/CTRL-V every day for managing products in my e-shop, it is a critical issue for me.
For now I have to use Windows, as my workflow is just faster there.
With all due respect, you only think it’s a trivial fix because you’re not a programmer. Anything you don’t know how to do looks easy. But if this was trivial to fix, someone (possibly even me) would have done it already.
Discover once again allows you to update update-able add-ons acquired using the “Get New [thing]” windows, which had gotten broken in the initial release of Plasma 6.
Sounds nice, but as a developer of a Discover plugin, it’s not at all clear to me how to implement a plugin installer that:
a) Successfully delivers updates.
b) Works on various Linux flavours where Plasma can live.
I am a programmer (albeit I don’t contribute to KDE), so I wanted to shed some light on why this is not actually trivial to fix.
The thing is, to the compositor (in Plasma, that’s KWin), there’s no such thing as a “paste” action. Windows are what listens to keyboard shortcuts such as Ctrl+V (it could be anything else that the window desires, like Ctrl+P), and when they are pressed ask the compositor the content of the clipboard.
Thus, the compositor (and thus Plasma) has no way to just tell the window to paste something. I mean, it kinda does, and it’s called an input method, but those are very complex and kinda broken right now.
It’s a problem that needs to be solved at some point for different reasons, so don’t worry, your auto-paste feature will probably become trivial in the future.
For now, you could maybe bodge something up that would auto-press Ctrl+V for you after you select an entry, assuming the software you are working with uses Ctrl+V for paste, but I don’t know if that’s doable without programming. Perhaps Plasma could include something like that, but as it’s not a proper solution I wouldn’t be surprised if it was not desirable (it already has a lot of hacky and improper solutions gathered over the years, and the developers would probably prefer reducing the amount, rather than adding to it).
So, it is just the Klipper has bad/wrong realization? As I read, other clipboard managers as CopyQ can handle it. I have not tried it out yet, but have put on the list to experiment with.
Basically it’s that Klipper’s architecture was never intentionally designed to do what you (and many others, myself included) want it to do. Changing that requires re-architecting it. Was the original architecture bad or wrong? No, it was fine for what it was designed to do.
What @Grzesiek11 says is exactly right. To do this correctly, we have to make Klipper an input method. But, if we do that, we also have to make it possible for more than one input method being active at once — or else Klipper would have to be your only input method and then you couldn’t simultaneously have a virtual keyboard, type CJK characters, or use any universal autocomplete or emoji insertion features. Clearly that is not ideal. This is something we both need and want to do anyway, and the work is being scoped out. But it hasn’t happened yet.
Because it is planned, and also because it the technically correct approach, it makes sense to focus on that rather than on a shorter-term hacky feature that literally sends Ctrl+V and hopes the receiving app supports it (and that the user hasn’t overridden this globally in the app, or…). That approach would be prone to unfixable edge case bugs.
There are two things that needs to be fixed, and I’m not sure if those are being even reported:
Brightness management with multiple monitors:
Currently, we can only set general brightness per power setting (AC, battery, low battery) and it works well. This changes when another monitor is plugged in and a lot of bugs happen, like:
when monitor plugged in while laptop has lid closed, and then plugging AC, system doesn’t register the power change and laptop’s brightness stays at battery level after lid is opened
secondary monitor is often dimming when laptop is not used for a while (according to general power settings), but then when activity starts, it doesn’t update its brightness as laptop’s monitor does,
brightness levels on secondary monitor cannot be remembered or set, so even if my laptop’s monitor is set as: AC 50%, Battery 30%, my secondary monitor often dims to 9 or 15%. Combined with the issue, that it dims, but doesn’t brightness automatically, cause an irritating problem, when I have to update secondary monitor brightness manually, every time when it gets dimmed. Trying to change the brightness on the monitor itself sometimes changes the basic dimming levels and sometimes isn’t, so this is massively confusing, buggy and not manageable, other than manual changes every time, which gets tiering fast.
#1 is not one issue, but a whole constellation of issues. Brightness control across multiple screens which can be appearing and disappearing dynamically is very complex, and full of edge cases. Folks are slowly working on it.
Sorry to say this but Discover doesn’t show anything at the moment because the main window isn’t opened. This seems to happen in different distro’s also mine which is Universal Blue’s Aurora (Fedora Kinoite in a newer jacket)
It definitely works for me and apparently also for most people, or else the bug tracker would have ten thousand bug reports about it. As such, this is likely a distro-specific packaging issue, a distro-specific integration issue, or a local configuration issue. I’d recommend debugging it a bit to see if you can figure out what’s going wrong.
Anything you don’t know how to do looks easy. But if this was trivial to fix, someone (possibly even me) would have done it already.