No announcement yet.

LXDE Desktop Being Ported To Qt

  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by chithanh View Post
    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.
    Windows NT based systems since Windows 2000 use UTF-16, older Windows, and SQL Server use UCS-2 (some UTF-16 awareness was added to SQL Server 2012). The point that has been largely missed is that compared to UTF-8, UTF-16 and UCS-32 are much faster to interpret. Compare what strlen would have to do in each. UCS-32 -> bytes / 4. UTF-16 -> bytes / 2 + number of (even/odd depending on endian) bytes that match 0x1101xxxx. For UTF-8 you have to do something like count high 1s in current bit before first 0, jump 1 plus the number of 1s and add that number to the counter until we've reached the end.

    Edit: Also assigning a safe buffer to fit a certain number of characters would use more space, even though the resulting string will probably use less.
    Last edited by TheCycoONE; 07-04-2013, 05:04 PM.


    • #62
      Originally posted by skriticos View Post
      You forgot Fox Toolkit and FLTK.
      • 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.

      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.

      Edit: Of course, I would enjoy to see people produce alternatives.
      Are you sure about Clutter?
      Lots of stuff still to do.
      Still plenty of non-trivial commits.
      Since cogl was made into a separate project in 2011 that may've greatly eased the development burden on the clutter devs.
      Fact of the matter is that clutter may not have a great deal left to do, but I'm only guessing.


      • #63
        Originally posted by Thaodan View Post
        Hmm, PCman said porting from GTK2-> Qt is easyer than porting to GTK3.
        That seems very unlikely. To my knowledge, any code that compiled without deprecation warnings on the newer Gtk+2 versions stands a pretty good chance of compiling with little or no modifications on 3.x.

        During the Gnome 2.x to 3.x transition, most of the core Gnome apps supported compiling against both, with a ./configure flag to select one or the other. Migration consisted pretty much of fixing code to not use deprecated functions, adding a few ifdefs to cope with the few cases where the API was incompatible, then eventually dropping the 2.x support once everything was stable on 3.x.

        Of course, the key detail there is "deprecated API". If your Gtk 2.x code makes heavy use of interfaces that have been discouraged for years on 2.x, then you *will* have compatibility issues due to those interfaces being removed in 3.x. But if your 2.x code is in pretty good condition, the porting effort should be negligible.
        Last edited by Delgarde; 07-04-2013, 06:58 PM.


        • #64
          It occurs to me that if LXDE is moving to QT, and Canonical have built a QTMir backend, that means future LXDE should be able to run natively on Mir with minimal effort.


          • #65
            Originally posted by mangecoeur View Post
            It occurs to me that if LXDE is moving to QT, and Canonical have built a QTMir backend, that means future LXDE should be able to run natively on Mir with minimal effort.
            It won't. Face it, no one wants anything to do with Mir.


            • #66
              Originally posted by dee. View Post
              It won't. Face it, no one wants anything to do with Mir.
              Except, you know, all the people at canonical, and all the people using their software - which easily represents the biggest chunk of the desktop linux market (in anticipation: no, distrowatch numbers do not represent market share). And being the most popular means attracting the most software and driver support (c.f. Steam support, and GPU driver updates tailored to go with it). If you make a DE and you're not paying close attention to this trend, you're not doing your job very well.

              Although strictly speaking, the aim is that the vast majority of users won't need to have anything to do with Mir, they'll just get a desktop that works. When was the last time you bought a computing product based on its display stack technology?

              All i was saying in any case was that if you build a desktop on QT5 it should run on mir whether you plan to or not, that's the point of QT be cross platform to begin with.


              • #67
                Originally posted by dvanzo View Post
                Anybody knows why text menu (first level) is in that language??????
                Because "LibreOffice" is called "LibreOffice" in Asia too. I've never seem the actual name of a project translated. If that happened, people wouldn't have a clue what software is installed.


                • #68
                  C++ is not that much bigger or slower than C, it may be a few KB bigger from templates, but the abstractions it buys vs a C implementation far outweigh the couple of milliseconds of C run time vs C++.

         for an example of why C++ is not slower, it also shows code size can be smaller and be more memory efficient and even be faster from better use of abstractions and without doing needles memory management for correctness and bugs to help develop actual features vs fixing mindless C bugs.

                  Also Just because KDE is big and kind of slow and bloated doesn't mean one bit that the UI framework used to build it is bad and bloated. That is 100% the fault of the KDE devs for not caring about perf and is in no way the fault of the Qt framework.


                  • #69
                    Originally posted by mangecoeur View Post
                    It occurs to me that if LXDE is moving to QT, and Canonical have built a QTMir backend, that means future LXDE should be able to run natively on Mir with minimal effort.
                    No, because a WM/desktop is a different beast from a regular application. Applications can be ported to Mir by porting their tookits, but the DE has much more integration with X - if you're going to manage windows, you need to know what a window is on the platform you're running.

                    That's why most of the fuss around KDE is over the Kwin component, not over KDE as a whole. Porting a simple KDE-based app to Mir or Wayland is no big deal once Qt and other underlying libraries have support, but porting a WM (or WM-like code such as a task-bar) requires lower-level code to actually know about all the windows that need managing. A toolkit generally doesn't help much with that.


                    • #70
                      Well the UI framework's base language used does not imply a bloated nature of the resultant product. C & C++ are equivalent in terms of speed, and the only reason why KDE is slow and bloated is because the KDE dev's coded it that way without performance in mind and only functionality.

             is a popular comparison of languages and that shows that C++ is not slower nor nescessarily more bloated. Usually it's abstractions help code size and speed.

                      So just because KDE is slow and big doesn't mean one bit that the programs coded in Qt must share the same trait as slow or bloated, its 100% dependant on the implementation, not the UI framework.
                      Last edited by HeavensRevenge; 07-04-2013, 11:26 PM.