On Wed, Dec 4, 2013 at 12:37 PM, Mitch Curtis <[email protected]> wrote:
> On 12/04/2013 11:47 AM, Sletta Gunnar wrote:
>> QWidget has the exact opposite problem. Layouts, styles and rendering
>> happens in pixel units while fonts are sized in point size. This is also a
>> problem when moving between platfoms as the pixelsize of a point has a
>> different definition on each platform. When running widgets on a hidpi
>> screen, the fonts are usually huge compared to spacing, lines and icons. In
>> addition to looking quite ugly it easily breaks the layout scheme set up by
>> the application because the text takes up too much space.
>>
>> As long as one sticks to one unit type through the application everything is
>> fine. Mixing leads to problems.
>>
>> Just thinking out loud:
>>
>> Sticking to pixels makes it possible for the application developer to make
>> the right decision based on what he/she wants to achieve. Layout out
>> relative to millimeters can quite easily be done by providing supporting
>> logic in Qt.
>>
>> If we added conversion functions for inch(), cm(), mm(), points() to
>> QQuickItem, it could look up its current window/screen object and figure out
>> the relationship between each unit for the screen the item is on and just
>> set that. The app can then layout in the unit space it prefers with
>> information readily available.
>>
>> Text {
>> font.pixelSize: cm(0.5);
>> anchors.left: parent.left
>> anchors.margins: cm(0.25);
>> }
>>
>>
>> Making them functions makes it impossible to listen for screen changes which
>> in turn trigger dpi changes so they would have to be properties...
>>
>> Text {
>> font.pixelSize: 0.5 * cm;
>> anchors.left: parent.left
>> anchors.margins: 0.25 * cm;
>> }
>>
>> The properties would look up the item's window and then the screen and do
>> the calculation from there so no extra memory for each item to store the
>> properties. And since they don't change all that often, the added
>> calculation is a negligible overhead. When the item is not associated with a
>> window, it will have to use the OS definition of a point instead, usually 72
>> or 96.
>>
>> Just an idea.
>>
>> -
>> Gunnar
>>
>
> That's a pretty cool idea! It would make it so painless to design stuff
> for different screens' DPIs.
I'm confused.
I thought we has pointSize for that reason, no?
To me it sounds like two different ways to accomplish the same thing.
Also, if i'm setting a font.pixelSize i'm expexting pixels to be
drawn. adding a "* cm" makes that moot since the real pixels that will
be drawn are calculated based on whatever cm is.
In other words, don't use pixelSize for it. Just making up a name now,
but how about something like this:
Text {
...
font.realSize: 0.5 cm
...
}
seems more readable to me and gives me the expectation that the font
is going to be 0.5 CM (per char).
>
>> ________________________________________
>> Fra: [email protected]
>> [[email protected]] på vegne
>> av Thiago Macieira [[email protected]]
>> Sendt: 3. desember 2013 18:09
>> To: [email protected]
>> Emne: Re: [Development] OpenGL drivers
>>
>> On terça-feira, 3 de dezembro de 2013 10:27:24, Thomas Hartmann wrote:
>>> Hi,
>>>
>>> we really should think about introducing em or percent for font sizes.
>>>
>>> But non pixel size fonts create a lot of problems for complex layouts.
>>
>> QWidget has worked with that for 15 years, so I don't accept that as an
>> excuse. We have anchor layouts in Qt Quick, which are a lot more powerful
>> than
>> the grids and spacers that we used in QWidget.
>>
>> Desktop support does not require pixel perfection. It does require scaling
>> over widely different resolutions and DPIs, though -- from 1366x768 to
>> 3200x1800, for example.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>> Software Architect - Intel Open Source Technology Center
>> _______________________________________________
>> Development mailing list
>> [email protected]
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
