This week in KDE: Porting everything to QtQuick

Well OK not literally everything. But… a lot of things! The KWin scripts KCM, Filelight, and DrKonqi. What does this mean? From a user perspective, mostly not much except for better visuals that align them better with modern KDE UI design. But it also means better-separated internals, more modern code, and easier hackability for the UI. The software’s lifespan increases and we get closer to everything using the same tech stack. It’s important stuff.

In addition, you should find lots of nice bugfixes and even a few new features!

15-Minute Bugs Resolved

Current number of bugs: 70, down from 73. 2 added, 2 found to be duplicates of other 15-minute bugs, and 3 resolved:

Certain monitors no longer constantly power-cycle in a loop when connected (Xaver Hugl, Plasma 5.24.5)

Everyone can once again change their Favorites in Kickoff and Kicker and have those changes persist after restarting Plasma or the computer (Méven Car, Plasma 5.24.5)

After installing a Flatpak app using Discover, there’s no longer still a misleading “Install” button there anyway (Aleix Pol Gonzalez, Plasma 5.24.5)

Current list of bugs

New Features

Skanpage now supports exporting searchable PDFs using optical character recognition! (Alexander Stippich, Skanpage 22.08):

Dolphin now lets you sort by file extension if you prefer that (Eugene Popov, Dolphin 22.08)

In the Plasma Wayland session, you can now change the resolution of your screen to resolutions beyond the officially supported ones, just like you can in the X11 session (Xaver Hugl, Plasma 5.25)

Bugfixes & Performance Improvements

Dolphin’s Terminal Panel no longer gets de-synced from the view itself (Felix Ernst, Dolphin 22.04.1)

Elisa’s “Load Playlist…” and “Save Playlist…” actions now work from the global menu (Firlaev-Hans Fiete, Elisa 22.04.1)

Text in Filelight’s tooltips is no longer clipped away at the ends (Harald Sitter, Filelight 22.08)

Plasma no longer sometimes randomly crashes when you have more than one app with multiple windows open and you interact with one of their Task Manager tooltips (Fushan Wen, Plasma 5.24.5)

In the Plasma Wayland session, KWin no longer crashes when connected USB-C monitors wake up from their power-save states (Xaver Hugl, Plasma 5.24.5)

The Global Menu widget no longer shows menus that the app has marked as hidden, such as the “Tools” Menu in Kolourpaint (Kai Uwe Broulik, Plasma 5.24.5)

In the Plasma Wayland session, KWin no longer crashes when you close a laptop and re-open it when its internal screen is set to turn off when closed (Xaver Hugl, Plasma 5.25)

In the Plasma Wayland session, fixed another way that KWin could crash when you disconnect an external screen (Xaver Hugl, Plasma 5.25)

In an app using xdg-desktop-portals (e.g. sandboxed Flatpak and Snap apps), when you use a file dialog to access a file in a remote location that automatically gets mounted using kio-fuse under the hood, the next time you open the file dialog again, it will open showing the original location, not its weird-looking kio-fuse mountpoint (Harald Sitter, Plasma 5.25)

Closing a window that spawned a child “Get New [thing]” window now closes the child window too, rather than letting it keep living, and then the parent app either crashes or has an invisible window that can’t be shown again until you kill the app using System Monitor or a terminal window (Alexander Lohnau, Frameworks 5.94)

Apps like Konsole that allow you to set a custom color scheme for the whole window that overrides the system’s default color scheme are now substantially faster to launch (Nicolas Fella, Frameworks 5.94)

User Interface Improvements

The KWin Scripts KCM has been ported to QtQuick, modernizing its appearance and making future maintenance simpler (Alexander Lohnau, Plasma 5.25):

Filelight has been ported to QtQuick, modernizing its appearance and making future maintenance simpler (Harald Sitter, Filelight 22.08):

DrKonqi’s crash reporting wizard has been ported to QtQuick too! But honestly you should barely notice the difference (Harald Sitter, Plasma 5.25)

For apps using xdg-desktop-portals, the app chooser dialog now looks and behaves better (me: Nate Graham, Plasma 5.25):

For those of you who disliked the change to always skip minimized tasks when scrolling over the Task Manager to switch tasks, it’s now configurable (Abhijeet Viswa, Plasma 5.25)

…And everything else

This blog only covers the tip of the iceberg! Tons of KDE apps whose development I don’t have time to follow aren’t represented here, and I also don’t mention backend refactoring, improved test coverage, and other changes that are generally not user-facing. If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

If you’re a developer, check out our 15-Minute Bug Initiative. Working on these issues makes a big difference quickly!

Otherwise, have a look at https://community.kde.org/Get_Involved to discover ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

40 thoughts on “This week in KDE: Porting everything to QtQuick

  1. Thanks, Nate, for the once another overview.

    > Closing a window that spawned a child “Get New [thing]” window now closes the child window too

    Thanks, some hell things were happening until I realised I got that problem. Good to hear it gets fixed.

    > Many things have been ported to QtQuick

    Can somebody clarify why QWidgets was bad and how QtQuick simplifies maintenance? And then why all apps were developed on QWidget in the first place?

    Like

    1. QWidgets are not bad, QtQuick is higher level which means a lot easier porting and maintaining. QWidgets dives you better and low-level control, but they prevent faster adaption to new implementation details.

      Liked by 2 people

    2. QtWidgets isn’t bad. But it’s older. QtQuick didn’t exist or wasn’t mature enough to use when the QtWidgets-based apps were written. QtQuick is newer and its ecosystem has only started to mature in the past few years to the point where we can use it for everything.

      While it’s still less mature that QtWidgets, it was developed with the benefit of hindsight to avoid the mistakes of the older technology. In particular, QtQuick enforces a code separation between the logic and the presentation, which is extremely important for future maintainability. Also, the language that the UI is written in is much more developer-friendly. It’s easy to learn, easy to change, and enables a higher “development velocity.” All of these things means that QtQuick apps age better. They don’t become more difficult to understand and maintain as they grow and become very complex over time. We have seen that once a QtWidgets app gets to be a certain size, it often is so difficult to work on that casual contributors wander away, and the app can only be maintained by professionals. When all such people wrop working on an app for whatever reason, the app dies. This doesn’t suit most of KDE which is volunteer-based. The bar to continued existence needs to be lower or else we’ll end up with a tragic graveyard of mature but abandoned apps.

      Finally, there is a benefit to all of our stuff using the same technology stack, rather than being aplit across multiple ones. It means we can implement something in one place and it bubbles down to everywhere, rather than having to do it

      Liked by 1 person

    3. As someone who’s been experimenting with Qt Quick 2 on Kubuntu 20.04 LTS, I’m just left wondering how many behaviours you had to override to make those rewrites not feel like bad ports of mobile apps. Are they using Kirigami?

      …and, if so, when will I start to see more information in my Google searches about how to use Kirigami with things like Python and Rust to easily target both Linux and Windows?

      I learned of Craft, but I don’t really want to make my Python and Rust projects subservient to a meta-build tool, any more than I was willing to write C++ and CMake stuff for rust-qt-binding-generator rather than just using PyO3 to write a Rust backend for a PyQt/PySide QWidget app and then use maturin or setuptools-rust put the Python build tooling in charge.

      Like

    4. In my little experience I found that gui development with QtQuick is way too slow compared with QWidget, maybe I use a lot QtCreator. If in QWidget era my gui development time was 10%, or less, of total programming, now it increased to an enormously 30-40% of dev time: just to place a label or sure it resizes correctly sometimes requires too much efforts. So I’m still using QWidgets for my GUIs…

      Like

    5. Personally I find the opposite, that it takes me 10 times longer to make a bad UI using QtWidgets than to make a good UI using QtQuick. I suspect a lack of familiarity and experience is hindering you, as the examples you gave are fairly basic tasks that don’t generally have a lot of gotchas as long as you know what you’re doing.

      But I do understand that not everyone has the same experience, and I think to a certain extent your preferred UI framework will depend heavily on your own psychology, brain style, and prior experience.

      Liked by 1 person

  2. And another amazing week, with the cherry on top:
    Skanpage now supports exporting searchable PDFs using optical character recognition! (Alexander Stippich, Skanpage 22.08):

    This one made my day! ❤

    Liked by 1 person

  3. Hi Nate! Thanks again for your weekly Summary! A specific goal had my attention: https://bugs.kde.org/show_bug.cgi?id=448398

    Looking at the patch, the code is making use of Vsync, Hsync etc. As you probably know, in Wayland there is no possibility to set a custom resolution unless you want to edit the EDID. Setting a custom resolution is particularly comfortable to me because my monitor can run at 74 Hz instead of 60. Since KWin is internally dealing with resolution details, would it be acceptable to add a window where users can create a custom resolution entry?

    Like

    1. Sounds like the monitor’s 74hz option should be autodetected so you don’t have to set up anything custom. Autodetcting the correct thing is almost always better than configurability, if it’s possible.

      Like

    1. I don’t think there’s a formal list, but all pages in System Settings are going to be ported before Plasma 6.

      I don’t know about Dolphin. However there is already a new QtQuick-based file manager from the Maui folks called Index. In addition, I’m aware of at least three KDE developers working on their own QtQuick-based file managers that are intending to eventually replace Dolphin. One of them seems to be quite far along: https://invent.kde.org/system/melon

      Like

    2. Because its developer is a stubborn soul who prefers it over CMake. 🙂 Should Melon ever gain traction and move out of the realm of being a personal project, it will gain CMake support, and then the QBS buildsystem will eventually wither away and die over time because supporting two build systems is silly, and even though CMake is awful, it’s common and supported and all of KDE’s tooling is set up around it. That’s the way this sort of thing happens.

      Like

    3. I have a PinePhone with Manjaro/KDE, and it came with Index. Which utterly failed from a usability standpoint (for starters, it can’t recognize the SD card, and network? whuzzat??) and first thing I did was install Dolphin so I could have a proper file manager. Sorry, but Index is not progress.

      I live in the file manager, and I’m really REALLY tired of “improvements” that take away basic functionality — the multiple ways File Explorer got broken by the New Win8/10 interface was one of the major devolutions that drove me away from modern Windows.

      Like

  4. KDE 5.x should be long since DEAD. You still are adding NEW features at 5.25!! When are you clowns going to slap a FEATURE FREEZE on KDE 5?? The irony here is that the number #1 thing people keep asking to be added is a SIMPLE having Virtual Desktops that allow for DIFFERENT WALLPAPERS and DIFFERENT WIDGETS like we had back in KDE 4.6 up to 4.14 (where KDE 4.x was ended unlike KDE 5 which is now at 5.25 and moving ever higher) and STILL the SIMPLE thing of having VIRTUAL DESKTOPS with DIFFERENT WALLPAPERS and DIFFERENT WIDGETS still has not been answered. The best way to achieve that is via the totally CLUNKY “ACTIVITIES” that require users to jump through a whole lots of hoops to get to the same point that required a 1 click checkmark in a box, from there is was a matter of configuring KDE to the way the USER likes it. But we are now at KDE 5.25, and we still do not have what users want to which is the simple elegance of KDE 4 Virtual desktops not this misbegotten creature called “Activities”; we still DO NOT have a FEATURE FREEZE is place; and you are still crushing bugs that should have been stomped out by the end of KDE 5.15. Right NOW KDE should be the smoothest DE ever and it should INCLUDE VIRTUAL DESKTOPS that came out in KDE 4.x and was slick as snot by KDE 4.14, as well as “ACTIVITIES”. KDE 5 should have built in flexibility that is USER DEFINED, *NOT*DEVEL defined.

    I suppose come this time next year KDE 5 will up to KDE 5.40 and you will still be stomping out bugs, that will have been introduced because there still will not be a FEATURE FREEZE in place and each NEW features introduces NEW BUGS! I now know what the ZOMBIE APOCALYPSE will look like: a bunch of brain dead (? or more correctly BRAINLESS) programmers wearing cards around their necks that say, “KDE 5.x” The official slogan will read, “KDE 5. The Nightmare of the Living Dead; the DE that refuses to DIE; the gift that keeps on giving INDEFINITELY — just not what the USER wants”.

    Like

    1. Hahahha did you forget to take your hormonal meds or something? Your ranting is pathetic. Don’t forget to dilate too

      Liked by 1 person

    2. The delivery may be hyperventilating, but the sentiment is correct: Users ***HATE*** having established usability and features taken away in the name of progress. My very favorite distro-incarnation EVER was killed dead by that specific loss of features between KDE4 and KDE5, because there was no longer a way to set up individually customized virtual desktops (never mind a way for user-defined color schemes outside of preset themes, much to the dismay of my aging eyes… that, BTW, is the other major reason I bailed out of post-7 Windows).

      I don’t care if it’s called KDE 3, 4, 5, 6, or 600. Please don’t break things we rely on out here in userland. What developers find interesting and important is often diametrically opposed to what everyday users want and need, and that feature loss between KDE4 and KDE5 is a prime example.

      Like

    3. While in Kde Plasma’s transition from 4.x to 5.x I was certainly annoyed by the loss of different widgets and backgrounds per desktop, now with some perspective I think it’s fine.
      I divide my work in activities (for example: office, graphic edition, multimedia, etc.), and the activities in workspaces. So, I think it’s not necessary deliver one feature for the virtual desktops that’s already disponible on activities. That is, if you are going to give the virtual desktops the features that correspond to the activities, simply delete the activities. There would be no point in keeping them alive.
      But the real problem with the activities feature is that there is no quick and visually appealing way to move windows between activities. That is, there is no such thing as “overview” or “desktop grid” for activities. I would even go so far as to say that manual configuration for both activities and virtual desktops is too much work! A combination of manual activity aggregation plus automatic virtual desktop aggregation (gnome-like) might be a good idea. In this case you would need an independent number of virtual desktops per activity, but it would be too complex for the average user to understand

      Liked by 1 person

    4. I agree, Activities, while an integral part of Plasma, aren’t ‘smart’ enough, and there is no visual way to interact with them apart from the activity switcher itself. IMO the best solution would be to have dynamic workspaces (like macOS and GNOME) per activity, and have an Activities button in the overview, which would bring up the switcher as a sidebar (which is already kinda is), but windows could be dragged to activities. Shift-drag to show the window on both the current and target activity.

      Activities and workspaces also needs to be communicated to the user, like “activities is the different things you might do with your computer: the unique set of tools and widgets you need for a specific kind of task, and an unique wallpaper to reflect the mindset required for that activity, and provide inspiration. Workspaces is simply a way to organize your windows inside activities, when you have lots of windows”.

      A lot more things could be automatic or less fiddly about Activities, and with proper communication, the users would realize that they are a really powerful feature. If they, however, choose not to use Activities, it should not bother them. If there is only one activity, all activity-related features should disappear, except the way to create more activities. Have the activity switcher on the panel by default, and in it have a “get started with activities” button that explains it.

      Liked by 1 person

    5. Yes, i agree with all you say. I think the activities are a very good idea but underexploited because the mentioned reasons. There is another great feature i really enjoy about activities, beyond diferents widgets and backround, and that feature is the posibility of have diferent launchers on the panel per activity. Having an activity prepared for a specific type of work (with the necessary applications and files) helps you a lot to concentrate. So, as a common user i just need better communication between activities, virtual desktop and windows to improve user experience.

      Like

    6. Do you think anything will be better if you yell angrily at Nate and his audience? Do you think developers who work on this project as volunteers, in their free time, will do what you, ONE of the millions of users, demands, if you call them brainless clowns? Are you paying them heaps of money, to have the right of demanding anything in this tone? Would you rather KDE get completely abandoned because the people doing actual work on it get fed up with the toxic bullshit of people like you?
      Why don’t you contribute, if you know so much?
      Take a deep breath, drink some hot chocolate, and think.

      Like

    7. Nobody wants to cater to people screaming and swearing at them all while making demands. Even if it’s a good idea.

      Thousands of hours of people’s time into something everybody can enjoy, for FREE, and then that? Hey everyone coding KDE so I can use it free of charge- THANK YOU again.

      Liked by 1 person

  5. Great news.

    Regarding skanpage There is one thing that keeps me on skanlite: I am able to keep on scanning.

    Eg: I open skanlite – select scan – it asks me to choose a name sequence – and from that on I just have to change page & press scan, change page & press scan… And so on .

    It’s very very useful for scanning multiple separate documents.

    Would be great to have something like that on skanpage…

    Liked by 1 person

  6. Great updates as always! 3 (possibly) quick questions.

    Is there a plan for Elisa to support adding remote locations to your library via kio-fuse? Even if you have already added the network folder in Dolphin, you pick the saved network location in Elisa, see the the smb://foo@some_address/audio/ location, hit okay, and nothing is added.

    Is there a plan to make offline updates via Discover more efficient for those with encrypted installations (which ideally most people would be using)? Right now I always have to do a double boot/password, with the first to get to the ‘barely booted enough to install the updates’ stage, then another to boot the system after the update. This makes more sense for a kernel or glibc update, but if the updates are minor things, the 2nd reboot seems excessive. I’ve always used command line tools for updates, but it feels like Discover is getting close enough to usable for system updates so I’d love to see it get over the hump. And realistically I’d need it to be rock solid to put it on computers for family members (which I want to!).

    Is any help needed to reproduce this and related issues: https://bugs.kde.org/show_bug.cgi?id=353975 ? It happens to me multiple times per day on my desktop and has made Plasma basically unusable. This is on Fedora 35, triple monitors, X11, latest Nvidia drivers (from RPM Fusion). I also sometimes hit a similar but slightly different bug, where instead of the display being on but you can’t interact with it (e.g. right click), the monitor just disappears from the system and powers off. I’ve even had this problem survive a reboot. The center / main display just wasn’t recognized either when the system woke up, or I switched back to it on the KVM (fancy Iogear 4k60 displayport model). This happens for me in Tumbleweed also. I’d be happy to provide logs or whatever else is needed to help debug or even fund a bug bounty on it. It’s so bad that I actually installed Fedora Workstation and Pop!_OS on spare disks to play with. I love Plasma and it feels like home to me. It’s my favorite DE around, above all Linux options, Windows, or macOS. But I could see someone hitting this issue and swearing off KDE forever. It’s that maddening.

    Like

    1. I also suggested the first one some time ago and I’m eager to see it implemented. That would be really very useful, since in many cases the media libraries are located on network locations.

      Like

  7. I don’t quite get the hype about QtQuick. Regardless of how simple it is to develop, it’s just not practical for users. Most QtQuick applications are completely static, with widgets/panels not being resizable. They tend to be slower and less responsive, too. Contrast this to classical QtWidgets, which are smooth, performant and adaptive.
    Unless QTBUG 99686 [1] gets fixed anytime soon, it looks like I’ll be left with a desktop environment that is so buggy that it’s hard to endure. I generally like how Plasma is designed and am not particularly happy with any other desktop environment, but as QtQuick is getting dominant in Plasma, maybe I should consider switching to Enlightenment or LxQt anyway…
    [1]: https://bugreports.qt.io/browse/QTBUG-99686

    Like

    1. BTW, every single UI component of Plasma itself has been QtQuick since KDE 4. What’s new is older QtWidgets-based *apps* moving to QtQuick. So “get that QtQuick out of my Plasma” is a bit like “get your government hands off my Medicare”.

      You’re welcome to switch to anything else that gives you more joy. Life’s too short to bang your head against something you aren’t happy with when there are alternatives.

      Like

  8. If you had actually read the bug report in question you’d have noticed that I am of course aware Plasma is built with QtQuick. I also have said performance problems with Plasma, e. g. the start menu sometimes not appearing on key press, or only appearing with delay, any Plasma tooltip having a transparent background, etc.
    Anyway, this doesn’t make the situation better, and does not justify further adoption of QtQuick, which does have problems with UX and reliability. I’m confused by the strange tone of your reply, and would have expected a more respectful consideration of the matters.

    Like

    1. I understand that my wording was ambiguous, though. I tend to use the term “Plasma” as a synonym for KDE, its apps and frameworks as a whole.

      Like

  9. Will KDE have at some point a default light color scheme that uses real black #000 on real white #fff text? This gray on grey trend is not helping my eyes, which are not getting better with time.

    // TBH, this blog could also use #000 text.

    Like

  10. any advance tutorial to learn Qt Quick with Pyside ? , i can’t find any lessons about Qt Quick with PySide that lead me to professional it, and even the document of the official Qt website seems poor in terms of Python with QtQuick
    , unlike I found that there are many sources to learn and master QWidget in YouTube or websites , and this is what makes me stay in the QWidget even though I want to walk with QtQuick

    Like

Leave a comment

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

WordPress.com Logo

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

Facebook photo

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

Connecting to %s