HIG and components API

[Marco Martin]

On Friday 09 October 2015, Aleix Pol wrote:
> 
> One thing I really like about the Material ones is that even if they
> provide a Button.qml component, they also provide the style for it and
> base their button on the one in QtQuick.Controls. This way, one can
> have code using QtQuick.Controls and have the correct look and feel
> without invoking explicitly the used components.

for the components that are in the "default set" we should probably try to use 
the qt ones (at least for applications that aim to be multiplatform)
even tough there will always be the future problem of qtquickcontrols2 (i was 
toying with the idea of still making them support styles, but this time by 
playing with import paths rather than using loaders, to not lose the speed 
improvements)

> 
> At a more general level, I think it's ideal if the higher level
> components provide semantic properties (i.e. toolbar, menu) so that
> the controls can adapt by themselves into the situation, rather than
> expecting the application to anchor properly.
> To make a parallelism, this is what made QMainWindow so useful and why
> we ended up using it in almost every QtWidgets application.

true.
the thing is that this probably can go only so far, as higs can require as 
they already do, components that don't have anything to do with the default 
ones are needed, so an extension becomes needed. You see also in that material 
set there are only an handful of components based of the qt ones, all the rest 
is custom made.

That's another reason why I think our higs and components shouldn't be that 
different from something that could work on Android, because either developers 
will use them for one app port that will work on both plasma mobile and 
android, or they are pretty much dead on arrival (and i wouldn't really have 
much motivation to write them eh)

-- 
Marco Martin