LXDE Desktop Being Ported To Qt

[mendieta]

Did they say why they wanted to port to Qt? Considering that there is already Razor-Qt which fills the same niche and considering that a port from GTK+ to Qt amounts to a complete rewrite (a port from GTK+2 to GTK+3 is quite simple btw), the whole plan seems rather pointless.

Not sure of the way. But LXDE is way ahead in terms of completeness. I used razor-qt plus odd bits from all over the place on an aging Mini 9. I needed all these odd bits to complete a desktop. The SSD on that old netbook died, and now i am running Lubuntu from USB, more easily.

Where razor shines is in things like an integrated settings manager where you have all settings (like in KDE). I would hope LXDE-QT would use that sort of integration. That type of consistency is what drew me to KDE years back, as well. I just find it extremely hard to use KDE in resource-limited systems like an older netbook, because of stuff like akonadi and nepomuk, that you cant just disable, at least not with a single switch, like you do with desktop effects.

Cheers!

[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.