On Fri, Oct 9, 2015 at 6:28 PM, Marco Martin <notm...@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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
