[Development] QWindow::setScreen() and QQuickWindow

Agocs Laszlo Laszlo.Agocs at digia.com
Wed Apr 16 13:37:24 CEST 2014


Hi,

Option #2 is good enough, isn't it? QWindow::setScreen() already states "If the window has been created, it will be recreated on the \a newScreen". This could be extended with a note about the visibility, like in QWindow::create(): "the window remains hidden until setVisible() is called".

As for the QWidget world, QWindow::setScreen's behavior is completely in line with QWidget::setParent: "The widget becomes invisible as part of changing its parent, even if it was previously visible. You must call show() to make the widget visible again". I am a bit confused with regards to the examples given as there is no QWidget::setScreen().

Cheers,
Laszlo

________________________________________
From: development-bounces+laszlo.agocs=digia.com at qt-project.org [development-bounces+laszlo.agocs=digia.com at qt-project.org] on behalf of Rafael Roquetto [rafael.roquetto at kdab.com]
Sent: Wednesday, April 16, 2014 1:20 PM
To: Fabian Bumberger
Cc: Qt Project Development Mailing-List
Subject: Re: [Development] QWindow::setScreen() and QQuickWindow

Hello Fabian, all.

Like you, I also suspect that the fact that QWidget stays on the screen has to
do with the 4 platform windows or something like that. All I know is that,
once setScreen() is called on a QWidget, it gets to the point where it makes
the QWidgetBackingStore dirty, issuing an update request and for some reason
at that point the code that handles the update (repaint) request figures that
the visibility of the widget is set to 'true' (don't ask me why, since
destroy() had already been called at this point), thus repainting the widget.

IMHO, we can either:

    1) add some more code to QQuickWindow so that when setScreen() is called,
    it sets a flag called, for instance, "restoreVisibility == true", that
    tells QQuickWindow to create itself already with a true visibility.

    2) Add to the documentation that show() needs to be called again after a
    call to setScreen(), as you suggested.

Does anyone have any further thoughts on this?

Thanks,
Rafael
On Mon, Apr 14, 2014 at 04:35:56PM +0000, Fabian Bumberger wrote:
> Hi Rafael,
>
> I was looking at this today and I am also a bit puzzled about why the QWidget stays on the screen.
> It might have something to do with the 4 platform windows that are created for each top level QWidget.
>
> Does anyone btw. know why this is necessary?
>
> About the behaviour of "setScreen". I too find it a bit awkward that it hides the window. If we can't change
> this any more, than it should at least be mentioned in the documentation.
>
> Fabian
> ________________________________________
> From: development-bounces+fbumberger=blackberry.com at qt-project.org [development-bounces+fbumberger=blackberry.com at qt-project.org] on behalf of Alan Alpert [416365416c at gmail.com]
> Sent: Saturday, April 12, 2014 2:16 AM
> To: Rafael Roquetto
> Cc: Qt Project Development Mailing-List
> Subject: Re: [Development] QWindow::setScreen() and QQuickWindow
>
> On Fri, Apr 11, 2014 at 12:56 PM, Rafael Roquetto
> <rafael.roquetto at kdab.com> wrote:
> > Hello,
> >
> > I have been investigating an interesting bug (using QNX as the platform for
> > Qt). Here is a brief summary:
> >
> > (all code inside main() and before app.exec())
> >
> >     QQuickView v;
> >     v.setScreen(someSecondScreen);
> >     v.show(); // works as expected
> >
> > but
> >
> >     QQuickView v;
> >     v.show();
> >     v.setScreen(someSecondScreen); // window is never shown
> >
> > Is this the expected behavior?
>
> Yes. setScreen expects to destroy the backing window and recreate it,
> so it passes onto users the expectation that they will have to reset
> all window properties afterwards.
>
> I'm not sure what QQuickView should do, but in the declarative case
> where you might have a "Window { visible: true; visibility:
> Window.FullScreen }" it would be expected to reset all the properties
> to what's in QML. I doubt it does that yet, and that's a bug ;) .
>
> > The reason this happens is because
> > QWindow::setScreen() calls destroy(), which triggers setVisible(false).
> > Afterwards, it calls create() but create() never bothers to display the window
> > again. In other words, it does
> >
> >     QWindow::setVisible(true) //coming from show();
> >     QWindow::setVisible(false) //coming from setScreen() -> destroy()
> >
> > For some reason beyond my knowledge, QtWidgets do not suffer for this bug,
> > i.e.:
> >
> >     QWidget w;
> >     w.setScreen(secondScreen);
> >     w.show(); // works!
> >
> > and
> >     QWidget w;
> >     w.show();
> >     w.setScreen(secondScreen); // also works
> >
> > I digged a bit inside the QWidget code and it also follows the pattern of
> > having setVisible(true) followed by setVisible(false) called, just like in the
> > QQuickWindow case. However, something is happening that in spite of that the
> > widget is being shown regardlessy.
> >
> > Any thoughts? Comments?
>
> Last time I was playing around with multiwindow support (about a year
> ago), QNX was the only platform where setScreen worked reliably. So
> the strange stuff happening could be related to the platform
> implementation, as we have no other platforms to compare it with. It
> also makes it hard to determine the "correct" multi-screen API, when
> there's no clear picture of how it would work on the majority of
> platforms.
>
> --
> Alan Alpert
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin

Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions



More information about the Development mailing list