Icon Widget Properties

A feature that went missing in the transition from Plasma 4 to Plasma 5 was the ability to configure the icon widget. The upcoming Plasma 5.9 release is where this dialog will finally make its entry into the 5.x series.

Icon widget properties dialog

The reason it has taken so long was the way the widget used to work was quite complicated. I tried to bring it back for virtually every feature release since at least 5.5 and scrapped numerous patches before I finally found a solution.

The dialog itself is provided by KIO and has been around for ages, so why was it so hard? The old widget had various codepaths for whether the file is on a local or remote location, is writable by the user, is an application, and so on, and did most of that only on-demand when you actually wanted to edit the widget for the first time.

For example, when you drag and drop Kate from the launcher to your desktop, it will see that it has a backing .desktop file and extract information from there. However, since it’s installed in a system location, you cannot just modify the .desktop file. If you opened the edit dialog, it copied the .desktop file to a location in the user’s home and let it edit that one. If you then canceled the dialog without changing anything, the file was deleted again. And this logic was just one of many – I had a really hard time wrapping my head around this.

Firefox disguised as Anjuta

The revamped applet on the other hand always generates a .desktop file and places it in ~/.local/share/plasma_icons massively simplifying the logic for editing. I can just throw a KPropertiesDialog at it and call it a day.

The mapping heuristics are executed just once on applet applet creation where the applet inspects the URL in its config and generates a .desktop file as needed. For applications (e.g. drag and drop Kate from Kickoff to your desktop), the file is copied to this location verbatim. However, in case the “run_desktop_file” Kiosk restriction is enabled, which disallows running applications from .desktop files outside of system locations, the original file is referenced instead. This way you can still place icon widgets in e.g. corporate environments whilst keeping your users from messing them up.

For any other kind of file, a “Link” desktop file is created – that’s the one you’ll get when you do New → Link to URL in Dolphin. The applet will restore its backing .desktop file as needed, migration from the current applet to its new implementation will work seamlessly – of course the applet will delete its .desktop file when it gets removed.

Sneak peek of what’s to come in the future ;)

If you enjoy my work on KDE software and want to support us, please consider donating to our Make the World a Better Place! – KDE End of Year 2016 Fundraising campaign!

6 thoughts on “Icon Widget Properties”

    1. I don’t fully understand. Also, this would probably be the wrong layer to do this.

      All I basically do is QIcon::fromTheme(KDesktopFile(m_pathToDesktopFile).readIcon()); – the actual parsing/processing logic is deeper in the stack.

  1. Great work! Can’t wait for the “Sneak peek of what’s to come in the future ;)” feature :-)! Will it also display album art?

Leave a Reply

Your email address will not be published.