[Development] Proposal to deprecate the amazing QApplication::globalStrut

[Volker Hilsheimer]

> On 5 Dec 2019, at 20:05, André Pönitz <apoenitz at t-online.de> wrote:
> 
> On Thu, Dec 05, 2019 at 06:12:53PM +0100, Giuseppe D'Angelo via Development wrote:
>> Il 04/12/19 12:56, Volker Hilsheimer ha scritto:
>>> IIRC, then I added that in the early Qt 2 days, anticipating that with
>>> Qt/Embedded we might see our widgets landing on touch screens “any moment
>>> now”. The idea was to have a global setting that ensured that widgets and
>>> other interactables (such as menu items, list items, checkbox markers etc) are
>>> at least x,y pixels large.
>>> 
>>> Well, the world has moved on, and the value has never been consistely used in
>>> styles or widgets anyway.
>> 
>> Ignoring for a moment the rest of the discussion: does such a value _make sense_
>> in the first place?
>> 
>> Qt-provided styles always tried to follow the OS native style, even in the
>> sizing of the controls. Arbitrarily resizing controls has always been possible,
>> but generally doing that either violates the guidelines of the native style
>> (e.g. making a push button 100px high) or breaks the widget altogether (making a
>> push button 5px high).
>> 
>> In this light, what's the idea of a global minimum size useful for? A native
>> style should rightfully completely ignore it. A non-native style could have it a
>> as a tunable parameter, but then, actually, it could have _any_ amount of
>> tunable parameters (e.g. have a minimum size for buttons, a minimum size for
>> labels, etc.).
>> 
>> Does anyone have more insights?
> 
> I have no insight, but I can imagine scenarios where e.g. visually impaired
> would like to increase minimum size of UI elements also for desktop applications
> wihout necessarily applying some global scaling to all elements.
> Not matching native style is certainly a minor issue in this context.
> 
> That's pure speculation though, and at least in the Qt Creator context
> I am not aware that such a request has ever been made, and I doubt that
> the current two(!) uses of QApplication::globalStrut() would be sufficient
> to meet such need accidentaly.
> 
> Andre’


The raison d’être for globalStrut was Qt/Embedded on Sharp Zaurus (it was added for Qt 2.2), and IIRC Matthias wanted to make it easy to “port” Qt *(and KDE) UIs to such Qt/Embedded devices. We only had widgets, and we had the style API from Qt 2 (which was completely different); there was no need for animations, touch was with stylus or fingernail, accessibility was barely a thing even on Windows.

With the benefit of hindsight, the globalStrut design was already then dubious; instead of requiring every QWidget::sizeHint implementation to respect the globalStrut, the layout engine might have been the right place for this.

When we introduced the “new” Qt 3 QStyle API, things became worse; sub controls would need to respect the globalStrut as well for “interactable elements” like a spinbox’s up/down button. But the reason why we moved to Qt 3’s QStyle API again was Windows XP and macOS introducing completely new requirements for styling, and in those pixmap-based styles, a globalStrut makes no sense (as Giuseppe points out).

Today, we have QtQuick for designing touch-friendly UIs. And if you build a widget-based UI for a touch screen, then you probably want a dedicated style for that as well (you at least don’t care about native styles; I suppose you can just reimplement QFusionStyle and return expanded metrics).

If you build for desktop, your users will want native look’n’feel, and they'll use that environment’s accessibility feature if they need magnification. I would imagine that the last thing users with need for assistive technologies need is every application introducing a different way to become useable for them.



Volker

PS: The discussion on how QStyle could become more property-driven/declarative perhaps belongs into a different email thread.