Announcement

Collapse
No announcement yet.

LXDE Desktop Being Ported To Qt

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by schmidtbag View Post
    Isn't Qt5 significantly heavier than GTK+2? The point of LXDE is to be lightweight, and in comparison to Xfce, it is. I used to have an Lxde setup that used about 45MB of RAM when booting to the desktop and I used it daily. I don't see this happening with Qt5.
    Reading the blog post would have answered all of your questions.

    Qt5 is slightly heavier than GTK+2 in their experience, but lighter than GTK3. Since GTK2 is dead and won't be ported to Wayland, LXDE has to move to /something/. Having to choose between Qt5 and GTK3, they picked Qt.


    Qt is not that heavy, BTW. Depends on what you use, and LXDE will only use the minimum they need.

    Comment


    • #17
      Originally posted by schmidtbag View Post
      Isn't Qt5 significantly heavier than GTK+2?
      No.
      Happy now?

      Comment


      • #18
        Originally posted by Awesomeness View Post
        Cairo is no part of GTK. It's an independent project that also works with Qt applications.
        Independent in the sense of: works without GTK+, yes. So is glib and so is pango. Yet, they where created for usage within GTK+ in the first place. That's by the way the charm of the GTK+ eco system: I can use all those projects independent of GTK+, e.g. I can draw my things using cairo and if I eventually choose to create a GUI, I can draw into a GTK+ window without changing a line of code in my drawing function.


        Originally posted by Awesomeness View Post
        Read the added paragraph in the blog post about Razor.
        I did that before writing the post you commented. They talk about possible cooperation. So far, it's reading razor-qt's config file.

        Originally posted by Awesomeness View Post
        Check the LXDE blog. It's all explained there in previous posts.
        Not really.

        Comment


        • #19

          Comment


          • #20
            Originally posted by pingufunkybeat View Post
            Agreed.

            No platform has a single toolkit, not Windows, not OSX, and certainly not Linux.

            What is needed is consistent look&feel and theming. Qt has done this for a long time, automatically adapting to GTK, Mac and Windows themes. GTK refuses to add this functionality, although it exists.

            That's the problem. Make them look the same and let the developers choose whatever they feel more comfortable with.
            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.

            Comment


            • #21
              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?

              Comment


              • #22
                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.

                Comment


                • #23
                  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.

                  Comment


                  • #24
                    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.

                    Comment


                    • #25
                      Key features

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

                      Comment


                      • #26
                        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.

                        Comment


                        • #27
                          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.

                          Comment


                          • #28
                            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

                            Comment


                            • #29
                              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.

                              Comment


                              • #30
                                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.

                                Comment

                                Working...
                                X