KDE Now Maintaining Their Own Set of Patches For Qt 5

[oleid]

The API is much cleaner - a lot of that is because it's based around an object-oriented C++ base rather than C.

There is little need to use C apis here. This isn't C vs C++. Most C APIs have nice C++ wrappers, e.g. GTKmm, gstreamermm, cURLpp, the list goes on.

[BesiegedAce]

Looks like someone is afraid of everything that does not look and work like windows 95. Real spooky.

In fact KDE maintains a breeze theme for GTK3 and it looks quite nice, better then their own breeze qt theme I would say. But that is mostly due to GTKs extremely flexible css based theming.

Even with Breeze-gtk gnome stuff looks weird and out of place on my desktop.

Also GTK filepicker sucks and continues to suck. Even Windows 98 has a better filepicker.

[DanL]

Fanboyism.

Yes, you are. FWIW, I liked xfce 4.14.x, and I still don't feel completely comfortable with KDE 5. Whatever, but please continue with your stupid narrative that people who don't like GNOME Shell are Win95 Luddites.

[Nth_man]

> The API is much cleaner - a lot of that is because it's based around an object-oriented C++ base rather than C.

There is little need to use C apis here. This isn't C vs C++. Most C APIs have nice C++ wrappers, e.g. GTKmm, gstreamermm, cURLpp, the list goes on.

An object-oriented C++ base is better and cleaner than a C++ wrapper around a not-object-oriented base...

[ssokolow]

Looks like someone is afraid of everything that does not look and work like windows 95. Real spooky.

In fact KDE maintains a breeze theme for GTK3 and it looks quite nice, better then their own breeze qt theme I would say. But that is mostly due to GTKs extremely flexible css based theming.

I tried every desktop session under the sun when I first came to Linux (KDE 3.x, GNOME 2.x, Xfce whatever, Enlightenment E16, Fluxbox, Openbox, etc. etc. etc.) and settled on KDE 3.x because GNOME 2.x felt like a more feature poor, more visually bloated version of it.

When GNOME 3.x came out, I gave it a shot... it just doesn't fit with my workflow... and you're talking to someone who now uses KDE 5.x, not because it works like Windows 95, but because it's the easiest to reprogram to my preconceptions of how I want my desktop to behave.

You're talking to the maintainer of QuickTile, a guy with three monitors who makes heavy use of global hotkeys and drop-down terminals to interact with his desktop, and who has been meaning to find time to hack together an AwesomeWM config to achieve the blend of tiling and floating he wants.

It has nothing to do with behaving like Windows 95 and everything to do with just plain not liking the direction the GNOME HIG is going.

[ssokolow]

In what sense? Let's say for the sake of argument that you are right, wouldn't it be simpler to add whatever features you are missing to GTK and then use that instead of be beholden to some company that clearly doesn't care about you at all? Personally I'd love to see Qt abandoned so that there is only one major display toolkit on Linux. It would simplify things for app developers and fix all the theme issues. The only problem is that KDE would have to be completely rewritten.

It won't happen, but I can dream.

Let's see.:

1. Qt's documentation is far superior to GTK's. (IIRC, this was listed as the big reason Subsurface moved from GTK to Qt.)
2. Last I checked, while Qt's MVC framework for data widgets is often considered its worst part, GTK's MVC framework was still a nightmarish mess by comparison.
3. GTK requires you to reinvent customizable toolbars or pull into GNOME componentry. It's built-in as part of Qt, and it's six lines of code to automatically persist both window geometry and toolbar/panel configs.
4. When I left PyGTK for PyQt4, you still had to use this hack to get multi-selection and drag-and-drop in the same TreeView widget.
5. GTK just deprecated Glade in favour of recommending that people write the GTK Builder XML by hand. Sorry, but I like working with Qt Designer.
6. GTK developers consider it to be as-intended that you can't rename or delete things inside the file picker but, instead, have to open up the file browser and navigate to it the long way. As soon as I upgrade my Kubuntu LTS, I'm planning to set USE_PORTAL globally to see how many GTK apps I can rid of it.
7. I'm sorry, but I don't want to work with a desktop that's so focused on cargo-culting what they like about Apple that they don't understand first-year HCI concepts, such as "stick with the floppy disk icon, because affordances are only valuable for learning the iconography, after which consistency reigns, and your user base already knows the 'save icon', which has other technical advantages too" or "Dialogs should read like printed pages, which means you put the action buttons in the bottom-right in LTR languages like English, not in the titlebar." (See, for example, this blog post, for some guidance on the kinds of things it's important to be thinking about.)

The list goes on and on.

Compromise accepted. I think Gnome is slowly going that way no matter what. On the other hand, what are the odds KDE or its applications will ever be written in Rust? I'd say near zero.

While it's more intended for incorporating Rust into a project that uses CMake and C++ at the top of the stack, the rust_qt_binding_generator crate is a KDE project. (It's a pragmatic approach that gets something usable now while Ritual and its rust-qt bindings churn away at implementing machine-generated bindings for things like subclassing-based APIs, overloaded methods, and all the other C++ OOP "goodness" that Qt APIs like QWidget picked up when they were laid down in the 90s.)

[TemplarGR]

Why every, but every thread on news about Qt, KDE, GNOME, or GTK, has to escalate into a fight between the 2 ecosystems? In the end, just use what you like. I use GNOME because i like it more. As for the article itself, KDE has always been a tech demo of Qt, and always will be. If you expect KDE to ever drop Qt, you just don't understand the situation... KDE will NEVER drop Qt, and if for some reason Qt ceases to exist, KDE will cease to exist as well.

[Alexmitter]

Even with Breeze-gtk gnome stuff looks weird and out of place on my desktop.

And so does the Windows 95 styled abomination that are Qt/KDE apps on my desktop.

Also GTK filepicker sucks and continues to suck. Even Windows 98 has a better filepicker.

Yea, not the very best file picker, but very stable and does its job, can't say that about the KDE file picker that sometimes pops up on KDE apps or the Qt with generic Qt apps.

[Alexmitter]

Why every, but every thread on news about Qt, KDE, GNOME, or GTK, has to escalate into a fight between the 2 ecosystems? In the end, just use what you like. I use GNOME because i like it more. As for the article itself, KDE has always been a tech demo of Qt, and always will be. If you expect KDE to ever drop Qt, you just don't understand the situation... KDE will NEVER drop Qt, and if for some reason Qt ceases to exist, KDE will cease to exist as well.

Because one of them decided to go with a fully proprietary toolkit in 1994 based on the promise that it may get GPL'd. So Gnome was born.

KDE is not a tech demo of Qt anymore, nothing for Qt to shine about, easily visible in the importance the Qt company sees in KDE, like zero, no importance at all.
KDE can go their own way, its not like there is much innovation in Qt6 anyways. They should focus on making a working desktop like back in the KDE 3 times.

[Alexmitter]

That's not true, I think you should read again the Qt's Contribution Agreement.

I would recommend you to read it again too, because you clearly misunderstood about everything in the CLA. I just hope you haven't signed it yet just to figure out you gave your code away with your rights.