This week in Usability & Productivity, part 45

Let’s have a bit more Usability & Productivity, shall we? The KDE Applications 18.12 release is right around the corner, and we got a lot of great improvements to some core KDE apps–some for that upcoming release, and some for the next one. And lots of other things too, of course!

New Features


UI Polish & Improvement

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

32 thoughts on “This week in Usability & Productivity, part 45

  1. Hi ! Yet another superb week ! A few remarks 🙂

    1. About “When you change the titlebar font size in such a manner that it will cause the titlebar to become taller, that size now change takes place immediately rather than after a reboot (Vlad Zagorodniy, KDE Plasma 5.15.0)”
    -> actually I filed this bug because I noticed the windows decoration got absolutely HUGE when switching the font to Roboto 11 then rebooting.
    Apparently, now, with this fiix, the titlebar thickness should increase as soon as I change the decoration, but I guess it’ll still be huge. Shall I file a new report for this one ? (also the titlebar thickness options kinda seemed they made very little to no difference) I noticed other fonts related stuff — like text being blurry here & there when using Cantarell 11…

    2. About the possiblity to assign tags and browse them directly from Dolphin, this is absolutely great. This raises several questions for me :
    2a) tags will be kept in the Baloo database. Which means, tags will be lost 2a1: if for some reasons you have to reset the database (which I do once in a while due to some bugs like CPU usage loops) 2a2 : if for some reasons I have to reinstall the whole OS or stumble upon a bug… Or change my machine. 2a3. Or if like mean you rsync files between several machines.
    2b) which means it’ll be risky to invest a lot of time tagging stuff that will eventually disappear !
    2c) What about files that natively support tags like MP3s, or pictures ?
    2d) for instance you can set ratings in Elisa which makes use of Baloo. But MP3 files also have an ID3 tag for ratings. Could they be synchronized ?
    2e) could the user assign a colour to a given tag so that they appear like “pins” “bubbles” over the icons ? Would be awesome for tags like “important” “in progress” etc.

    Awesome work, cannot wait 😉 Cheers !


    1. Replying partly to myself :

      maybe the tagging features is not meant for archiving / long-term information gathering purposes, but for short-term workflow-improving temporary work ?


    2. Regarding the first item, no, you don’t have to file a new bug report. The height of the titlebar depends on the current window title font (at least, that’s the case with Breeze and Oxygen decoration theme). If the font size gets bigger, then the titlebar will be bigger. So, it works as intended.


    3. Hi Vlad ! Well, I really thought the decoration was too thicke, as I was “shocked” when it first appeared, see with Roboto 11
      So that must be a combination of the font metrics & the decoration theme… Or maybe that’s subjective ?


    4. Yes, the KDecoration library uses the font metrics to derive grid units, which are then used by Breeze and Oxygen decoration theme.


    5. Tags are actually stored as extended attributes on the files themselves, so they should be portable.

      Synchronizing tags between files’ native tagging capabilities and the xattr tags is something that’s being actively worked on, but the Elisa guys I believe.

      Color tags are also desirable and we have various people coming up with a plan for that. Follow

      Liked by 1 person

    6. Right. macOS makes extensive uses of extended attributes and what they did there was to patch all the command-line tools (cp, mv, rsync, etc) to default to using the options that preserve xattrs; you need to explicitly turn them off instead.

      IMHO this behavior makes sense as a default and I wish upstream software just did it. But I think it would be reasonable for KDE-focused distros to do it themselves.


    7. Hmm, even modifying a file for instance in LibreOffice makes it lose the attributes actually, I’ve noticed. Would we have to patch every single app that saves files or are there some low level libraries which could be involved ?


    8. This is because LibreOffice performs “atomic saves”, where it makes a copy of the old file and overwrites it. If all the system tools were patches to preserve xattrs by default, this would probably get fixed automatically. Without that, you’ll need to file a bug report against LibreOffice itself saying that xattrs need to be preserved when performing atomic saves.

      Not all apps perform atomic saves, and all KDE software should properly because it uses KIO for this.


    9. Hi Nate, thanks for replying. I’m sure you’ve already answered the same questions several times… I’ll probably open a bugreport in the Libo tracker, then.


    10. Tags are *not* stored in baloo, merely cached. Tags are permanently stored in file XAttr. When you delete the baloo index, it has to retrieve the tags again from the filesystem, so it may take some time until the tagged files show up in searches, but eventually they will.
      Metadata from e.g. photos and music are also fetched from the files, and again preprocessed and cached in the baloo index, for fast searching.
      When you update file metadata, like from Elisa, the changes will be stored in the file and picked up by baloo.


  2. Awesome as always! 🙂
    It reminded me, is this issue already reported? In ksysguard search box has a gray background and that annoys me every time I use it (pretty often) as it doesn’t look like an input field (which should be white). Also, the grayed out text on gray area suggests as if it was not clickable, a not interactive area which is misleading and it feels very wrong each time I use it. It’s not consequent with general UI rules.


  3. Liking the dolphin changes. However I’d like the option to use ctrl+L to toggle out path editing mode. I’ll elaborate:
    When one taps ctrl+l one is led to the current folder path and we can edit it, but if we tap ctrl+l again, it doesn’t switch out of this mode.

    Also, I’d like to know if there’s some way to get full name fo files like in nautilus? too long of a filename will understandably will truncated, but the name would show fully if a file was selected on nautilus, but not here, I tried to look for any options that would affect this but couldn’t find anything. Having some way to set font size for filenames would be good too, because even when zooming up and having less files (so each file has a bigger field) the size of the font increases with it so we can’t see any more of the file name anyhow.

    Lastly, I don’t know if this would fall under dolphin but when we copy a file’s path and try to paste it to a program that uses kde dialogue and is looking for a file, the operation will fail saying that the dialogue was expecting a “folder” even though the program that spawned the dialogue is looking for a file. So if I have ‘/home/foo/music/we.opus’ and paste that path, the dialogue won’t take it, and I’ll have to give it ‘/home/foo/music/’ instead and then manually select ‘we.opus’.


    1. 1. Not a bad idea!

      2. Settings/Control > Configure Dolphin > View Modes > Maximum lines > Set to “Unlimited” (this it the default setting, in fact; maybe you or your distro set it to something else at some point?)

      3. If you have a path that includes the filename of the file you want to open, you have to paste it into the filename field on the bottom, not the path bar on top.


    2. Regarding the patch, it doesn’t seem to be very popular so far, so you might want to chime in with a comment if you like the idea of it.


    3. There is no need for you to do this. Why would you add double function to ctrl+l when you have ESC?
      I really don’t get it. The option is there, but people have forgotten the use of a dedicated button on their keyboards. ESC exists for these kind of reasons.


    4. I see the option now, it’s odd, as I don’t think arch meddles with upstream, however this isn’t quite what I wanted as I end up with a lot of white space, I’m guessing what I asked isn’t an option on dolphin (showing untruncated filename of the selected file).

      Though this concerns me with gwenview, as I understand they wanted to integrate dolphin’s file viewer onto gwenview and possibly other kde applications, and currently gwenview sort of has this functionality (it is on mouse hover rather than file selection) and I’m guessing this will be gone when this merge happens.

      Thank you very much for the patch.


    5. Oh I see what you want now: the ability to see the full filename on hover when not using the “Unlimited” setting. Yeah, Dolphin doesn’t have that yet.

      Dolphin and Gwenview currently use different code to display their icons. We’d like to merge all of these different things into one widget that can do everything, but don’t worry, when we do so we’ll take care not to lose any features; in fact the merge should result in Dolphin, Gwenview, Folder View, and the open/save dialogs each gaining the superset of all the features available in the others.

      Regarding the patch, it doesn’t seem to be very popular so far, so you might want to chime in with a comment describing how it would benefit you.


  4. Nice improvements, great work.

    One thing that annoys me is the dictionary plasmoid icon, its using a broken version of the oxygen icon.


  5. As always, a fantastic job.

    For me there is nothing that compares to KDE and every day you make KDE get better and better.

    The only thing I and some friends that I “converted” to KDE, is the absence of a widget to switch the processor frequency, as well as the gnome (governor frequency control).

    This would greatly help the gaming experience and would make it easier for people who do not have much technical knowledge to change these parameters on the console.

    Thank you for the great work you are doing in KDE!


    1. Yes, I’ve heard this before. I’m not sure whether or not those kind of system settings can be manipulated by a widget, but if they can, then writing one such widget should be pretty simple for someone with the know-how.


Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s