KDE Usability & Productivity: Week 87

Usability & Productivity 3 Minutes

This is the last week in KDE’s Usability & Productivity initiative (next week the blog posts will continue, but under a new name). The voting results are in for KDE’s new goals and the community-selected winners are full Wayland support, consistency throughout the KDE ecosystem and software, and a renewed focus on KDE apps. Read all about it here!

But meanwhile, there’s a ton of stuff to announce right now, so let’s jump right in.

Serendipitously enough, something big landed this week that’s relevant to the first new goal: fractional scaling on Wayland!!!

Check out the complicated dependency tree of patches that were required to make this happen:

Veteran KWin developers Roman Gilg and David Edmundson have been working on this for ages, and all of their hard work–which will land in Plasma 5.17–is much appreciated. But wait, there’s more!

New Features

Bugfixes & Performance Improvements

User Interface Improvements

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 https://community.kde.org/Get_Involved, 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 you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

Published by Nate

Published

30 thoughts on “KDE Usability & Productivity: Week 87”

  2. Very, very awesome! I’m speechless at how much progress has been made for plasma 5.17! I simply cannot wait for 5.18 and what might be in store for it.

    Like

    Reply

    1. Me too. It promises to be a very exciting release. I’ve been using it already (by compiling everything from source) and it is so stable and smooth. There have been so many bugfixes, quality-of-life improvements, and new features!

      Like

    2. Unfortunately for me, plasma has multiple Wayland issues still with AMD graphics chips (vega 8 on Ryzen 3500U and RX 500 series cards, both using AMDGPU). One issue is with steam loosing focus when clicking on stuff in it’s UI, and the other is the library not showing up at all even though the tray indicator is there. Then there’s firefox, spotify, and discord which often have issue with loosing focus when right-clicking and pasting or copying stuff, or just opening new tabs by clicking links. Firefox with native wayland enabled is just a mess of artifacting and bugginess, probably because of the lack of subsurface support right now (which might be the cause for alot of the other stuff too?).

      I also get occasional artifacting like a flash of green on resize (i kinda like this though… call me weird), or even entire plasma shell crashes rarely (used to be more frequent, but it’s gotten alot better over time). Spectacle still requires that click-to-confirm screenshot which breaks taking game screenshots.

      If you guy’s manage to fix this stuff with this new initiative I’d be damn impressed, as they’ve been bothering me for over two years now. I really envy you being able to comfortably use Wayland too!

      Like

  4. All of you good people working on KDE are amazing! Version 5.17 is looking to be a game-changing beast of a release, it surely will attract more and more users to KDE and linux. Much needed too, since the big boys and gals at Redmond have completely lost their marbles and keep releasing potato after potato.. KDE boys and gals, I can’t thank you enough, computers are fun and personal again.

    Liked by 1 person

    Reply

    1. I feel the same way–especially about computers being fun and personal again. That’s a big part of why I love doing this. It feels like the fun old days again–before everything became corporate and the industry started to think that unleashing monetized AIs on our personal data was a good idea.

      Liked by 1 person

    1. Well, people can still contribute to them even if it’s not the main initiative. On reddit a kde developer already mentioned they have some work being done for one of the other initiatives. I imagine in the future once the Wayland initiative is over, they’ll have another vote and look through old proposals too.

      Liked by 1 person

  6. Nice week again. I’m pretty happy to see what the new KDE Community goals are, i voted for the full Wayland support (really needed IMHO) at the Phabricator, i can’t wait to read about that here at your blog Nate :).

    Of course, nice improvements. I’ll be filing a new bug about Spectacle, cause in Wayland session isn’t doing the screenshot first and later showing the screenshot with the Spectacle traditional window (as it does under Xorg session), instead of that, it shows an Spectacle little tooltip at the top-left edge of the screen, indicating that you must click or press enter key to do the traditional screenshot, even if you have selected and wanna do a rectangular selection, so it’s kinda frustrating and time loosing.

    Apart from that, i’m really full of joy to see that Spectacle is getting better under Wayland, that Plasma 5.17 is really improving a lot and that we’ll be having a really nice release in about one month, so really close to it. I can’t wait.

    As always, i would like to express my huge gratitude to the KDE Community who makes all this amazing software possible to let us enjoy our devices, PCs, smartphones (with the futuristic KDE Plasma Mobile, which is really promising and looking better and better with the past of the time and the lots of effort the community is putting on it), etc. And of course, special thanks and apart mention to Nate, who lead this sun-setting initiative, but for our joy, he’ll be continuing to give us our weekly KDE Community work and development ration, keeping us up to date of what’s happening under the hoods, so we don’t have to worry.

    An immense hug to everyone mentioned above ^^.

    KDE rocks!!

    Liked by 1 person

    Reply

    1. If your interested i posted more details above about my personal troubles in Wayland in a reply to nate that i hope get fixed. Anyways, the click-to-confirm screenshot in spectacle on Wayland isn’t actually a bug, it’s a intended feature added so that nobody can maliciously take a screenshot on you. In my opinion however, and in nates too according the phabricator thread about it, it’s better to sacrifice security (which is mostly just a theater anyways) in order to ensure the user gets the best possible experience.

      I bet Linus Torvalds would agree.

      Thread for reference: https://phabricator.kde.org/D22209

      Liked by 1 person

  7. I know that Plasma will keep improving the little details, but I’ll miss coming here every week to read these posts and always findings a little thing that I wanted polished (like the search button on Dolphin in this case).

    Good job everyone.

    Liked by 1 person

    Reply

    1. The future of KWallet is currently under discussion again with regards to the Qt 6 transition in a few years. I’m also hopinf it can be modernized or replaced with something better so that issues like those can be fixed.

      Like

    3. At the moment I believe it’s being held in person at Akademy, but I expect some Phab tasks or mailing list threads to show up soon.

      Like

    4. How about replacing with KeePassXC? It’s a pretty advanced software and regularly gets updates, I think it’s the perfect tool for replacing KWallet.

      Like

  10. «full Wayland support, UI consistency, and a renewed focus on KDE apps»

    Finally Wayland’s implementation on KDE will be taken seriously after about 12 years of Wayland’s release. Alleluia! Now if MTP support follows the same path, millions of KDE users will be blissfully happy… xD

    Ok, now seriously, :P, who composes that “community” that selected those winners? There are some mentions to it in the link you provided, but all mentions are very inespecific. The image I get is that 3 or 4 folks proposed some ideas and somebody, I don’t know who, voted for them.
    Who voted? Who compose that “community” and how can one participate and vote to future proposals? Can only those folks in the photos propose things or also users can?

    Having an technical “aristocracy” in a project like KDE is a good thing as long as it is limited to technical decisions. The developers are the ones who know how to code, design software solutions “mechanisms”, “structures” and all that technical stuff. That’s perfectly right. But usually, users, experienced and power users, I mean, and professionals who use software for real work every day know better than developers the real necessities “out there”. I don’t mean that a developer’s work isnt real work, of course it is, but is very narrowly limited to the specific task of developing software, whereas most of the uses of computers are away from that: office, design, business, multimedia, even just general domestic usage in a family which various habits depending of its members. Those users -and I emphasize the importance of experienced and professionals ones, not just a newbies who think they have the best ideas ever thought but don’t even know how to use the software- are better entitled than developers to suggest some ideas and make many intelligent proposals for “the real world” -i.e.: Who decided that monochromatic icons are a good idea? Was nature wrong when she gave us the hability to distinguish colors?-.

    So, I think that community should be democratic -“qualified democracy”, not “universal suffrage”- when it comes to make proposals about goals and vote them, and keep being “aristicratic” for everything related to development and technical decisions. This is especially important when many of us are donating our money to see how the decisions are taken without considering our point of view. I know that donating is not exactly “paying” nor buying, but ignoring experienced users opinions makes me less eager to increase my donation next time or even keeping doing them in the future.

    Like

    Reply

    1. P.S: I like a lot many of the KDE apps, but I agree with the need to discard redundant apps like some multimedia players. But there’s one nobody mentions -or I haven’t seen it so far-: why do we have two image viewers, Gwenview and Showfoto?
      I know Gwenview is just a “gallery app” with 5 or 6 edit funtions and a lot of services to export to. Showfoto is a basic viewer with 3 or 4 dozen -haven’t counted them, to be sincere- edit functions which half could be removed because nobody is going to use a basic app for doing advanced things like image stacking, color management, local contrast, and half of the features Showfoto does very basic and coarsely. Those are photo retouching and development functions that average users won’t ever use, and that programs like Darktable, RawTherapee, Hugin or even Krita and Gimp do much better -and users who need them know it-.

      OTH, Gwenview isn’t able to open all image file formats nor very large heavy files. Showfoto opens everything -well, I guess that not *everything*, but almost-, even half a giga compressed TIFFs, but is way too basic for serious image edition, as I told before -there are apps for mobile devices with more features and better algorithms-, and also has funcions that exceed the ambit of a photo retouching program, like presentation view or the same lot of services to export to that Gwenwiev has.
      Well, why not “purify” Showfoto and fuse it with GV? We would finally have a single “all purpose” gallery app with support for almost every bitmap file format, and with nice basic edit features taken from SF, more than the very scarce ones that GW provides but many less than SF does, like brightness/contrast, saturation, luminosity, sharpen, noise reduction and not much more.

      Like

    2. I generally agree that it’s better for a community or vendor not to have multiple apps that target the same users or use cases (these users would be better served by a single polished app with more developers). However you don’t just merge apps. That’s like saying you should merge two buildings into one; it just doesn’t work that way. Rather, what happens is that one app gets abandoned and its developers either work to port the missing functionality into the other app, or they get demotivated and just stop contributing entirely, which is a shame.

      In order to standardize on one app, what generally needs to happen is that it becomes seen as the frontrunner and attracts developers organically until nobody really feels like working on competing offerings because the frontrunner is seen as good enough. For example this is why KDE has only one screenshot app now–Spectacle is seen as good enough so people work on it instead of creating or resurrecting an alternative. But you don’t force this or decree it–especially not in a non-hierarchical voluntary community like KDE.

      I’d also like to see Gwenview become the default, go-to image viewer app, which is why I develop for it (not enough, really). If you want to see that happen as well, start hacking on Gwenview and sending patches, and encourage your friends to start doing it, too!

      Like

    3. Sorry for the delay. I wasn’t expecting a response from you. Thanks for taking your time. 🙂

      «That’s like saying you should merge two buildings into one; it just doesn’t work that way…»

      I know things aren’t that easy. I was speaking in a very general manner. I know too that the members of a voluntary project cannot be forced to do anything they dont want, but a big project like KDE has some guidelines and gals, it doesn’t run from here to there like a headless chicken. One of those guidelines should -I believe- be avoiding duplicate efforts and work, and trying to unify the always scarce manpower you have as much as possible. Optimization of resources and goals, like that new focus on KDE apps you mention in the article. That’s why I think that the KDE people should talk to, say, Gwenview and Showfoto developers and try to make them work together in a single and better app.
      And of course KDE can ignore and not give any support to redundant apps that want to follow their own way, a respectable position but not necessarily bweneficial for the KDE echosystem and its users. Social usefulness is an important criterion too, I think.
      Obviously, other people will keep writing their redundant apps, the Nth media player that doesnt contribute anything different, interesting, better…, the Nth raw photo developer or the Nth icon theme. It’s ok, it’s their time and they spend it as they want, but they could be invited to join the KDE apps team and work in “making KDE echosystem greater”, and if they still prefer to write another app that does the same than an already written KDE app, should’ t be benefited by the “umbrella” of KDE, IMHO. Or, in case the others’ app is better than KDE’s, fork it or “adopt” it and quit wasting developers in inferior apps just because they are “made at home”.

      > For example this is why KDE has only one screenshot app now–Spectacle is seen as good enough…

      Great example. We have the official screenshot tool and then theres a more feature rich tool called Flameshot, which has soem functions that may probably not interest much people, but some others I think that are interesting for every one, like the tool to blur areas of the screenshot, great if you are sharing screenshots with user names or other personal info; the tool to draw lines and basic forms, cool to remarking a zone in the image… Well, have you, people at KDE, tried to approach Flameshot developers and invite them to join you to improve Spectacle? Or, couldn’t the source code be “copied&pasted” into spectacle -again, I’m speaking in a very general and superficial way, I suppose things are not that easy like copyng and pasting piece of text into a different text document-, or what about even ditch Spectacle and just “kdeize” Flameshot?
      These kind of things would not guarantee that every developer of redundant apps would join you, of course, but maybe a few of the would. And taking into account how small are the development teams in FLOSS, it wouldnt be a negigible thing.

      > If you want to see that happen as well, start hacking…

      You, developers -here’s an example of why the KDE community should be more diverse- should try to quit thinking that every Linux user is a programmer, informatics student or TI professional. I’m an allergologist, my mother -yes, my sixty-something y. o. mother uses Linux- is a hispanic literature teacher. I read a lot about my field and general medical and biological articles, and also have a life, a family and a few hobbies. I sincerely don’t have the time nor the interest to learn programming software. I like using computers for my continuous education, recycling of knowledge, and also for my own leisure, but I don’t like to lose several hours every week in technical matters. Most of the computer users in the world are more like me than to you, techies. That’s why I contribute donating some money to a few projects I use every day -like KDE, Nextcloud, DavDroid, and some more-. Few years ago I also contributed reporting bugs, but I got a bit disappointed, and also I had my first daughter so my spare time began to shrink progressively :/. Nowadays, donating Is the only thing I can do, without abandoning my current life and becoming a geek -said with all the due respect-.

      BTW, another suggestion: Would be nice to be able to donate “bounties”. Instead of giving an amount a year for no specific purpose, one could donate that money to, let’s say, add the option to personalize each folder’s background in Dolphin -I feature I miss from Windows XP-, which is especially useful when splitting the view and have several tabs so you don’t get confused and delete the file from the wrong directory. If 10, 12, whatver people would agree in the same goal, their donations could be added and used to pay developers to dedicate x hours to work in such feature.

      Kind regards, and don’t feel obliged to answer. I just would like some of mi ideas to be considered, but I know you do a lot o things in KDE and don’t have much free time either.

      Like

    4. The pool of eligible voters consisted of everyone with a developer account (2646 people, see https://websvn.kde.org/trunk/kde-common/accounts?view=markup) as well as everyone subscribed to the kde-community mailing list (I don’t know the number of subscribers).

      My preference would have been for a wider audience and better ahead-of-time announcement of who was going to be eligible to vote, and I think we can improve the messaging here for the next go-around in 2021. But it’s hardly some elite cabal of insiders. KDE is the opposite of a technical aristocracy! 🙂 It’s a hugely anarchic community where the decision makers are basically the ones who show up, with no restrictions or gates or litmus tests or anything to get in the way. In this way, it’s exactly like a democracy, where the people who make change happen are the ones who participate by running for office, joining campaigns as volunteers, organizing political events, protesting, petitioning the local government, etc.

      I don’t see any evidence that KDE ignores users’ views. For example, you are a user and your viewpoint is being listened to right now! 🙂 However being listened to isn’t the same thing as getting your way. By way of illustration, I’m a KDE developer with a fairly high profile in the community and I make plenty of noise but quite often don’t get my preferred outcome. This is normal in any large project that involves people with diverse viewpoints. The price of scale is compromise and slow speed of change. It’s just one of those iron laws of human endeavors.

      Like

    5. «The pool of eligible voters consisted of everyone with a developer account…»

      :-/

      «… as well as everyone subscribed to the kde-community mailing list…»

      Oh, nice. Didnt know that. I’ll see if I could join that mailing list. Thanks for the info.

      «… where the people who make change happen are the ones who participate…»

      Hmm. But there are “project leaders” who accept or reject proposals patches, fixes, etc. Thus those “leaders” are more “powerful” than the rest. So there’s indeed an aristocracy: if you participate in the development, you have more or less “power” in approving or rejecting proposals; if you are a common user, even if a regular contributor with bug reports, suggestions, donations, whatever, you are of a lower “caste”.

      «For example, you are a user and your viewpoint is being listened to right now»

      But that’s because you are such a nice guy :). I used to participate in the formerly active KDE forum and in bugs.kde.org and had a few arguments with some developers which in many occasions would ignore me totally or even would be despotic and disrespectful.
      Being kindly listened and replied in a blog is nice, but I meant real voice and vote for experienced users in matters not related with technicalities.

      Anyway, I’ll try to join that mailing list and expose there my thoughts. I know that I won’t get my preferred outcome almost never, but having the opportunity to be listener in a wider and more influential “forum” would be a great improvement.

      Many thanks for your time, your kind explanations and of course the work you do in KDE as a developer and asa “divulgator” -if such a word exists in english, I suppose it probably doesn’t xD-.

      Like

    6. So there’s indeed an aristocracy: if you participate in the development

      I think you are confusing aristocracy and meritocracy. 🙂 The “project leaders” (or maintainers) are nor chosen by birth, or wealth, or force, or government fiat–as with an aristocry. They are chosen by their peers on the basis of their meritorious contributions. Other developers agree to abide by their decisions not because they have the power to punish transgression, but because their wisdom and opinions are valued and friendly cooperation is important in this community.

      This is not to say that all maintainers or even developers have the same level of social skills. A few may be rude or downright abrasive. But those people who abuse this trust by acting antisocial, making bad decisions, not listening to the community, or standing in the way of change that large numbers of users are clamoring for generally lose their power and people start ignoring them. Humility is important. We can’t forget who we’re doing this for: you!

      But humility isn’t only important for developers; users need it too. If you ask for a change or a feature and the answer is “no”, maybe it genuinely wasn’t a good idea, or maybe it wasn’t technically implementable, or maybe nobody had time to do it, or maybe it didn’t fit with the software’s goal (this is one of the reasons why there are multiple apps in the same category, by the way; apps target different users and use cases). It’s never fun to get told “no”, but it’s a part of life no matter how much power you have. Even the president of the United States, arguably the most powerful person on Earth, gets told no all the time (“No, you can’t buy Greenland,” “No, you can’t nuke hurricanes”). It’s important to deal with it better than he does. 🙂

      Like

    7. > I think you are confusing aristocracy and meritocracy

      I don’t think so. That’s I I’ve always said that it’s logical that technical decisions are taken by the developers. Common users don’t have the merits to do that, you do. I meant that if you are a developer, you become a member of that “aristocracy” (please don’t mind the quotes, I think you have misunderstood me before thinking I was talking of real aristocracy). If you are just a user, you shall always be “of an inferior caste”.
      I don’t think one need any especial merit in writing code to vote if Wayland should be usable finally in Plasma after so many years. Long -and maybe not so long- term users know by experience that Xorg has so many failures, glitches, inefficiencies, security holes, and are perfectly capable to participate in an educated manner in a “referendum” to prioritize its complete implementation among KDE’s goals.

      And please don’t think I was personalizing because I talked about my experience in conversations with some developers. In fact, excepting a few occasions, I can’t complain. Most of my old suggestions in BKO were well received, some were implemented, some others not because they seemed nice but not as much as to interest anyone to work on them; and others, the most ambitious, were rejected because they required too much work for the scarce manpower in KDE. But in general I can’t say I’ve been told that mi ideas weren’t interesting, and when I’ve been, I haven’t made any drama but accepted sportively.
      No, mine is just an anecdote, but there are dozens of cases where users had asked intelligent questions or made intelligent and imaginative proposals, and some leader developer who seemed to believe that KDE was his, has ended saying few less than such ideas were nonsense, even if the user was a professional demanding some improvement in some app that would benefit the app’s usage in real world.
      Yes, humility is something all of us need to keep in mind, but trust me if I say that is very vey likely that a professional court clerk who works every day handling dozens of documents knows better than a document reader’s developer how such an application should work; not technically, I insist: a court clerk isn’t a software engineer, but functionally. The same way that you and me aren’t mechanics but do know that if our car’s steering wheel is too hard and makes difficult to drive safely, that’s wrong and our mechanic may preach to the choir, but our car needs a fix.

      > by the way; apps target different users and use cases

      That’s true, but where’s the limit? There are almost as many different use cases as users. How many media players should be, 300? How many gallery apps, 86? No problem, but let people from outside KDE do them and let KDE shred some good judgement supporting only one official KDE media player, image viewer, etc, IMHO.

      Maybe I’m geting a wrong impression, but sincerely it seels to me -and to several other KDE users. You read this impression in many forums. I’m sure you have too ;)- that developers are, in general, not too open to discuss with users as equals -again, I mean when it comes to functionality, efficacy, functional and aesthetic design, etc. Coding, architecture and other technical matters is “your kingdom”.
      Users need to be humble too, right, but I think that users are by nature way more humble, usually, than developers. I’m in the medicine field, and I notice most of my patients have an almost servile humility. I find some similarities when I read chat groups and forums where participate both users and devs. Look at GitHub’s issue trackers, Telegram channels, etc. Of course there’s a little bit of everything everywhere, but I’d say that, in the vast majority of cases, users show much more humility than developers. My personal impression, maybe I’m wrong, of course.
      The other day I was reading a forum in which one of the most active developers of Darktable complained about developers not paying as much attention as they should to some users’ opinions, many of them professional photographers who earn their salary every day with the photos they develop in Darktable; even their opinions are divergent or even opposed to some devs’ ones. Well, that’s a nice proof of humility from a developer. I don’t see much of that in the KDE area. You are a surprise and a breath of fresh air, seriously. I hope it’s an example of the new generation of developers coming to KDE in the recent years.

      Ok, I don’t want to steal more time from you. When I begin to write I never know when I’m going to end xD
      I’ll find the time to join that kde-community mailing list and expose all my rants from the users’ point of view there 😁
      Thanks once again for your time.

      Like

    8. I think you and I are in total agreement: developers should be humble and polite and listen to users; expert users of an app are likely to hold informed and intelligent opinions regarding desirable features and the most important bugfixes; and developers should cooperate as much as possible on a smaller number of high-quality apps rather than diluting it across a larger number of mediocre apps.

      Like

Leave a comment