KDE Plasma 6 Alpha Approaches Next Week With The Soft Feature Freeze

[bug77]

*nod* My muscle memory is `apt-cache search foo | grep foo` and I only use Discover for updating what I've installed through the CLI and this is one of the reasons.

pacman's CLI is worse than that:
usage: pacman <operation> [...]
operations:
pacman {-h --help}
pacman {-V --version}
pacman {-D --database} <options> <package(s)>
pacman {-F --files} [options] [file(s)]
pacman {-Q --query} [options] [package(s)]
pacman {-R --remove} [options] <package(s)>
pacman {-S --sync} [options] [package(s)]
pacman {-T --deptest} [options] [package(s)]
pacman {-U --upgrade} [options] <file(s)>

(guess which one installs a package)

It's still preferable to Discover. By a mile.

[dpeterc]

Whoever shuts down the computer without saving their work deserves that. Besides there can be a power outage, not losing data is application's responsibility by doing periodic saves and/or maintaining a cache. So I didn't even know it was not working since I always disable session saving to shutdown and boot faster.

Typical reply of Wayland supporter to missing features:

1. I don't need it, so you shouldn't either.
2. Whoever needs it is an idiot.
3. Should be done by application.

[mrg666]

Typical reply of Wayland supporter to missing features:

1. I don't need it, so you shouldn't either.
2. Whoever needs it is an idiot.
3. Should be done by application.

There are only annoying X11 supporters trying to reverse the demise of X11. I agree with your second and third bullets though.

[bug77]

There are only annoying X11 supporters trying to reverse the demise of X11. ...

See, this is where you're wrong. It's the newcomer that has prove their worth, X isn't dead just because Wayland exists.
A display protocol is just a means to an end. If my sh!t won't work on top of it, it's simply of no interest to me. I don't turn on my computer to run a display protocol, I turn it on to get stuff done.

[mrg666]

See, this is where you're wrong. It's the newcomer that has prove their worth, X isn't dead just because Wayland exists.
A display protocol is just a means to an end. If my sh!t won't work on top of it, it's simply of no interest to me. I don't turn on my computer to run a display protocol, I turn it on to get stuff done.

No, I can't see, I am the newcomer ... check the dates of joining.
I also use my computer to get work done. And I always get it done. I don't care about your sh!t, your interests, means to your ends, why you turn on your computer, and neither xorg developers. You like X11? Run it, it is there. BTW, it is dead, I hate to remind you but development stopped more than a decade ago. Nobody wants to touch that with a flag pole.

[Eudyptula]

Sarcasm aside, it would be a good start - although, way too late.

The following is my very personal and subjective opinion. I can only speak for Plasma, System Settings, Info Center, Discover, System Monitor and Spectacle. I'm not using the others you mentioned.

* Plasma
Before QML there was a well thought consistent "design" in everything. You could intuitively "know" where to do what. And the configurability was one of the strong points. Now it has become so much windows-like. "There must be a setting somewhere but where?" It is still quite configurable but it lacks the organization.

* System Settings
Holy Cow! A conglomeration of dozens of smallish applications that are supposed to "work together" but rarely do. Does not work on slightly older graphic cards.

* Info Center
QML is an overkill for this small application. Everything it does is simple to express in plain C++ and Qt widgets.

* Discover
... has become so bad that I switched back to use the command line for installing/upgrading. And it's not for lack of trying. I use the GUI when a usable one is available.

* System Monitor
Used to "kinda work" - no longer does. I miss the non-QML plugins

* Spectacle
Fits into the KDE landscape like a hammer on a raw egg. I'm mainly using Flameshot. The worst thing is that the start menu doesn't find it with the usual search terms like "snip", "screenshot" "snitch" etc.

There was a very noticeable cut in "snappiness" with the introduction of QML, and it has worsened over time. In hindsight I have to say that this was very foreseeable: Operate a JavaScript engine in between your applications and the desktop. I did not know this at the time. I know now. There was also a perceived "pause" of development with the move to QML. That time would have been better utilized for improvement or bug fixing.

It is very sad to see a desktop that was so well designed at first, and surprised everyone with the memory consumption, to be destroyed like this.

