On Dec 4, 2013, at 12:34 PM, Thomas Hartmann <[email protected]> wrote:
> Hi,
>
> what is already possible is to read the font.pixelSize property for a
> specific point size or just using the implicit size of a text item.
> One main problems with layouts following physical units (pt, cm), is
> that icons (all pixel based resources) have to be scaled accordingly (or
> have a "random" size). And most icons are still pixel and not vector
> based and scale badly.
>
> Eventually on high dpi screens it would make sense of course, to ditch
> all pixels and only use vector bases resources. But this is not our
> reality, yet.
Even with vector based resources you’ll probably like to use different ones
depending on how much device pixels you have for rendering a specific icon. A
32x32 pixel icon can contain much more details than a 16x16 pixel icon, instead
of just being a "nicely rendered" 16x16 icon. Or do vector based formats
actually have support for that?
Br, Eike
> Kind Regards,
> Thomas Hartmann
>
> Am 04/12/2013 11:47, schrieb Sletta Gunnar:
>> 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
>>
>> ________________________________________
>> 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
>>
>
>
> --
> Thomas Hartmann
> Software Engineer
> Nokia, Qt Development Frameworks
>
> Digia Germany GmbH
>
> Rudower Chausse 13, 12489 D-Berlin
>
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B,
> Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
>
> Email: [email protected]
>
>
> Digia Germany is a group company of Digia Plc,
>
> Valimotie 21, FI-00380 Helsinki Finland
>
> Visit us at: www.digia.com
>
> ------------------------------------------------------------------
>
> PRIVACY AND CONFIDENTIALITY NOTICE
>
> This message and any attachments are intended only for use by the named
> addressee and may contain privileged and/or confidential information. If
> you are not the named addressee you should not disseminate, copy or take
> any action in reliance on it. If you have received this message in
> error, please contact the sender immediately and delete the message and
> any attachments accompanying it. Digia Germany GmbH and Digia Plc do not
> accept liability for any corruption, interception, amendment, tampering
> or viruses occurring to this message.
>
>
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
--
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
