Budgie Desktop To Begin Decoupling From GNOME, Will Use Qt

[ikey_solus]

This is unexpected, considering than ikey has always been a GTK fanboy, for what I have read. But it makes sense.

I've never been a fanboy of anything. Except Heroes. But only Season 1.

[ua=42]

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?

Well, there are other issues with GTK...
Mainly it generally looks like $#1T on mac and windows and can have issues when run in KDE.

[leipero]

GNOME 3.24 gets the idea of less is more, and a consistent interface that has a ways to go compared to OS X but beats the pants off all other options for Linux. Qt for specific apps is fine. I'm used to it. If it becomes more like KDE I'll gut it out of my system.

Exactly, when I see KDE, it's like tigers attacking me, run run run . But seriously, I can't explain it, but any QT DE simpy "doesn't feel right" to me, it's like using Windows, same "feeling" of being heavy. But QT applications such as Clementine do feel right in GTK based DE.

[patstew]

These kinds of project shifts always devolve into people arguing which toolkit is better, GTK+ or Qt, and even C vs. C++...

But actually the blog post is much milder. The problems more specifically are about Mutter and some GTK+ internals. And the author happens to prefer C, but complains that GNOME's C is not very standard.

My humble response to this blog post is that many of the problems mentioned with GNOME exist in Qt/KDE as well. Qt uses a non-standard C++ (a weird macro preprocessor) and ABI breakage in C++ is always more painful than in C. I have a feeling this change is not really going to make life easier for Budgie.

Qt is not non standard C++, the source files you write are standard C++ with standard macros. It does have a code generator (moc) that creates some extra C++ files, but it doesn't preprocess your code or extend C++ at all.
If you really hate moc, one of the moc devs wrote a version using C++ template magic, so there is no extra step, but it uses a slightly different syntax (https://github.com/woboq/verdigris).

[computerquip]

Qt is not non standard C++, the source files you write are standard C++ with standard macros. It does have a code generator (moc) that creates some extra C++ files, but it doesn't preprocess your code or extend C++ at all.
If you really hate moc, one of the moc devs wrote a version using C++ template magic, so there is no extra step, but it uses a slightly different syntax (https://github.com/woboq/verdigris).

I don't think that was quite the point. The point was that the C++ style that Qt implements is weird and unconventional, much like the C that the original blog post complains about in Gnome.

[computerquip]

Well, there are other issues with GTK...
Mainly it generally looks like $#1T on mac and windows and can have issues when run in KDE.

Welp, can't argue there unfortunately. The dependency chain is also really complicated and isn't well supported on platforms outside of Linux. Usually autoconf based, provides no build instructions for Windows, and has a smaller Windows community. That's why I don't tend to use anything that uses GTK+ as an explicit dependency on Windows or Mac.

[eidolon]

ikey_solus
SolusOS 2 (not Solus) temporarily made use of Xfce (IIRC, for alphas 8 & 9) while Consort was in the works, and there was some talk of working to help port Xfce to GTK+ 3,^[1][2] so you have some familiarity with Xfce. With the full acknowledgment that you aren't an Xfce developer and Xfce is master of its own destiny, given your statement on GTK+ in the context of Budgie's needs (such as "GTK+ clearly develops in the direction of the parent GNOME Desktop experience"), if you would hazard an opinion regarding Xfce, is GTK+ 3 and beyond (more so with regard to the "and beyond" part, I'm not concerned about GTK+ 3 churn at this point, not to mention that a fair bit of the porting has already taken place) the direction you think would be most beneficial to Xfce, given the alternatives?

[ldo17]

The dependency chain is also really complicated and isn't well supported on platforms outside of Linux.

That’s hardly the fault of Linux, that it was specifically designed to be friendly towards Open Source. Blame the proprietary platform vendors for offering such inflexible IDE-centric tools.

[ikey_solus]

ikey_solus
SolusOS 2 (not Solus) temporarily made use of Xfce (IIRC, for alphas 8 & 9) while Consort was in the works, and there was some talk of working to help port Xfce to GTK+ 3,^[1][2] so you have some familiarity with Xfce. With the full acknowledgment that you aren't an Xfce developer and Xfce is master of its own destiny, given your statement on GTK+ in the context of Budgie's needs (such as "GTK+ clearly develops in the direction of the parent GNOME Desktop experience"), if you would hazard an opinion regarding Xfce, is GTK+ 3 and beyond (more so with regard to the "and beyond" part, I'm not concerned about GTK+ 3 churn at this point, not to mention that a fair bit of the porting has already taken place) the direction you think would be most beneficial to Xfce, given the alternatives?

GTK is only one part of the picture for Budgie. XFCE (And MATE) are in a much better position in that regard in the sense that only one part of their overall stack is dependent, thus it's far easier to mitigate any issues (And not to forget that GTK3 itself is entering the LTS twilight years).

For the other projects, no I don't believe GTK3 represents a sizeable issue anymore. For Budgie, "tightly integrated with the GNOME stack", is eventually what kicked us in the teeth. Such is the nature of dependent growth.

[t.s.]

...Building a desktop is really hard, and, from what I see, is too much work for the floss community of they split their efforts.

Yep. Agreed. In linux, there must be more than 2 of anything.