LXDE Desktop Being Ported To Qt

[bwat47]

You're right. The GTK+ apps sit nicely along with Qt apps in KDE but when you launch a Qt app say in Gnome it is a pain to look at.

its more the other way around, QT will automatically adapt to the GTK theme when launched in gnome, but GTK will not automatically adapt to the QT theme when run in KDE. In KDE you have to use a hardcoded "oxygen" GTK theme for any sort of integration. QT apps look fine in gnome because QT automatically adapts. If QT apps are looking poor in your gnome desktop, perhaps your system is not configured correctly (I believe you need the libgnomeui package installed for QT's gtk theme adapting to work, and you also need a matching GTK2 theme because ATM QT can only adapt to GTK2 themes, but most GTK3 themes come with a matching GTK2 version anyway.)

For example here is smplayer on my gnome 3 desktop: http://i.imgur.com/1YA7nab.png

[Awesomeness]

Isn't this slightly redundant with RazorQT being developed?

No, both teams cooperate.
The chance of both projects merging is high.

[F i L]

Gotta admit that i'm happy to see more linux projects switch to Qt. So that we have less fragmentation, and because, while I haven't spent a ton of time comparing the two at all, judging by the new Qt 5.1 videos it looks like Qt is the superior project both in features and cross-platform support. Qt also feels a bit more efficient to me, but I don't have any facts to back that up.

[peppercats]

Isn't this slightly redundant with RazorQT being developed?
You'd think they would just stay with GTK2 since LXDE is meant to be(afaik) a low-system requirements DE and not really as full-featured as say, Cinnamon.

[oleid]

So I think no sane person disagrees that Qt is a fine tool-kit, as is GTK+ (or maybe GTKMM -- I never used that). But I still fail to see a sensible reason for the switch of the tool-kit. I got the impression, that the developer started to like Qt and then decided it would be fun to port the pcmanfm.

GTK3 is no way worse than GTK2 -- at least the XFCE developers think that way [1]. The whole point of LXDE is going easy on resources. Qt uses not less resources than GTK2 (and with [1] not less than GTK3), so there is no gain. To make things worse, there is no plan to port all the applications which form LXDE to Qt, so you end up using both tool-kits. I know that disk space and memory are cheap nowadays, however, this is not the point of LXDE.

To sum it up: I don't question the tool-kit decision, I simply question the motivation and the outcome.

[1] http://forum.xfce.org/viewtopic.php?id=6685 -- last post

[oleid]

Equivalent functionality exists for GTK, but has been rejected by the GTK devs. That's why GTK apps always look ugly when running in KDE and you have to port Qt themes to GTK.

To be fair, the Qt theme wrapper you are talking about is quite buggy. Also, I think it is not unproblematic to include something which loads a C++ library in a C library.

The proper solution would be a common theme engine, shared between different toolkits - something which was tried once, yet failed due to a lack of interest on both sides.

[Awesomeness]

Focusing on Qt, it's a huge monster that includes an ungodly amount of NIH, starting from their own strings and containers, onwards to their own 3d engine (not even kidding) and much more.

Qt is modularized, not huge.
You can build modules on whatever technology you like. And considering that Qt is the first toolkit of its kind, all other toolkits are NIH?

[JS987]

Taking QString as an example, we can quickly see things that are better about QString compared to standard strings:
1. It is guarenteed to be in UTF-16. Standard strings? *shrugs*

UTF-16 is bad thing as it takes 2 times more memory than UTF-8 for ASCII text.
If application has UTF-8 as input and output, which is usual on Linux, 2 unnecessary conversions are needed (UTF-8 => UTF-16 => UTF8)

[pingufunkybeat]

You're right. The GTK+ apps sit nicely along with Qt apps in KDE but when you launch a Qt app say in Gnome it is a pain to look at.

It's exactly the other way around. Qt automatically adopts the current GTK theme if running inside GNOME. The GTK theme engine was mainlined a long time ago.

Equivalent functionality exists for GTK, but has been rejected by the GTK devs. That's why GTK apps always look ugly when running in KDE and you have to port Qt themes to GTK.

This is not surprising, since the main reason GTK exists is to kill off Qt.

[dee.]

SDL isn't a widgets library. It abstracts some (quite low-level) primitives gamedevs usually need. So, say, you can have framebuffer and can draw to it. Without bothering self to know what graphic system actually handles it and how it works. However there is catch. Neither it meant for "usual" applications development, nor it provides widgets set on it's own. So it have to be someting else that implements widgets. Games usually implementing some custom dialogs/widgets/... on their own. It's okay to have custom widgets in games as they usually themed to match game look and feel rather than OS look and feel. But if you're about to write some application, there is trouble on the way. You have to implement all controls yourself (or use some quite low-level lib to do so) and then .. then you can't easily match look and feel of other apps. Since SDL does not knows about GTK. Qt/KDE, Enlightenlemt or whatever and their themes, etc. So it will be really custom-looking programs. It's okay in special cases like games but will not work well for applications.

I know all that. I've never claimed anything contrary. I classify it with other toolkits because it's in the same position in the software stack, between the display server and the application - as an abstraction layer that abstracts away all the lower elements. Yes, it's meant primarily for games, but so what? Every other toolkit also has some niche where they function best.

Not every application needs a mouse-controlled GUI with widgets. If your application is a game that only has a simple menu with "new game", "options" and such, using even something like GTK would be overkill, and wouldn't suit the purpose very well.