[Development] Scalable UIs in QtQuick (take 2)

[Gerry Boland]

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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160224/999d5cc7/attachment.sig>