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

[Uwe Rathmann]

Hi Shawn,

> FWIW I did try to make that point during the session, since you 
> weren’t there to do it yourself, that you would like to have 
> something like a table of QVariants instead of only colors (to 
> include things like icons and border line widths and radii), and
> also that the ColorRole enum should be extensible or replaced with 
> something that is extensible (such as a string).

When looking at the current implementation you have a combination of
attributes coming from the widgets ( colors, fonts, ... ) and from
QStyle ( metrics like QStyle::PixelMetric, ... ).

Then you have some code that is located inside of the style, that is
responsible for layouting and rendering the subcontrols from these
attributes.

Whether these attributes are stored in a table as QVariant or somehow
else is a detail of the implementation - the issue I'm interested in is
a system that allows me to extend/replace the number of attributes and
the layout/rendering code in a more flexible way.

Another aspect I'm missing is how to define transitions between states
in an easier way. So I would like to have a system that allows me to set
state depending attributes and some definitions for the state
transitions ( f.e QEasingCurve::Type + duration ), so that the style can
manage the transitions automatically by interpolating between the
attributes.

a)

The system I have implemented in QSkinny splits the layout/rendering
code into different classes. Those are called skinlets - what might
translate to controlDelegate in the usual Qt terminology.

f.e the following code registers/replaces a skinlet for a custom control:

     skin.declareSkinlet< MyControl, MyControlSkinlet >();

Then you can add whatever attributes are used by MyControlSkinlet and
you are done.

Such a system allows to replace/expand/remove the number of controls
being supported by a style in a much easier way than with the monolithic
approach you have in QStyle.

b)

Then I indeed have a table of attributes with colors/metrics/flags +
attributes for the transitions.

The basic idea behind separating the attributes from the delegates is
that setting attribute values is something a GUI designer can do while
creating scene graph nodes ( this is what the skinlets do ) is
definitely a job for an experienced developer.

> I was thinking it would be a good start to add a high-numeric-value 
> QPalette::ColorRole::UserRole and then you could extend that with 
> your own enum for use in your own widgets and styles.

Please allow me to add fonts here as well. All projects I have been part
of in the last decade had a concept of using font roles. You have a
preference dialog where the user can assign specific fonts to given
roles, like f.e Title/Body/...

So I would also raise the question if the inheritance model that is used
for fonts in widgets and QC2 still matches the reality of the applications.

> But what to do instead then?  More work is being done already at
> this time to get QPalette working better in Qt Quick, but maybe we
> should replace it with something else entirely?

With Qt6 we will see fundamental changes in the scene graph and below
and a new QML version. So the controls are actually the only layer of
the Qt/Quick stack, that is not under heavy reconstruction.

The question is how much changes you are willing to do. IMHO it would be
time to move on with the controls too - but can this be done without
major API changes ?

So in the logic of being sensitive with breaking APIs this can only be
done as Quick Controls 3.

Uwe