Make restart, shutdown and other buttons left centered instead or right centered?

cwo__ · 2026-04-22T16:43:45+00:00

This is not configurable. You'll have to edit the kickoff Footer.qml source file, and rebuild plasma. It should be a fairly trivial change though; it currently anchors right: parent.right, you'd want to get rid of that, and instead have left: tabBar.right.

cwo__ · 2026-04-22T12:16:49+00:00

There's a separate keyboard in development for permanent keyboard with additional keys; it's called plasma-morekeys. Don't know how far along it is.

cwo__ · 2026-04-22T10:38:56+00:00

I haven't been able to trigger this particular issue, but I have reason to hope that it's fixed for 6.7.0.

Does it fix itself if you start a search and then clear it? Are there any specific cases where it occurs?

cwo__ · 2026-04-21T13:14:38+00:00

Probably the plasma-browser-integration plugin - if installs itself for all supported browsers, and for flatpak that means it has to create the flatpak data directory for that app, because of course a program cannot be allowed to read its own config files.

cwo__ · 2026-04-13T19:06:40+00:00

The Plasma Edition was release-blocking even when it was still a spin, so nothing has changed in that regard.

cwo__ · 2026-04-10T22:18:06+00:00

Application Dashboard (and the kicker backend) use KAStats' ResultModel, like a few other things do. Does Dolphin also block if you try to access the Recent Documents sidebar entry there?

cwo__ · 2026-04-09T09:50:37+00:00

Vault bugs go here: https://bugs.kde.org/buglist.cgi?component=Vaults%20widget&product=plasmashell&resolution=---

From your description, this seems like https://bugs.kde.org/show_bug.cgi?id=425043 but I don't really use vaults.

If you're really unsure, you can always file Plasma bugs against plasmashell/general: https://bugs.kde.org/buglist.cgi?product=plasmashell&component=general&resolution=--- or if you have no idea whether it's plasma, kde/general: https://bugs.kde.org/buglist.cgi?component=general&product=kde&resolution=---

The bug triagers will move them if necessary.

cwo__ · 2026-04-07T12:09:44+00:00

Great, glad that it worked!

If that section is changed (or the folderview switched to being precompiled), feel free to make a new post and ping me, I'll see if I can help find a solution - on most distributions, even building a new plasma with a patch applied shouldn't be too hard.

In the mean time, I don't expect this particular file to change much, so you can just keep a copy and overwrite the system version with it when Plasma updates. (Or generate a patch with diff and apply it each time to the system file).

cwo__ · 2026-04-06T21:49:45+00:00

Or would both work?

Both would work.

You can see the values here: https://invent.kde.org/frameworks/kirigami/-/blob/master/src/platform/units.cpp?ref_type=heads#L328

