HIG and components API

[Aleix Pol]

On Fri, Oct 9, 2015 at 6:28 PM, Marco Martin <notmart at gmail.com> wrote:
> On Thursday 08 October 2015, Aleix Pol wrote:
>> > Possible problems:
>> > * the two panels may be always instantiated, even if empty this may be
>> > not optimal memory and loading time wise
>> > * toolbar api still no defined
>> > * could some content for the global drawer be there by default? do we
>> > leave a blank slate? even the hig examples are very heterogeneous
>> > https://techbase.kde.org/Projects/Usability/HIG/GlobalDrawer
>>
>> Maybe you'd like to take a look at the qml-material components [1].
>> I've looked into them, they seem high quality and have some
>> interesting concepts.
>
> also (as an author of an application with an android port)
> what do you think our components should have over those or something self-made
> in order for somebody to chose ours when considering porting a KDE application
> to mobile?
> what would you look for?

As I've said before, I really cannot make up my mind on how to look at
the QML Components problem altogether.

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.

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.

Did I answer your question?
Aleix