On 18/02/16 12:05, "Development on behalf of Hausmann Simon"
<development-bounces+lars.knoll=theqtcompany....@qt-project.org on behalf of
simon.hausm...@theqtcompany.com> wrote:
>Hi,
>
>
>(1) Do I understand your question correctly in the sense that you're wondering
>if 5cm would still produce a 5cm dimension on the screen regardless of the
>scale factor? Then the answer is yes :)
>
>
>(2) At first glance I do like that idea. Any other opinions?
The problem with this is to know what the percentage relates to. Percentages
come from CSS, where this is usually (but not always) defined as the
corresponding property in the parent element.
What I’m afraid of with a CSS like model is that percentages will require quite
some additional logic in the parser (and knowledge about individual properties)
to know what the percentages are supposed to match against. Even if we define
this as always relating to the same property name in the parent item, this
creates some semantic difficulties, as the right hand side of the binding
expression implicitly depends on the name on the left hand side.
Cheers,
Lars
>
>
>
>
>
>
>Simon
>
>
>________________________________________
>From: Ирина Flora <ritt...@gmail.com>
>Sent: Thursday, February 18, 2016 11:57
>To: Hausmann Simon
>Cc: development@qt-project.org
>Subject: Re: [Development] Scalable UIs in QtQuick (take 2)
>
>I like it!
>
>
>Some questions though:
>* Does (2) include coverage for cases like 5cm ?
>* Could we have a solution for writing `width: 90%` instead of `width:
>parent.width * 0.9` as well?
>
>Regards,
>Konstantin
>
>
>2016-02-18 14:50 GMT+04:00 Hausmann Simon
><simon.hausm...@theqtcompany.com>:
>
>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
>
>
>
>
>
>
>
>
>
>
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