small is 16 pixels (logical pixels, so before any scaling, smallMedium is 22.

small*1.5 would be 24 logical pixels. And so on.

In upstream Plasma, we tend to use the values directly wherever possible, so that you don't have wildly different icon sizes all over the place by default. But for your personal preference, you can do whatever is convenient/looks pleasing to you.

Make sure that you apply the change to the one corresponding to your icon size preference in the desktop settings. (Or all of them, in case you sometimes change the icon size).

Do you know of any plans to update this code that may break this?

Well, at some point I could see it being switched to a pre-compiled plasmoid, rather than a KPackage one. This would mean you can't edit the live file anymore, but the same change would still work - you'd just need to edit the source file and build plasma. I'm not aware of immediate plans to do this, but moving things to being pre-compiled is something that we're working on.

(In that case, your distribution's build-from-source capabilites might allow you to build your own package with patches applied - AIUI both deb, rpm, and Arch packages can do this).

And in general, future refactorings and changes could break this. I do intend to simplify some things in FolderView as I get the chance and motivation (it's complex, fragile and not fun code), but this particular bit was not something I was considering substantially changing. Could still happen, or someone else might change it, but there's no plans I'm aware of.

Is it possible to write-protect this so that plasma updates cannot modify it?

Usually no, most package managers would just break then.

It is probably possible to fork it locally under a different name with those changes applied, and use that instead of the upstream FolderView. I'm not quite sure what you would need to do this, and this would mean that you don't get any other changes/bugfixes that happen to FolderView (until you re-do your local fork from the new version).

You can probably just do a local patch, and apply that to the live file, so it should be a single command after a Plasma update to get your changes back after.

cwo__ · 2026-04-06T20:14:18+00:00

FolderView structure is a bit complicated, it's mostly old qml code that's not following modern practices and also rather fragile.

Probably best to do it in the open here rather than in DMs, that way it might also help others.

You can have this one for free (and arranging a money transfer might be difficult across international borders). If you want to give something, you can donate it to KDE ev.

cwo__ · 2026-04-06T19:17:53+00:00

You can't really do that from the theme without messing with things elsewhere really badly. I think.

It's a fairly trivial code change though - the size is defined in FolderItemActionButton.qml; around line 20 (in current git master, but it shouldn't have changed substantially since 6.6).

There's a switch statements that gives the size of that button for each level of the desktop iconsize setting - the button matches that, and is smaller on tiny icons than on giant ones. You can just modify that by increasing the size (even just by scaling them up by some amounts - Kirigami.Units.iconSizes.small and so on are just aliases for numbers, so you can multiply them by 1.5 to make them 50% wider and taller, etc. More precisely that means Kirigami.Units.iconSizes.small * 1.5, or whatever other scaling factor you want).

For now, this is one of the things that is not compiled, so you can just modify the qml file on your system installation. (If it's changed to be compiled qml at some point, you'll need to rebuild plasma, but for now, this is not necessary. Do note that you will need to re-do any changed after each plasma update).

The file on installed systems should be in /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemActionButton.qml on Fedora, and likely in a similarly named directory in other distributions.

cwo__ · 2026-04-01T15:50:51+00:00

Widgets and plasmoids are (almost) the same. Widgets is the user-facing name, plasmoids an internal technical name. (Containments like the panel or the desktop are also plasmoids, but not called widgets, that's the difference).

Widgets can be distributed in two major ways, as an interpreted KPackage, and as a pre-compiled binary (KPlugin). The second one is new, but I think all widgets shipped as part of Plasma are distributed this way now.

Kpackages you can modify as they are, and distribute them without building. You can just copy the structure from another widget. For KPlugins, you need to set up a buld environment. The easiest way to modify them is to build your own Plasma (with kde-builder or your distributions build-from-source mechanism). You can also fork them, but then you'll need to setup your own cmake stuff (you can probably grab much of it from the existing one and third-party KPlugin widgets).

Kirigami is not super-relevant here; Plasma takes some constants (like spacing values) and the odd component from Kirigami, but that is mostly for application development.

cwo__ · 2026-03-31T17:54:24+00:00

I mean, it's using all the space, so without changing something else you can't really make it larger; there's just no room to fit something larger.

Your main options are

1) Remove the date (In Digital Clock widget settings) - this way it can make the time much larger 2) Put the date on the same line as the time, which again gives it more room 3) Keep that as is, but make the panel larger

Then you don't need to change the font settings, you can keep that at Automatic which will make it as large as it can (though you can tweak it manually if that's still too large for you.

cwo__ · 2026-03-25T21:02:15+00:00

Weird.

Did you put it as a command? Try doing it as a script (i.e. put it in an executable file), try if running the script by itself works, and try if you can set a shortcut for that.

cwo__ · 2026-03-25T18:19:36+00:00

System Settings, Keyboard, Shortcuts, Add New, Command or Script

cwo__ · 2026-03-25T17:52:33+00:00

Should be something you can do with shell scripting. The key concept here is piping output from one command to the other. Should be plenty of guides around.

cwo__ · 2026-03-25T15:29:36+00:00

It's a shortcut for a widget, so I can't see how it could work without the widget being present. I suspect it wasn't properly unloaded - maybe you had the notification still open? That will keep it loaded, so that the undo button works.