Thank you for elaborating on your opinion of QML, I was curious about this when reading your initial comment. I don't have any strong opinions about it, it seems like there's no clear-cut solution and that all options (that I'm aware of) come with caveats.

It seems to me that there are some valid points against using QML (while clearly having some upsides as well).

I get the impression you can feel the disadvantages of QML in certain areas when using KDE software (however, Gnome feels more sluggish with all its non-optional slow-motion animations and Windows is, well... like a forgetful old person walking over the crosswalk).


I guess the question is, are there any viable alternatives?
I feel like C++ would really slow down development and complicate it to a point where it would greatly reduce the number of contributors (even though it would, in theory, speed up the software). There would have to be something with the accessability of QML without the downsides. C++ also seem to be a nightmare in regards to bugs and security (due to how meticulous and skilled programmers have to be with that particular language) and thus not really being a real option in the first place (as new languages like Rust seem to solve a lot of problems).

[bug77]

No, I can't see, I am the newcomer ... check the dates of joining.
I also use my computer to get work done. And I always get it done. I don't care about your sh!t, your interests, means to your ends, why you turn on your computer, and neither xorg developers. You like X11? Run it, it is there. BTW, it is dead, I hate to remind you but development stopped more than a decade ago. Nobody wants to touch that with a flag pole.

Which was dpeterc's original assertion. The one you didn't agree with.
And btw, not being developed further is not the same as dead.

[lowflyer]

Thank you for elaborating on your opinion of QML, I was curious about this when reading your initial comment. I don't have any strong opinions about it, it seems like there's no clear-cut solution and that all options (that I'm aware of) come with caveats.

It seems to me that there are some valid points against using QML (while clearly having some upsides as well).

I get the impression you can feel the disadvantages of QML in certain areas when using KDE software (however, Gnome feels more sluggish with all its non-optional slow-motion animations and Windows is, well... like a forgetful old person walking over the crosswalk).


I guess the question is, are there any viable alternatives?
I feel like C++ would really slow down development and complicate it to a point where it would greatly reduce the number of contributors (even though it would, in theory, speed up the software). There would have to be something with the accessability of QML without the downsides. C++ also seem to be a nightmare in regards to bugs and security (due to how meticulous and skilled programmers have to be with that particular language) and thus not really being a real option in the first place (as new languages like Rust seem to solve a lot of problems).

To be more "generally specific" about the problems, it comes down to two areas:

1. In GUI applications it is generally recommended to separate between GUI and application code. QML does not help with that - au contraire, it deliberately blurs the separation.
2. QML needs some sort of a Javascript engine running in your application. The Javascript engnine runs a few orders of magnitude slower than C++. Additionally, the interfacing between application and QML also needs CPU cycles.

The first point makes it difficult for the programmer. To keep application code separate from QML requires an unearthly level of discipline. QML makes sure that it always looks "polished" - even if the code is wrong. The second point is the price to pay for it. Run an application on one of these new 5 GHz, 18-core PC's with plenty of RAM, I bet you won't notice the difference. But multiple applications on a normal earthly system...

I can point you to three alternatives.
There is one inside Qt Widgets. It's called Qt Style Sheets. With these you can polish the look of your Qt Widgets application pretty much the same way as with QML. And it's dynamic - which QML is not.

From your comment I suspect you would like to see an alternative written in Rust. I don't want to hijack this thread for a Rust vs. C++ rant. But I think your perception of C++ is wrong - it is easier than you think and it is becoming easier still with each new iteration. Your expectations from QML and Rust are too high. QML, see above - Rust is more complicated than you think. Don't fall for the snake oil that the Qt Company and the Rustafarians pour out. Your only option is to exercise patience until Rust is on par.

If you are willing to pay the price of a Javascript engine, there is another alternative: node.js. You have all features of HTML, CSS and Javascript without the limitations of QML and without the "ballast" of C++.

[ssokolow]

I guess the question is, are there any viable alternatives?
I feel like C++ would really slow down development and complicate it to a point where it would greatly reduce the number of contributors (even though it would, in theory, speed up the software). There would have to be something with the accessability of QML without the downsides. C++ also seem to be a nightmare in regards to bugs and security (due to how meticulous and skilled programmers have to be with that particular language) and thus not really being a real option in the first place (as new languages like Rust seem to solve a lot of problems).

If you're bundling an intepreted language into things for the UI-building layer, there's always Python. PySide is the only official binding for a general-purpose (non-QML) memory-safe language (like QtJambi for Java used to be), Python has MyPy which, as far as I know, does better than any available QML linter/type-checker when put in strict mode, and PySide grants access to the QWidget APIs, unlike QML.

As a KDE user who values snappy, native-feeling interfaces but doesn't trust himself to write memory-unsafe code, I write all my GUIs with PyQt or PySide. (Mostly PyQt for historical reasons.) The work split Qt enables between Python and C++ means the Python code stays I/O-bound waiting on the user and, if I do need to do some CPU-bound stuff, there's always Rust and PyO3.

...and, for context, I'm running on a dual-core Athlon II X2 270 from 2011 (chosen based on a 65W TDP upper limit) where Firefox is pretty much constantly taking up 25% of available CPU time when "idling" and Thunderbird's new v115 webtech UI made Thunderbird painfully sluggish... but my Python+QWidget apps are still nice and snappy.

[mrg666]

Which was dpeterc's original assertion. The one you didn't agree with.
And btw, not being developed further is not the same as dead.

He wrote

1. I don't need it, so you shouldn't either.

I wrote

You like X11? Run it, it is there.

You are only proving the second bullet true.