> From: doom.ooseve...@gmail.com [mailto:doom.ooseve...@gmail.com] On Behalf Of > Jean-Michaël Celerier > Sent: Friday 22 September 2017 13:25 > To: Stephen Kelly <stke...@microsoft.com> > Cc: Jean-Michaël Celerier <jeanmichael.celer...@gmail.com>; > development@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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