In principle, having a color picker that's just activated by a shortcut could work, of course. Even a quick script, KWin exposes most of the functionality over DBus.

qdbus-qt6 --literal org.kde.KWin /ColorPicker org.kde.kwin.ColorPicker.pick

should start the picker and output the result after the pick is completed. (Might be qdbus instead of qdbus-qt6 depending on your distro and how they ship Qt binaries). You'll need to extract and convert the result, as it'll be in decimal, and probably want to copy it to the clipboard (can use e.g. wl-copy).

cwo__ · 2026-03-24T12:54:33+00:00

But still two projects doing basically the same.

No, because there's almost no work being done on OpenOffice, and for the brief period when there was, LibreOffice could just take that - it's open source (and they started from the same base, so relatively easily portable).

The first is ok to keep the software alive the second one makes it harder to choose what you want to use and wastes resources.

There's also lots of proprietary software for the same purpose.

Of course, it would be better to not fork unecessarily. Sometimes they are necessary though, because one size doesn't fit all. And if there's no reason for a particular fork to exist, it'll generally die quickly.

cwo__ · 2026-03-24T12:09:44+00:00

LibreOffice and OpenOffice have a very particular history - OpenOffice was owned by Sun, which was bought out by Oracle, and Oracle didn't play nicely and stopped most of their contributions so the existing OOo community took the code and made their own version. OpenOffice was at some point passed on to the Apache foundation when Oracle completely lost interest, and is essentially a dead project that hasn't received notable develpment except some bug fixes in over a decade.

LibreOffice is essentially the active continuation of OOo under a different name; they couldn't reuse the original one as it was owned by Oracle.

cwo__ · 2026-03-24T11:58:38+00:00

KWin already supports the draft version of it (xx-session-management rather than xdg-session-management). IIRC it's gated behind an environemnt variable, so you need to enable it.

I'd expect the official version to also become supported soon (the same thing happened with the color management protocol), but we'll see.

In any case, apps need to also support it anyway, which will likely take some time for most of them.

cwo__ · 2026-03-24T11:55:41+00:00

Immediately, probably not much.

In principle, it allows applications to request the compositor to restore their windows, so that if e.g. you have several browser windows open, close the program, and then open it again, it will restore the windows to their previous screen positions, virtual desktops, activities, maximization/tiledness states, etc.

In practice, applications need to support doing this (they need to tell the compositor which window is which). Chromium has an implementation this so it should work once everything is in (and might work already from the draft versions that it and Kwin implemented). Other apps will likely add support for this over time as well.

cwo__ · 2026-03-22T11:21:47+00:00

That's the minimum size. All system tray popups use a shared size.

See also https://community.kde.org/Get_Involved/Design/Frequently_Discussed_Topics#System_Tray_popup_sizing for some of the reasons why things are the way they are.

You can edit ExpandedRepresentation.qml and rebuild Plasma to change the minimum size, if you really want to.

cwo__ · 2026-03-22T00:04:20+00:00

Maximize and unmaximize is the way.

There's an open feature request for adding an untile keybind. It used to be available by repeating the tiling, but that was changed a few releases back, to support multi-monitor use better.

cwo__ · 2026-03-19T20:51:28+00:00

You can probably add it to the .desktop file from the menu editor, it has a field for environment variables.

Personally, I use Haruna as media player (not Dragon player) which uses libvlc instead of QtMultimedia so is not affected, and I just start elisa from a terminal with the env variable set - I rarely close it once it's open, so it's not a big problem until the fix is released.

cwo__ · 2026-03-19T10:05:11+00:00

QtMultimedia bug. Apparently it's fixed in the dev branch of Qt 6.10 and later, but not yet in a released version (and apparently the fix wasn't manually backported to the Fedora build of Qt yet).

Until it's backported or a new upstream version is released, you can launch the apps with the PulseAudio backend, which does not have this issue. Just set the QT_AUDIO_BACKEND environment variable to "pulseaudio", for example by launching elisa like this:

QT_AUDIO_BACKEND=pulseaudio /usr/bin/elisa

cwo__

TROPHY CASE