Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-33138

should QWindow.setScreen() always work?

    XMLWordPrintable

Details

    • Task
    • Resolution: Won't Do
    • P5: Not important
    • None
    • None
    • GUI: Window management
    • None

    Description

      There are a few existing bugs about this: https://bugreports.qt-project.org/browse/QTBUG-31166 https://bugreports.qt-project.org/browse/QTBUG-29252 https://bugreports.qt-project.org/browse/QTBUG-30724 https://bugreports.qt-project.org/browse/QTBUG-4365 https://bugreports.qt-project.org/browse/QTBUG-29251

      Basically QWindow::setScreen() is nearly useless, except that it works sometimes on Windows. The expectations in order of increasing tenuousness could be:

      1) if you construct a QWindow with the targetScreen parameter and then showFullScreen(), it should show on the given screen
      2) if you construct a QWindow with the targetScreen parameter and then show(), it should show somewhere on the given screen even if the geometry is not set
      3) if you construct a QWindow without the targetScreen parameter, then setScreen(), and then showFullScreen(), it should show on the given screen
      4) if you construct a QWindow without the targetScreen parameter, then setScreen(), and then show(), it should show on the given screen
      5) if you construct a QWindow without the targetScreen parameter, then show() (or showFullscreen()) and then setScreen(), it should move to the given screen

      If you want to position a window on a particular screen that participates in a virtual desktop, on OSX and Linux none of those expectations hold true, so you just have to set the geometry. (see the comment in qtbase/tests/manual/qscreen/main.cpp)

      Expectation 5 is the questionable one, because Qt cannot fully expect to control the window manager on every platform. We can probably get to the point (if we aren't already there) that if you request a geometry change it's likely to work, or at least do something "close enough". But we can still question whether it's correct to change the window geometry just by setting the screen - especially if the window is not fullscreen. What should its geometry be then? What if the new screen is much smaller: should the window take up the same percentage of the new screen as it took of the old one? Should it try to keep the same size but shrink to fit if the new screen is too small for that? Should it try to keep the position proportional (e.g. x=102 on the old screen is 10% of the width of a 1024-wide screen, so if the new screen is 640x480 should it have x=64?) And whatever we ask an X11 window manager to do is treated just as a suggestion anyway in the worst case. Window management is not Qt's job, but it's also unreasonable to have setScreen() exist but do something unexpected, or not work at all.

      On a mobile device it seems reasonable to expect that setScreen() could be used to move a window (which is probably fullscreen) onto an external display. It might even be unreasonable to think of the built-in screen plus the external display as a continuous virtual desktop, the way it's usually done on desktops and laptops; if so, then moving the window to the external display by setting geometry doesn't make sense.

      This has become more important because of this potential change: https://codereview.qt-project.org/#change,62091 Before making available a Qt Quick API, we need to agree on what functionality can be guaranteed across all platforms, document it, and make sure it actually works.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              srutledg Shawn Rutledge
              srutledg Shawn Rutledge
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes