Announcement

Collapse
No announcement yet.

LXDE Desktop Being Ported To Qt

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

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


            • #46
              Qt = the end of lightweight

              I had LXDE running on a machine until about 2 weeks ago when an automatic update (lubuntu) broke it in a really weird way
              and I just didn't have the patience to debug it. I switched the computer to XFCE and I am even happier I've done it now that I read that LXDE is going Qt.
              I have never seen ANYTHING lightweight done in Qt. Like, zero lightweight things in QT. Qt is the fattest pig out there.

              I would love to see more attention given to EFL. That's what I call lightweight! If any of you Qt preachers want to see the real meaning
              of the words light and fast, install bodhi linux and marvel at what Qt will never get close enough to even to see the heels of with the hubble telescope.

              It's sad to see the linux world being crushed under the infinite lards of Qt the fatso king.

              Comment


              • #47
                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.
                This is just utter bullshit.

                Comment


                • #48
                  Originally posted by Yorgos View Post
                  Anybody knows why text menu (first level) is in that language??????

                  Regards,

                  Daniel

                  Comment


                  • #49
                    Originally posted by JS987 View Post
                    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.
                    I think you are both wrong. Windows historically uses UCS-2 and not UTF-16. Also UTF-8 is not significantly longer than UTF-16 for most human readable text, because spaces and punctuation (1 byte in UTF-8, two in UTF-16) eat up any savings for characters which are 3 bytes in UTF-8 but only 2 in UTF-16.

                    Comment


                    • #50
                      Originally posted by dvanzo View Post
                      Anybody knows why text menu (first level) is in that language??????
                      I assume it's the user's native language and the rest is not in "that language" because translation is missing for those strings.
                      Notice, that one entry in the menu on the right is also in "that language" (Chinese?).

                      Comment

                      Working...
                      X