Announcement

Collapse
No announcement yet.

Qt5 Will Work On HiDPI Support For More Platforms

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

  • Qt5 Will Work On HiDPI Support For More Platforms

    Phoronix: Qt5 Will Work On HiDPI Support For More Platforms

    Morten Sorvig on behalf of Digia is working towards bringing high-DPI (HiDPI) scaling support to more platforms...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Well, it looks like this is one area, at least, where gtk is in better shape than qt on Linux.
    Seriously, this is why having a native toolkit makes sense. Ideally, it results in a lean codebase because there is less need fit abstractions necessary in order to support outset platforms.
    I do wish EFL war that toolkit for Linux, however, even if it is cross platform.

    Comment


    • #3
      Originally posted by liam View Post
      Well, it looks like this is one area, at least, where gtk is in better shape than qt on Linux.
      Seriously, this is why having a native toolkit makes sense. Ideally, it results in a lean codebase because there is less need fit abstractions necessary in order to support outset platforms.
      I do wish EFL war that toolkit for Linux, however, even if it is cross platform.
      Yes because win32 was so awesome on Windows...

      Here's the thing, abstractions aren't just necessary to deal with outset platforms but to also deal with extensibility and change management. For an example let's say you've got a display server we'll call it "X", that has been the standard for forever with no real competitors so your native toolkit uses it directly with no real abstraction, eventually the developers of X decide that X is broken by design and now they're going to create an awesome new Display Server let's call it "Wayland". Now not only does everyone want to use this hot new display server but you still need to support X users through the transition. So now what do you do? You're going to have to write an abstraction supporting both display servers on top of massive amounts of refactoring of your codebase as a result holding up everyone who wants to use Wayland despite Wayland having been ready for use for a few years instead of just writing another backend for the abstraction.

      Comment


      • #4
        Originally posted by Luke_Wolf View Post
        Yes because win32 was so awesome on Windows...

        Here's the thing, abstractions aren't just necessary to deal with outset platforms but to also deal with extensibility and change management. For an example let's say you've got a display server we'll call it "X", that has been the standard for forever with no real competitors so your native toolkit uses it directly with no real abstraction, eventually the developers of X decide that X is broken by design and now they're going to create an awesome new Display Server let's call it "Wayland". Now not only does everyone want to use this hot new display server but you still need to support X users through the transition. So now what do you do? You're going to have to write an abstraction supporting both display servers on top of massive amounts of refactoring of your codebase as a result holding up everyone who wants to use Wayland despite Wayland having been ready for use for a few years instead of just writing another backend for the abstraction.
        ... Actually i was thinking of cocoa, but, yeah, win32 did pretty well for a, what, 18 years old api.
        Likewise, I think we can afford to break guarantees every 31 years, in your particular example.

        Comment


        • #5
          Originally posted by liam View Post
          ... Actually i was thinking of cocoa, but, yeah, win32 did pretty well for a, what, 18 years old api.
          If by pretty well you mean became a technically unsound utter mess... Whereas properly abstracted toolkits like Qt continue to be nice and clean while being both wide and deep.

          Originally posted by liam View Post
          Likewise, I think we can afford to break guarantees every 31 years, in your particular example.
          Yes and hold up adoption of a platform for years as you spend time doing what you should have done when you designed it in the first place, instead of spending a fraction of the time hooking up a backend. Additionally by keeping a proper level of abstraction between you and the underlying OS it can be made to easily run on other OSes which expands the userbase target and means more developers working on your code.

          HiDPI support in Qt would probably actually be even further off if Qt didn't support OS X and iOS because HiDPI screens are still a rarity outside of macs and mobile devices.
          Last edited by Luke_Wolf; 24 May 2014, 04:59 AM.

          Comment


          • #6
            Originally posted by Luke_Wolf View Post
            If by pretty well you mean became a technically unsound utter mess... Whereas properly abstracted toolkits like Qt continue to be nice and clean while being both wide and deep.


            Yes and hold up adoption of a platform for years as you spend time doing what you should have done when you designed it in the first place, instead of spending a fraction of the time hooking up a backend. Additionally by keeping a proper level of abstraction between you and the underlying OS it can be made to easily run on other OSes which expands the userbase target and means more developers working on your code.

            HiDPI support in Qt would probably actually be even further off if Qt didn't support OS X and iOS because HiDPI screens are still a rarity outside of macs and mobile devices.
            I had no idea that qt provided api guarantees for nearly 20 years! That's hugely impressive. It's especially impressive that they don't break api between major releases, the release periodicity of which far exceeds the lifetime of win32.
            So I assume my app written with well abstracted qt 1 will work seamlessly on Wayland, and what's more, even better than gtk 3.16 app?
            Lastly, as gtk doesn't have to support other platforms, it can focus on Linux and, consequently, had hidpi support before the FAR SUPERIOR BESTEST DEVELOPED ADVANCED QT on Linux.

            Comment


            • #7
              Originally posted by liam View Post
              I had no idea that qt provided api guarantees for nearly 20 years! That's hugely impressive. It's especially impressive that they don't break api between major releases, the release periodicity of which far exceeds the lifetime of win32.
              So I assume my app written with well abstracted qt 1 will work seamlessly on Wayland, and what's more, even better than gtk 3.16 app?
              Lastly, as gtk doesn't have to support other platforms, it can focus on Linux and, consequently, had hidpi support before the FAR SUPERIOR BESTEST DEVELOPED ADVANCED QT on Linux.
              I never promised that being properly abstracted meant you had to do no work, instead that work is made minimal (particularly as regards change management). For instance an abstraction known as the Model-View-Controller design pattern which is very common to apply to applications (as it naturally fits the concept of an application) allows you to accommodate changes in the data backend, business logic, or user interface without having to touch the other two parts of the program, and one common application of MVC is to have multiple user interfaces to a program with minimal effort. As a result even if your Qt1 application doesn't work with Qt5, you could scrape the UI off and spend however long it takes to design the interface in QtCreator and depending upon the complexity write maybe 100 lines of actual code (ignoring the boilerplate) hooking it up to the controller.

              Woo so something that is just a graphics toolkit beat a platform abstraction framework to HiDPI support before HiDPI support was really necessary as a thing.

              Meanwhile Qt has been further developing it's competitor to WPF (QtQuick/QML) with getting things like QtQuickControls and Qt3D working and getting Android and iOS support up to being first class citizens, along with getting KDE Frameworks 5 all set up with some parts upstreamed into Qt5 but who needs that?

              Comment


              • #8
                Originally posted by liam View Post
                I had no idea that qt provided api guarantees for nearly 20 years! That's hugely impressive. It's especially impressive that they don't break api between major releases, the release periodicity of which far exceeds the lifetime of win32.
                They may not have API guarantees between major releases, but at least within major releases they do.

                Originally posted by liam View Post
                Lastly, as gtk doesn't have to support other platforms, it can focus on Linux and, consequently, had hidpi support before the FAR SUPERIOR BESTEST DEVELOPED ADVANCED QT on Linux.
                Or, if you look at it another way, despite Qt having to worry about many platforms, they were able to implement HiDPI support about a year before gtk+, and had HiDPI support on Linux very soon after gtk+ did (and apprently gtk+ support is pretty basic at this point). If being able to focus on just one platform really made that big of a difference, you would expect gtk+ to be way ahead on this, but they are behind overall, and just a tiny bit ahead on their only major target platform.

                Comment

                Working...
                X