Budgie Desktop To Begin Decoupling From GNOME, Will Use Qt

[Zoll]

Glad they took this decision. Qt is way superior to GTK in every way, this is why even Unity ditched GTK for Qt.

But why they explicitly say they would never using KDE Frameworks? Tier1 KDE Frameworks only depend Qt and already has a lot of work done and ready, they have no dependency on other KDE components. IMO, using at least Tier1 KDE Frameworks will accelerate development by quite a bit.

[ikey_solus]

But why they explicitly say they would never using KDE Frameworks?

I didn't just get out of one bed to fall right into the next one.

[oleid]

I still dont get why switching to Qt when there is still GTKmm. It's so much nicer than Qt from a c++ point of view. And nowadays, gtk3 is as stable as it will get. And it has bindings for any language on the planet. There is no Rust based Linux desktop yet, is there?

[ldo17]

... like saying mc donalds is against eating food.

Given that your statement isn’t exactly news, what point were you actually trying to make...?

[ikey_solus]

I still dont get why switching to Qt when there is still GTKmm. It's so much nicer than Qt from a c++ point of view. And nowadays, gtk3 is as stable as it will get. And it has bindings for any language on the planet. There is no Rust based Linux desktop yet, is there?

I explained it all in my post. If you're asking that, you didn't read it The problem here is not the language, it is very much the toolkit and platform. (All in the post.)

[Delgarde]

Not sure why they don't just target the latest GTK LTS...? Or is there something else I'm missing here?

Not really to surprised. I seem to remember gnome being against having stable apis for others to use...

If you actually read the post, it's only tangentially about Gtk+. Mostly it's about Mutter, and in general, trying to keep compatibility with bits that Gnome doesn't really regard as public API for others to use.

[Luke_Wolf]

There is no Rust based Linux desktop yet, is there?

Technically there is one for RedoxOS along with a toolkit, but... it's as primitive as it gets, I'm sure linux will eventually get it though. Certainly though it would be good to see someone create a proper rust desktop and toolkit, just so that it exists and helps them in their goal of rewriting the world. But... there's no point bugging existing desktops to switch. They have too much legacy, and it's probably better to start from scratch anyway.

[Alliancemd]

I work in the automotive industry and we use Qt extensively(all the car manufacturers' infotainment systems that I know of moved to Qt. Cars from China were the only one in the world not using Qt and now they switch too).
I must say that starting with Qt 5.6, the framework is Very Solid.
Before Qt 5.6 there were a few issues and all of them on the QML side(like aggressive optimizations by the QML Engine that freed memory it shouldn't... Crashes at shutdown because the QML Engine was managing badly concurrent memory access and freeing the resources - again, before Qt 5.6).
We hit one regression in Qt 5.8 in the QML Engine, but it doesn't affect almost nobody.

ikey_solus Did you consider using Rust for the low-level stuff? Just throwing it out there(sorry, obsessed)
"We will not be using QML. The desktop core should not be using JS, C++ only." - Sorry, but I think that you have a misconception of QML(please receive it as constructive criticism - explanation coming) and I sincerely propose to reconsider.
We also use QML extensively and we have exactly 0 lines of JavaScript code.

The idea is to do all the logic on the C++ side and expose an API through something like Q_PROPERTY to the QML side.
This makes it extremely easy to create UI applications that use reusable [C++ but exposed to QML ]components in a very nice way.
Remember that with QML you automatically get:
- Beautiful UIs(debatable?)
- The UI is GPU accelerated(animations...)
- Cross-platform and works with different display servers: Wayland, X11...
- Supports OpenGL, Software Raster, DirectX, Vulkan(experimental) - all automatically selected for you based on the platform and driver support(default behavior that can be changed if desired).
- Good support for animations
- Theming
- Native support for HighDPI
- Native support for multi-screen
- Good API(debatable?)

If you want, you can create your own QQuickItems and draw the way you want.
In Qt 5.8 you can make your own Wayland compositor in QML( https://www.youtube.com/watch?v=9vWMUTvFgdU )

Let's say that you have some C++ code/API that contains the "quote of the day" and you want to present it to QML.
You can either make a class and register it as property to a QML context or make it a QML component(the way we do it).
If you make it a QML component, than you could do this in your QMLs:
```
import BudgieAPI.QuoteOfTheDay 1.0 as Quotes // you find a better a name
//or, ex: import QuoteOfTheDayAPI 1.0

...
text: Quotes.quote
```
and if you want to change it `Quotes.quote = "some other quote"`, or if you have a Quotes based component, just `quote: "some other quote"`
Now you can swap data structures and implementations in the background and you still keep the API nice.

Another example where we offer a nice QML API but all the code is actually heavily optimized C++ code:
We implemented the QQuickImageProvider interface that in the background uses a cache manager to speed up image loading(think kdeinit but for images + other optimizations).
You have a nice ImageProvider API where you just attach an image wherever you need it but in the background what happens is:
- On first request, based on the selected strategy, we load either a lossy pre-compressed texture(ASTC compression) or a lossless compressed texture into the GPU memory.
Then we just give a pointer to that. From this point on, the CPU is almost completely taken out of this equation.
- If the image already was loaded, it's just a pointer and displayed directly from GPU memory.

These images now consume no RAM at all(all in VRAM) and the CPU has nothing to do. This results in fluid 60fps animations even on aggressive hundreds of images scrolling, on a very weak hardware.
It's still a nice QML API that makes it easy to develop and maintain the code. It doesn't have to make your code slow, if you don't want to make it slow...

[ikey_solus]

Did you consider using Rust for the low-level stuff? Just throwing it out there(sorry, obsessed)

I've taken a proper look, and personally, Rust just isn't for me. Believe me I understand the benefits of Rust, but I really can't get behind the syntax. Nowadays I'm mostly C & Go (Go replacing as much of my old Python cruft as possible)

"We will not be using QML. The desktop core should not be using JS, C++ only." - Sorry, but I think that you have a misconception of QML(please receive it as constructive criticism - explanation coming) and I sincerely propose to reconsider.

No I believe my conception to be entirely accurate. I know what you're getting at, separation of business logic (C++) and presentation (QML/JS). Still need that JS though Personally I don't really want that in the core desktop (shell) itself. For the applications, like the Control Center, sure, it could make sense. And obviously we want to ensure that all of our useful "Budgie bits" are usable from QML for those extending the desktop. What I'm explicitly avoiding is "QML all the things". Or restricting ourselves to QML only UIs, making life harder for those building so-called native widgets apps.

[starshipeleven]

Good, I always approve projects on Qt.