[Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

[Stephen Kelly]

> From: doom.ooseventh at gmail.com [mailto:doom.ooseventh at gmail.com] On Behalf Of Jean-Michaël Celerier
> Sent: Friday 22 September 2017 13:25
> To: Stephen Kelly <stkelly at microsoft.com>
> Cc: Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>; development at qt-project.org
> Subject: Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6
> 
> Indeed, this seemed too easy :p 

Right ;p.

> Sligthly related, but the second approach with the coordinates makes me remember
> this bug report (about QML, but the problem space is similar and proposed 
> solutions involved adding units to values): https://bugreports.qt.io/browse/QTBUG-11655

This is a request for physical units.  I mentioned physical units in my previous 
mail, but I don't know how important they are for this design, which is not so much 
concerned about units, as such, but about multiple screens with different DPIs etc.

> > A disadvantage of the QCoordinate approach is that the values are not comparable
> > to each other without a screen. 
> 
> There is also the problem of a single Qt window between multiple screens with 
> different DPI so it'd be at least one screen per coordinate

I think that's out of scope.  Windows API doesn't even allow accounting for 
that.  Maybe you can go low-level and find some work around, but it's not really 
something applications (even outside of Qt) do.

> (maybe even worse if 
> someone wants to use a QCoordinate for computing a distance that would span 
> multiple screens ?)
> 
> > One of the issues raised so far is that this QCoordinate stores only
> > pixels and points, 
> 
> shouldn't this be implemented as a variant instead ? (I mean, Qt6 *will* 
> require C++17, right ? :p) 

Nope. The point is that *both* pixels and points must be stored.  std::variant 
is a sum type.  That's not what's needed here.

Thanks,

Stephen.