pixels, dimensions inside and of the widget

[fperillo]

Can you please spend a little time to document in the wiki:

1. how to convert pixels, fonts, spacings described in material.io to qtmaterial
   f.e. in this widget https://material.io/guidelines/components/expansion-panels.html#expansion-panels-behavior and if you scroll above, all the other settings.
2. How TextField determines its dimensions, expecially its height... you draw in the paintEvent but how are you sure you have that space? What if I'd add the error line below the underline? I was expecting a sizeHint, a policy...

Thanks

[Heikki Johannes Hildén]

For the second question; the Text Field component inherits from QLineEdit, so the geometry is controlled from there, except that some extra space is needed for the label. To accommodate this, you'll see on line 98 of qtmaterialtextfield.cpp:

    if (value) {
        setContentsMargins(0, 23, 0, 0);
    } else {
        setContentsMargins(0, 0, 0, 0);
    }

[fperillo]

Ok, so to implement the error message, error line or char counter I should just add some more spacing at the bottom...

[Heikki Johannes Hildén]

Sounds reasonable, but you'll have to give it some trial-and-error most likely. These (counter and error message) could be given their own classes also, to avoid complicating the code in the main Text Field component. Kind of how the label is implemented now if you look in qtmaterialtextfield_internal.cpp and the QtMaterialTextFieldLabel class.

[fperillo]

My question about inside measures regards this data present on material.io:

Font: Roboto Regular 16sp
Height: 56dp
Left avatar padding: 16dp
Right icon padding: 16dp
Text padding, left: 72dp
Top padding: 8dp

How do I translate these measures to Qt? Is 16sp font equivalent to setPointSize(16)? It seems to me that setPointSize(16) is too big of a font...

And 56dp in pixels?

[Heikki Johannes Hildén]

Yeah, I haven't followed this very rigorously. Here is the definition of Android's Density-independent pixel unit, to start with:

Density-independent pixel (dp)

A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way.

The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple:

px = dp * (dpi / 160)

For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels.

My understanding of sp is that it is similar, except that it is subject to a scale factor which depends on the user settings. So in your example, I think (I could be wrong here) that, assuming;

1. a 160 dpi screen is used, and
2. no user scaling is involved

then 16sp would be equivalent to setPixelSize(16) (not point size).

We could introduce some helper methods for doing this conversion, using the QScreen class for example:

qreal dpToPixels(qreal dp) {
    QScreen *screen = QGuiApplication::primaryScreen();
    return dp*screen->physicalDotsPerInch()/160;
}

The bigger question here, however, is how much of this should be determined by the widgets? For example, if the Material design guidelines say that a Flat Button should be exactly x dp high, this is not really how Qt's layout system works. I mean, layouts are designed to be fluid and if we start to set fixed sizes for everything, that would be weird, I think. The way it works now is that a default size is given for fonts and icons, and reasonable size hints are specified in the various QWidget subclasses. One way to think of it is that it would then be up to the user of the library to make sure that the widgets are used in a way that is consistent with the Material guidelines. I don't know if this is the best approach. Do you have any ideas?

[fperillo]

I'm not sure I have a clear idea on how to handle Material widgets in Qt layouts... they are completely different beast with their own peculiarities...

For example List/ListItem are good for a mobile phone screen but would be really strange on a 46" monitor if used full screen as in the mobile... and both screen have the same resolution !!!!!

Material is really nice looking thanks to proper graphical design, and this includes proportions between objects, displacements, font sizes color and opacity. I'd like to adhere as much as possible to the standard and of course leave to the programmer the possibility to modify everything.