Announcement

Collapse
No announcement yet.

LXDE Desktop Being Ported To Qt

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

  • #31
    Originally posted by pumrel View Post
    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.

    Comment


    • #32
      Originally posted by ShadowBane View Post
      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)

      Comment


      • #33
        Originally posted by curaga View Post
        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…

        Comment


        • #34
          Originally posted by pingufunkybeat View Post
          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.

          Comment


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

            Comment


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

              Comment


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

                Comment


                • #38
                  Originally posted by peppercats View Post
                  Isn't this slightly redundant with RazorQT being developed?
                  No, both teams cooperate.
                  The chance of both projects merging is high.

                  Comment


                  • #39
                    Originally posted by pumrel View Post
                    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

                    Comment


                    • #40
                      Originally posted by oleid View Post
                      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!

                      Comment


                      • #41
                        Originally posted by JS987 View Post
                        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)
                        Yes but most of the rest of the basic multilingual plane is shorter or equivalent length in UTF-16, and encoding/decoding is much simpler which could make for faster string operations. Also Qt is cross platform, and Windows e.g. standardizes on UTF-16 - to have portable programs they would have to deviate from one or the other. Actually I think almost everyone/everything uses UTF-16 or UCS-32 for in memory representations of unicode strings (though I may be wrong), they're just so much easier to work with.

                        Comment


                        • #42
                          Originally posted by oleid View Post
                          Also, there is a better binding support for GTK compared to Qt, simply because not every language supports the usage C++ libraries - this is true for e.g. Haskell. While there _are_ haskell bindings for Qt, they can't be considered usable.
                          Yeap, pretty much the same situation on D. The GTK bindings are in good shape, while the Qt bindings, while they do exist, they're only for Qt 4 and barely even compile now.

                          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 sympathise with the sentiment, but that's a really poor choice of examples there. WxWidgets is a wrapper around different toolkits anyway, so if there was only one, it would become redundant. Motif is ancient and will be purged once Wayland comes. SDL isn't a widget-based toolkit, and the person you replied to seemed to talk about those first and foremost. Same with Clutter.

                          Originally posted by Awesomeness View Post
                          No, both teams cooperate.
                          The chance of both projects merging is high.
                          Interesting. I see that the desktop background, for one, is the same between both, but then it might be a part of Openbox?

                          Comment


                          • #43
                            Originally posted by TheCycoONE View Post
                            Yes but most of the rest of the basic multilingual plane is shorter or equivalent length in UTF-16, and encoding/decoding is much simpler which could make for faster string operations. Also Qt is cross platform, and Windows e.g. standardizes on UTF-16 - to have portable programs they would have to deviate from one or the other. Actually I think almost everyone/everything uses UTF-16 or UCS-32 for in memory representations of unicode strings (though I may be wrong), they're just so much easier to work with.
                            UTF-8 is 50% longer than UTF-16 for some Asian text, but UTF-16 is 100% longer than UTF-8 for ASCII which is worse. String class should support both: UTF-8 and UTF-16. Glib/GTK is using UTF-8 for strings.

                            Comment


                            • #44
                              Originally posted by JS987 View Post
                              UTF-8 is 50% longer than UTF-16 for some Asian text, but UTF-16 is 100% longer than UTF-8 for ASCII which is worse. String class should support both: UTF-8 and UTF-16. Glib/GTK is using UTF-8 for strings.
                              A classic C byte string in Qt is represented with a QByteArray it has all the same methods as QString it just works on single chars.

                              Comment


                              • #45
                                Originally posted by carewolf View Post
                                A classic C byte string in Qt is represented with a QByteArray it has all the same methods as QString it just works on single chars.
                                You can store 8-bit strings using QByteArray, but classes usually only accept QString which means conversion to UTF-16 is done.

                                Comment

                                Working...
                                X