Hey Simon, I can try offering the Ubuntu Touch perspective on units with QML (sorry if late, was busy for MWC).
We created a units system for our QML apps, called grid unit: units.gu(x). We did this as we needed the ability to scale the UI for different devices, from phones with highDpi screens to lowDpi monitors. DevicePixelRatio didn’t exist at the time, and when it appeared, it was too limited unfortunately, as we did not trust that non-integral values would work reliably in QML. And also such values break QWidget-based apps. Grid units are implemented as you predicted: as a context property. It can change at runtime too, as with our convergence strategy, we need apps to rescale dynamically at runtime. (We also have "device pixels" units.dp(x), which will map directly to your proposed logical pixels, which is good. But that is primarily used for things to be 1 or 2 pixel wide, like line thickness). We've implemented special image loaders that will respect this unit system. This all works, and we've found it clunky but not too troublesome so far. There are disadvantages however: 1. overhead of function call of a context property for every size specifier 2. multimonitor situations, we would like to have different scales on individual monitors. Context property not allowing that, so we need to rethink that. 3. does conflict with DevicePixelRatio somewhat. I've worked hard to make them work together, but the complexity is unpleasant, and I’ve still not solved all issues. 4. there are a few other internal non-visual tweaks Qt does which depends on DPR, but naturally not our grid unit value. This is why 3. above (marrying DPR and grid units) is being done at all, else we’d just ignore DPR for longer. So I'd be very happy to see some work on adding some concept of units to QML. Perhaps we are asking too much to allow registration of a custom unit system at QmlEngine startup? We'd love to enable app authors to write: Rectangle { width: 10gu; height 5gu; } and have the value runtime updatable. I understand that would make parsing harder though, and that our requirements are probably more complex than the norm. Instead, I thought about embracing your proposed logical/physical pixels approach. Our requirements would mean we have to allow logical pixels to be more varied than x2, x3... of the physical pixels - i.e. need float DPR values. However one of the fundamental ideas of the grid unit was to help UI layout consistency - it helps developers line-up their UI elements to be visually appealing. To look best, elements should be positioned on pixel-boundaries to ensure sharp edges. So units.gu always returns an integer. But using a pure float scale with your proposed logical pixels (or just today’s QML with a float DPR), I fear that something like: Rectangle { color: “red”; width: 10; height: 10; x: 5 } with a 1.5x scale, will be positioned at 7.5px and so will not have a sharp left/right edge. So unfortunately I fear your physical/logical pixels proposal is not of much use to us on Ubuntu Touch. We can use them to replace our units.dp "device pixels" thing, but our primary scaling system: grid units, won't work with it. Thanks for looking into this nonetheless. -Gerry On 18/02/16 10:50, Hausmann Simon wrote: > Hi, > > A little while ago Lars and I proposed to introduce physical units in the QML > language for use in QtQuick. The idea was to make it easier to write user > interfaces that adapt to different display resolutions by "pinning" your UI > to physical dimensions. For example you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } > > and the image size in physical pixels would scale accordingly to always > produce a 5cmx5cm profile image on the screen. The proposed units included > "px", which was really an alias for nothing. > > We've had some very good discussions around this at last year's contributor > summit as well as in smaller face-to-face discussions. The main feedback I > recall was that this would seem like a nice feature on paper but in practice > people create their resolution independent interfaces using the current > "pixels" and a scale factor that they introduce in a qml file or as a context > property. That's another way of saying that perhaps the feature wouldn't > really find any use, which is fair :). Instead the desire was expressed that > making it _easier_ to scale "logical" pixels in the application would perhaps > be better. > > So today during a discussion another idea came up: > > (1) In order to make it really easy to scale "logical" pixels without having > to introduce your own context property or factor in a .qml file that you > multiply everywhere, we could turn the regular "pixels" in QtQuick into truly > logical pixels that scale with an application wide (or window wide) factor. > So Image { width: 100 ... } will scale automatically from 100 logical pixels > to maybe 200 physical pixels on a x2 display. This assumes the availability > of API to change this mapping. > > (2) In the events where you still _want_ to use physical pixels, you could > use "px" units. > > So at first nothing would change for app developers at all because we map > logical pixels to physical pixels. But > if you'd like to, you could opt into changing this mapping and having a > relatively easy fallback to physical pixels using for example the "px" unit. > We might as well offer the other physical units anyway, that probably causes > little to no harm. > > What do you think? > > Simon > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development