Announcement

Collapse
No announcement yet.

LibreOffice 7.0's Qt5 Support To Offer HiDPI Scaling

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

  • LibreOffice 7.0's Qt5 Support To Offer HiDPI Scaling

    Phoronix: LibreOffice 7.0's Qt5 Support To Offer HiDPI Scaling

    The LibreOffice open-source office suite's Qt5 tool-kit integration so far has lacked HiDPI scaling support for dealing with modern high pixel density displays. But adding to the excitement for the LibreOffice 7.0 release later this year is now the Qt5 HiDPI scaling capability...

    http://www.phoronix.com/scan.php?pag...-HiDPI-Scaling

  • #2
    As stated in the commit log: Basically a hack that comes with glitches.

    Why didn’t they just work with the Native GTK instead of causing even greater fragmentation?

    Comment


    • #3
      Originally posted by 144Hz View Post
      As stated in the commit log: Basically a hack that comes with glitches.

      Why didn’t they just work with the Native GTK instead of causing even greater fragmentation?
      This is libreoffice we are talking about.

      https://wiki.documentfoundation.org/...the_Qt_widgets

      There have been on going different debates in it UI design way back to staroffice before open office.

      I guess you are clueless Libreoffice UI system is fragmented state.

      https://docs.libreoffice.org/vcl.html

      Very good read. There are 8 different support toolkits behind libreoffice hiding under the VCL layer.

      There are fun things all basic dialogs in libreoffice are done in gtk ui format files that are then converted to the 8 different backends+. Yes GTK ui files using to make Windows and OS X native dialog windows without any GTK required. Yes those ui format files are also used to make qt dialogs.

      Please take this under consideration at the worst point in libreoffice toolkit fragmentation history is back when it was in openoffice there was 20+ different toolkits and each dialog between them had to be manually updated individually. Compared to the worse part of the history VCL layer fragmentation the current libreoffice is very tidy.

      The usage of the gtk ui files to generate universal dialog windows no matter what one of the 8 toolkits being used is a very interesting feature instead of having to attempt to install the same toolkit on all platforms.

      Well performing cross platform support in a user interface can horrible cause what Libreoffice VCL layer is having both qt and gtk really don't hurt that much behind the VCL layer when you see that libreoffice is generating stuff for 8 different toolkits and having glitch show up between the gtk and qt implementation on Linux(this can be done cheaply on QA server) normally shows glitches to the Windows, OS X and other native backends as well.

      Libreoffice and Apache Openoffice are basically in completely different rings of hell to what most developers expect and what is sanity there is not sanity else where at times. But the insanity of there systems do show some very interesting possible paths forwards.

      Comment


      • #4
        oiaohm Not clueless at all. The Native GTK port is the default and comes with a promise to provide dialogs and UI that works on Wayland. Naturally the dialogs look native for most users on Debian, Ubuntu, Fedora, RHEL, Cent, SLED etc. This is fully backed by Red Hat who got VERY smart people working on this long term.

        Some Qt hacks have come and gone. None with the promise of being wayland ready or long term solutions. This is just fragmentation that leads nowhere.

        Comment


        • #5
          Originally posted by oiaohm View Post
          I guess you are clueless Libreoffice UI system is fragmented state.

          https://docs.libreoffice.org/vcl.html

          Very good read. There are 8 different support toolkits behind libreoffice hiding under the VCL layer.
          Providing alternatives does not equal to fragmentation. The different GUIs are not competing against one another in the sense that each crew would be working on whatever features they find interesting and that there would not be a GUI that acts as a reference to all others.

          Originally posted by oiaohm View Post
          There are fun things all basic dialogs in libreoffice are done in gtk ui format files that are then converted to the 8 different backends+. Yes GTK ui files using to make Windows and OS X native dialog windows without any GTK required. Yes those ui format files are also used to make qt dialogs.
          Well this is only the sensible thing to do: to have a "standard" on which to build on. It doesn't really matter where the XML definitions were borrowed from: e.g. Qt's own UI templates are converted into C++ code in compilation phase and not parsed on runtime. Writing a similar converter for GTK XML definitions is probably a one-man task and low-maintenance.

          Originally posted by oiaohm View Post
          The usage of the gtk ui files to generate universal dialog windows no matter what one of the 8 toolkits being used is a very interesting feature instead of having to attempt to install the same toolkit on all platforms.
          I suppose the driving factor is visual integration with various desktop environments even on Linux alone; KDE vs. Gnome.

          For example Qt has been well-supported on all three primary platforms for over a decade now, so it could've been an easy choice to just base on Qt, drop the VCL layer, and forget everything else. Then again the industry seems to still be in favour of GTK as a reference platform due to its more open licensing with regards to both the past and present.

          Comment


          • #6
            curfew It would not be an easy choice to go Qt besides it looking weird and non-native on most distributions.

            It would set back Wayland adaptation at least 3 years and it would inject CLA right back into a project that fought for a decade to get rid of a CLA predator (Oracle).

            Comment


            • #7
              As soon as I saw Qt5 in the headline, I knew 144Hz would turn it into Qt vs. GTK and troll with CLA CLA CLA CLA...

              Comment


              • #8
                Originally posted by 144Hz View Post
                As stated in the commit log: Basically a hack that comes with glitches.

                Why didn’t they just work with the Native GTK instead of causing even greater fragmentation?
                "Native GTK" yeah, sure.

                Qt apps feel native on most desktops. Be it GNOME, KDE, Windows, macOS or whatever, it will look native.

                In the meanwhile GTK apps look alien on Plasma if you are not using the Breeze theme (and even after using the Breeze theme still looks alien).
                Last edited by tildearrow; 03-10-2020, 05:35 AM.

                Comment


                • #9
                  Originally posted by 144Hz View Post
                  curfew It would not be an easy choice to go Qt besides it looking weird and non-native on most distributions.

                  It would set back Wayland adaptation at least 3 years and it would inject CLA right back into a project that fought for a decade to get rid of a CLA predator (Oracle).
                  STOP ALREADY! Those posts of you get so annoying...

                  Comment


                  • #10
                    Originally posted by tildearrow View Post

                    "Native GTK" yeah, sure.

                    Qt apps feel native on every desktop. Be it GNOME, KDE or whatever, it will look native.

                    In the meanwhile GTK apps look alien on Plasma if you are not using the Breeze theme (and even after using the Breeze theme still looks alien).
                    Eh, Qt apps do not feel native on GNOME.

                    But, no one really cares, because why would you expect them to?
                    Last edited by Britoid; 03-10-2020, 05:48 AM.

                    Comment

                    Working...
                    X