[Interest] High-dpi fixing for Qt 5.5

[Elvis Stansvik]

Den 2 mars 2018 6:05 em skrev "John Weeks" <john at wavemetrics.com>:

Do it in the showEvent()?


Hum, that's a good idea, thanks. I guess the parentage up to a top level
widget will always have been established by then, and that top level window
will always have a windowHandle()?

I guess in my event handler I should also check if the window() has changed
since the last time, and if it has, disconnect and reconnect to the
windowHandle() of the new window().

Curious to know if anyone else is using this approach (showEvent) for
reliable screen change detection.

In any case, how come QWidget itself doesn't have a screenChanged? This
seems to be more complicated than it has to be.

Elvis


> On Mar 2, 2018, at 8:16 AM, Elvis Stansvik <elvstone at gmail.com> wrote:
>
> 2018-03-02 16:26 GMT+01:00 Martins, Sérgio <sergio.martins at kdab.com>:
>> On 2018-03-02 15:21, Elvis Stansvik wrote:
>>>
>>> 2018-03-02 16:18 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
>>>>
>>>> 2018-03-02 15:54 GMT+01:00 Nikos Chantziaras <realnc at gmail.com>:
>>>>>
>>>>> On 02/03/18 16:37, Elvis Stansvik wrote:
>>>>>>
>>>>>>
>>>>>> [...]
>>>>>> How can I (as application developer) get notified of screen changes
of
>>>>>> non-QWindow-backed widgets?
>>>>>
>>>>>
>>>>>
>>>>> There seems to be two ways to do this. One is using one of the QScreen
>>>>> signals:
>>>>>
>>>>>  http://doc.qt.io/qt-5/qscreen.html
>>>>
>>>>
>>>> Hm, I should have made my question more clear.
>>>>
>>>> The typical way I've seen is to connect to the screenChanged signal of
>>>> the closest ancestral QWindow (window()->windowHandle()).
>>>>
>>>> But, I've found that it's not reliable for certain widgets/certain
>>>> platforms to do e.g:
>>>>
>>>>    QTimer::singleShot(0, [this]() {
>>>>        connect(window()->windowHandle(), &QWindow::screenChanged,
>>>>                this, &MyWidget::handleScreenChanged);
>>>>    });
>>>>
>>>> in my constructor, because depending on how the widget is constructed,
>>>> the parentage up to a top-level window may not have been established
>>>> yet, even if I do it in a single-shot timer like this.
>>>
>>>
>>> I should clarify this: What I mean is that I've seen situations when
>>> window()->windowHandle() is 0 here, even if the widget is constructed
>>> with a full parentage up to a top-level widget.
>>
>>
>> Hi,
>>
>> Call QWidget::create() on your top-level constructor, and it will ensure
it
>> it has a QWindow
>
> Thanks, that's one way of doing it, but reading further, it seems
> QWidget delays doing this for a reason. E.g. see the docs for
> Qt::AA_ImmediateWidgetCreation, which I could also use to tell Qt to
> call create(..) immediately during construction. That attribute is due
> to be removed in Qt 6 though.
>
> I don't think I like the idea of jumping the gun on QWidget here and
> calling create(..) myself.
>
> Surely there must be some way to reliably know when a widget is moved
> to another screen (or anoter top-level window), short of hooking up to
> internal events?
>
> Elvis
>
>>
>>
>> Regards,
>> --
>> Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer
>> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - The Qt, C++ and OpenGL Experts
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-Johnm Weeks

_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180302/5a95da07/attachment.html>