Page 3 of 12 FirstFirst 12345 ... LastLast
Results 21 to 30 of 112

Thread: LXDE Desktop Being Ported To Qt

  1. #21
    Join Date
    Jul 2013
    Posts
    73

    Default

    Quote Originally Posted by dee. View Post
    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?

  2. #22
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,994

    Default

    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.

  3. #23
    Join Date
    Jan 2013
    Posts
    1,446

    Default

    Quote Originally Posted by skriticos View Post
    • 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.

  4. #24
    Join Date
    Jun 2012
    Posts
    293

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

  5. #25
    Join Date
    Nov 2012
    Posts
    53

    Default Key features

    Quote Originally Posted by skriticos View Post
    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...

  6. #26
    Join Date
    Jun 2012
    Posts
    293

    Default

    Quote Originally Posted by dee. View Post
    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.

  7. #27
    Join Date
    Jun 2012
    Posts
    119

    Default

    Quote Originally Posted by curaga View Post
    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.

  8. #28
    Join Date
    Dec 2012
    Posts
    52

    Default

    Quote Originally Posted by oleid View Post
    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

  9. #29
    Join Date
    Jun 2012
    Posts
    119

    Default

    Quote Originally Posted by 0xBADCODE View Post
    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.

  10. #30
    Join Date
    Jan 2013
    Posts
    1,446

    Default

    Quote Originally Posted by 0xBADCODE View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •