LXDE Desktop Being Ported To Qt

[jukkan]

So what would you do to EFL, WxWidgets, Motif, SDL, Clutter and the rest? How exactly would it benefit anything to have less choice of toolkits? How would it "defragment" anything, and how would it ease app development? App developers can already choose whatever toolkit they want, you'd want them to have less choice - how'd that make anything easier?

I didn't mean I'd have the other toolkits extinguished -- but rather that if all major DEs and apps decided to all use Qt, development efforts would be concentrated there and Qt would receive the highest amount of polish. Thus, Qt would be an obvious choice for app developers and as a result we would have consistent look&feel on the desktop.

I'm only speaking about Qt because it's seems to be the most actively developed at the moment.

Counter-question: do you think there is benefit to having multiple toolkits, all solving essentially the same problem, being developed simultaneously -- and if, why?

[curaga]

Feb 19 2013: "No, LXDE will NOT use Qt. Don’t panic!!"
Jul 4 2013: "LXDE Desktop Being Ported To Qt"

That's a very nice turn-coat change, courtesy of the LXDE blog. ^^

Counter-question: do you think there is benefit to having multiple toolkits, all solving essentially the same problem, being developed simultaneously -- and if, why?

They are not solving the same problem. Clutter is about 3d UI, FLTK is about lightness, gtk+ is about C.

Each also has their own pros and cons when you can pick several for your needs.

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. Sure, STL may have been bad 15 years ago, but now you have several free implementations of quality, there is no excuse to duplicate all that in a modern toolkit. For the completely perplexed Jackie Chan-quality stuff like duplicating an entire 3d engine, when there are 10^5 free 3d engines available, that's just plain insane.

Therefore, if you're looking for a toolkit you can understand and debug, and compile in a reasonable time, Qt is not it.

Obviously Qt includes much good sides, and for many projects it's the obvious choice. But you must be aware it's not the end-all-be-all of toolkits.

[dee.]

• WxWidgets: ewww. I wanted to like it, but it has these little bugs all over the place that make it.. well, ewww
• SDL: Now you are mixing cattles with aliens. SDL is a great tool for bringing full screen OpenGL content to a platform (see Steam), but it's not what you'd call a general purpose GUI framework (you know, with input boxes, buttons and all that stuff). It's a layer below.
• Clutter: It's dusty and out of active development.

Not sure about the bugginess of WxWidgets, but the rest is incorrect -
SDL is a cross-platform toolkit for accessing input devices, graphics and sound, it's not a GUI toolkit but it's a toolkit nonetheless, an abstraction layer that sits between the display server and the application - just like GUI toolkits. Its purpose is different, but the mechanism is the same - it's not "a layer below", it's more like "a layer to the side", if you get what I mean.
Clutter is currently used for GNOME and Cinnamon, it's by no means "dusty" or "out of active development" - it's being ported for Wayland, just like GTK.

[0xBADCODE]

They should rename it...

They should rename it. Because.. because Qt is cool, featured and so on. However, Qt is anything but lightweight. In fact it's quite a huge stockpile of libs and Qt programs usually tend to be memory hungry and quite slow. And C++ allows programs to get bloated really quickly.

[Nth_man]

Key features

I like Qt though. It's cross-platform, quite versitale and powerfull and most importantly it's quite clean and nice to work with + it has good documentation.

Yes! That is critical to avoid errors, and to develop better than the competition.

If the developers also have the free/libre software capabilities, and the option of Digia's paid support...

[0xBADCODE]

SDL, Clutter and the rest?

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.

[ShadowBane]

Feb 19 2013: "No, LXDE will NOT use Qt. Don?t panic!!"
Jul 4 2013: "LXDE Desktop Being Ported To Qt"

That's a very nice turn-coat change, courtesy of the LXDE blog. ^^




They are not solving the same problem. Clutter is about 3d UI, FLTK is about lightness, gtk+ is about C.

Each also has their own pros and cons when you can pick several for your needs.

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. Sure, STL may have been bad 15 years ago, but now you have several free implementations of quality, there is no excuse to duplicate all that in a modern toolkit. For the completely perplexed Jackie Chan-quality stuff like duplicating an entire 3d engine, when there are 10^5 free 3d engines available, that's just plain insane.

Therefore, if you're looking for a toolkit you can understand and debug, and compile in a reasonable time, Qt is not it.

Obviously Qt includes much good sides, and for many projects it's the obvious choice. But you must be aware it's not the end-all-be-all of toolkits.

Qt duplicates the standard library in many places due to the ability to add features, make working with Qt more consistant (naming conventions, conventions about how things can be used,) and the ability to make performance guarentees (such as the copy on write mechanics that are used by Qt.)

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*
2. QStrings are guarenteed to use copy on write. Standard strings may or may not.
3. QString has QStringBuilder (the % operator on strings) to reduce the overhead of string + string2 + string3. C++ strings? You have to do multiple allocations.
4. There are a lot more manipulation functinos for QString than std::string.

[Ouroboros]

Not really.

Do you have selective sight, or are you just lazy? I think PCMan explained himself pretty well.
He's not saying Qt > GTK+; he's basically saying YMMV depending on the project and it's goals.

His options were (going by his blog post):

1) Port to GTK+3 and try to retain GTK+2 compatibility
2) Port to Qt which is slightly heavier than GTK+2 but lighter than GTK+3 and is easier to work with (in his personal opinion) and doesn't break compatibility every minor release.

I, however, need to admit that working with Qt/C++ is much more pleasant and productive than messing with C/GObject/GTK+.
Since GTK+ 3 breaks backward compatibility a lot and it becomes more memory hungry and slower, I don?t see much advantage of GTK+ now. GTK+ 2 is lighter, but it?s no longer true for GTK+ 3. Ironically, fixing all of the broken compatibility is even harder than porting to Qt in some cases (PCManFM IMO is one of them).
So If someone is starting a whole new project and is thinking about what GUI toolkit to use, personally I might recommend Qt if you?re not targeting Gnome 3.
Update 2013-03-27:
I got some feedback about the toolkit choice above. Don?t get me wrong. I?m not saying that gtk+ is bad and did not intend to start a toolkit flame war. If you?re going to use python, C#, or other scripting language, gtk+ is still a good choice due to its mature language bindings.
Vala is attractive initially, but after trying it in real development, you?ll see the shortcomings of this approach. Because it sometimes generates incorrect C code that still compiles, we got some really hard-to-find bugs. So we need to examine the generated C code to make sure it does things right. This takes much more time than just writing plain C code myself. Besides, the generated C code is not quite human-readable and debugging becomes a problem. Another issue that?ll hit you is the problems in the library bindings. Though there exists many vala bindings for various C library, their quality is uncertain. Finally, debugging, examing, and fixing the bindings all the time takes even more time and offsets the time saved by using Vala.
To sum up, for compiled binary programs, Qt IMHO is a good choice to consider if you don?t hate C++.

- http://blog.lxde.org/?p=990

[ShadowBane]

They should rename it. Because.. because Qt is cool, featured and so on. However, Qt is anything but lightweight. In fact it's quite a huge stockpile of libs and Qt programs usually tend to be memory hungry and quite slow. And C++ allows programs to get bloated really quickly.

Bad programmers tend to allow programs to get bloated. There is nothing in particular about C++ that makes programs in it be bloated. Also, Qt is a rather efficient library, but Qt4 isn't very modular, which means the first Qt application you run brings in a ton of debendancies through shared libraries. This is mostly addressed by Qt5.

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