QML Themeing
-
[quote author="aalpert" date="1334653834"]
That was kind of the original idea for Qt.labs.components, but I'm not sure this follows all the requirements. There seems to be a desire for a set that transcends the desktop/mobile divide - this divide is what's leading me to believe we really need a new and more flexible solution.
To bridge that gap, you need more than a Qt.labs.components.nativeMobile and a Qt.labs.components.Desktop. You need one native set that switches between all of them.
[/quote]
IMHO the UI design for a desktop application is totally different from a mobile application (cell phone target). So no need to strictly follow a common API (e.g. the page stack concept popular in mobile applications is of no use on the desktop).
I'd rather say that a set that transcends the desktop/tablet divide would be great because a well designed tablet interface can also work very nice in a desktop application. Just look at the latest Mac OS X and Windows 8 concepts.
-
bq. My team in INdT has been researching about theming/styling of Qt Components.
I’ve synthetised what we’ve been done and some of our aims and ideas:
http://codecereal.blogspot.com.br/2012/04/qml-themingstyling.htmlHi, the code is now updated and can be downloaded from git://code.openbossa.org/projects/qtquickstyles.git
We have found some bugs that were impeding the module to run properly. We have fixed it and integrated on the master.
Regards
-
[quote author="njeisecke" date="1334655499"][quote author="aalpert" date="1334653834"]
That was kind of the original idea for Qt.labs.components, but I'm not sure this follows all the requirements. There seems to be a desire for a set that transcends the desktop/mobile divide - this divide is what's leading me to believe we really need a new and more flexible solution.
To bridge that gap, you need more than a Qt.labs.components.nativeMobile and a Qt.labs.components.Desktop. You need one native set that switches between all of them.
[/quote]
IMHO the UI design for a desktop application is totally different from a mobile application (cell phone target). So no need to strictly follow a common API (e.g. the page stack concept popular in mobile applications is of no use on the desktop).
I'd rather say that a set that transcends the desktop/tablet divide would be great because a well designed tablet interface can also work very nice in a desktop application. Just look at the latest Mac OS X and Windows 8 concepts.
[/quote]I originally thought that the difference between the 'meta-platforms' was too great for anyone to care either. But remember, the email thread started with a Qt port to Android (presumably, it wasn't just for the tablet androids). I'm getting the impression that people want a component set large enough to create useful UIs, which literally work anywhere. This isn't for creating a commercial quality UI that looks and feels native, this is about hacking up an application and running it on your phones + tablets + desktop immediately. The UI would be a few ugly buttons mashed into a grid ( I get the feeling this was a key selling point of the Qt Layouts) and may even look like baby vomit by comparison with native apps. But you wrote a technically-functional application that runs on all your platforms in five minutes, which is sometimes what's most important.
I'd welcome hearing people's feedback on that directly of course, instead of just making assumptions here about what people what.
There are also some theoretical grounds for truly-cross platform APIs. What if page 'stacks' were tabbed widgets on desktop? What about something more dynamic, like that google fragments API that BogDan pointed too (but simpler, their docs confused me) or perhaps Qt style resizing layouts are needed for rescaling elements (but simpler, and with more smarts than just resizing things to 4x). But I'm not sure of concrete proposals here that would give a basis for a common API.
-
Applications designed for desktop space won't work on the mobile form factor. I've tried that for fun. Not only does it look ugly, the interface is simply unusable. So I really don't see the value of a common component set.
You can develop a very clean interface to your application business logic in C++ and use that from Qml quite naturally. The language gap (C++ -> Qml) forces you to make that clean separation, so creating a totally different UI for the mobile and desktop/tablet use case is now really easy and people should be educated about that.
Of course the API for basic components like buttons, text editors etc. should be compatible between mobile and desktop/tablet. Not for enabling cross platform code but simply to make it easier for the developer to remember stuff.
-
[quote author="aalpert" date="1334731153"]
I originally thought that the difference between the 'meta-platforms' was too great for anyone to care either. But remember, the email thread started with a Qt port to Android (presumably, it wasn't just for the tablet androids). I'm getting the impression that people want a component set large enough to create useful UIs, which literally work anywhere. This isn't for creating a commercial quality UI that looks and feels native, this is about hacking up an application and running it on your phones + tablets + desktop immediately. The UI would be a few ugly buttons mashed into a grid ( I get the feeling this was a key selling point of the Qt Layouts) and may even look like baby vomit by comparison with native apps. But you wrote a technically-functional application that runs on all your platforms in five minutes, which is sometimes what's most important.
[/quote]
[quote author="aalpert" date="1334731153"]
I'd welcome hearing people's feedback on that directly of course, instead of just making assumptions here about what people want.
<snip>
[/quote]We ship (embedded) touch-panel and (non-embedded) desktop applications with the same code, and the same physical Qt style-sheet file. Interface is totally different, but the style sheet establishes "common" settings for colors, fonts, etc. It works. We need this going forward with Qt/QML.
I think two different discussions are trying to take place in this discussion:
(A) A desire for a common styling interface/convention for cross-platform ease-of-development; Ability to style/emulate "Native" is secondary (primary goal is for application-developers to create a common-code-base with minimal effort that "basically-works" on multiple target platforms).
(B) A desire for a styling interface/convention that enables highly-specialized application-specific or platform-specific styling. Primary is the expectation for extremely close "native" presentation (native-to-target-device-and-target-operating-system), or the need for artistic expression or application "branding". Support for lowest-common-denominator (e.g., across-all-target-platforms) is quite "secondary".
Recall that Qt has historically delivered HIGH value in providing (A). The current "fracture" from desktop-into-mobile, and the fracture within mobile (including new paradigms for multi-touch and gesture) also cause real market need for (B).
IMHO, we can design QML styling interfaces or conventions to support both. It's not yet obvious to me how to do that, we have to be smart, but I really believe it can be done. That's why I think these discussions are very important.
[quote author="njeisecke" date="1334735328"]Applications designed for desktop space won't work on the mobile form factor. I've tried that for fun. Not only does it look ugly, the interface is simply unusable. So I really don't see the value of a common component set.
[/quote]This is partly true. However, we are shipping "embedded-touch" and "desktop" with the exact same widgets, so it is partly untrue.
[quote author="njeisecke" date="1334735328"]
You can develop a very clean interface to your application business logic in C++ and use that from Qml quite naturally. The language gap (C++ -> Qml) forces you to make that clean separation, so creating a totally different UI for the mobile and desktop/tablet use case is now really easy and people should be educated about that.Of course the API for basic components like buttons, text editors etc. should be compatible between mobile and desktop/tablet. Not for enabling cross platform code but simply to make it easier for the developer to remember stuff.[/quote]
We agree. This (C++ -> QML) abstraction is a major strength of this paradigm, separating the business-logic-and-APIs from the dynamic (GUI) presentation, and also why we are so interested in the QML direction. This is a "neutral" assertion to my separation of the (A) and (B) expectations (above).
You also make a good point, that if we could establish common-interface/conventions, then code will be "more familiar" to different developers working on different platforms, or in the different arenas of "desktop v. mobile". That has (very) high training/productivity/scaling/adoption value.
The styling issue, IMHO, is absolutely and entirely and totally about "data-density". Some concepts are truly "universal" -- a "hot-spot" that that user can somehow "hit" -- that's a button. A "date" that the user can "modify" -- that's some kind of "date-edit-thingie". These may be "lowest-common-denominator", or presented specific to a given-platform-convention.
QML can do both. It should not be a big deal. We're just talking about the "convention" or "API" where we can describe/extend/customize the presentation for (A) and (B) use cases.
Of course, "build" should not be a big deal either: All you need to do is compile-to-object, then link. How hard can it be? (<joke, we know how hard that can be.>)
It is possible we have one convention/API for (A), and a different for (B). It is possible that while those may be different, that they share a common "root" convention/API. Even better would be if we had the same convention/API for both.
Finally, I think it important to define terms, since IMHO the "solution" MAY be "convention", and MAY be "API":
() "Convention" -- if you tend to do it like this, or name things like this, then your parts will work with other people's parts (think something like "Duck-Typing" where we all just do-and-name-stuff-consistently)
() "API" -- something like INdT's theming/styling of Qt Components, where components are actually made-available-for-use, probably adopted into the common distribution
My guess is we will probably need a little of both "convention" and "API", but it is conceivable that we could use only one-or-the-other for (A) and/or (B).
-
[quote author="aalpert" date="1334653834"]
The real test will be how flexible this approach is to wildly varying platforms. I know the meego components will probably never get updated to a new architecture, but it should be theoretically quite possible to redo the existing QtQuick Components sets using a mixture of the style approach (and a platform specific widgets import for widgets that are custom enough not to be styled).
[/quote]Our main target is to have it working on mobile and desktop platforms, in the future. Currently we are mainly focusing on the Desktop side, due to the lack of desktop components with a native look and feel, but that could also have a different style, implemented by the user, with a minimum effort.
Another motivation was to have Qt5 implementation free of QWidgets.[quote author="aalpert" date="1334653834"]
Is it possible to split it up a little more, like moving the plastique folder out of that repo? It makes no sense in the current concepting phase of course, but one thing I would hope for a new platform styling API is the ability for new platform styles to easily come from outside. I got the impression that a lot of styling details went inside QWidget and friends, when it should all be abstracted out. So this new requirement I just realized is that the platform styles need to be a plugin (or import), as easy to write and swap in as the new QPA architecture.
[/quote]You mean that, if a user wants to use the plastique style, he would write "import PlastiqueStyle 1.0" on his QML file, and would do the same for any other available styles?
If is that what you have meant, I think we could have an hybrid approach, an import that would have all styles and separated imports for each style, that would only load that style.
The big import would have some "default" styles implemented, maybe the same styles that are available trough the QStyle. This way, the user would only make one import and could have all default styles reachable and the application would have the native look and feel. If he wants a different look and feel, he could just use our ApplicationStyle and set the style for each widget, reflecting in all application.
Or he could only import the desired style to his application. -
[quote author="thiago.lacerda" date="1334864314"]
[quote author="aalpert" date="1334653834"]
Is it possible to split it up a little more, like moving the plastique folder out of that repo? It makes no sense in the current concepting phase of course, but one thing I would hope for a new platform styling API is the ability for new platform styles to easily come from outside. I got the impression that a lot of styling details went inside QWidget and friends, when it should all be abstracted out. So this new requirement I just realized is that the platform styles need to be a plugin (or import), as easy to write and swap in as the new QPA architecture.
[/quote]You mean that, if a user wants to use the plastique style, he would write "import PlastiqueStyle 1.0" on his QML file, and would do the same for any other available styles?[/quote]
Actually, no. As a purely hypothetical example, let's suppose that Apple wanted to make iOS a first-tier Qt Platform, complete with a native control set for QML. But then their lawyers forbid putting that code into the qt-project repositories. Could they then ship that with their platform, but not with Qt, while still making "import NativeComponents 1.0" use their platform's native components?
-
[quote author="aalpert" date="1335170025"]
Actually, no. As a purely hypothetical example, let's suppose that Apple wanted to make iOS a first-tier Qt Platform, complete with a native control set for QML. But then their lawyers forbid putting that code into the qt-project repositories. Could they then ship that with their platform, but not with Qt, while still making "import NativeComponents 1.0" use their platform's native components?
[/quote]
With the current implementation, the one that wants to add a new style to the project, can do it just by making his new style class inherits from the QUiStyle base class and return this new style on the getPlatformStyle method (from QUiStyle) when it detects that it is running on such platform.
Since it is on the very beginning of the project, this is the current way. What do you think that could be a more suitable way? -
[quote author="thiago.lacerda" date="1335197206"][quote author="aalpert" date="1335170025"]
Actually, no. As a purely hypothetical example, let's suppose that Apple wanted to make iOS a first-tier Qt Platform, complete with a native control set for QML. But then their lawyers forbid putting that code into the qt-project repositories. Could they then ship that with their platform, but not with Qt, while still making "import NativeComponents 1.0" use their platform's native components?
[/quote]
With the current implementation, the one that wants to add a new style to the project, can do it just by making his new style class inherits from the QUiStyle base class and return this new style on the getPlatformStyle method (from QUiStyle) when it detects that it is running on such platform.
Since it is on the very beginning of the project, this is the current way. What do you think that could be a more suitable way?[/quote]That's certainly fine for the initial prototype. Perhaps later the getPlatformStyle function could check plugin paths for compatible platform styles. But it sounds like this isn't going to be a problem, which is great!
-
I've written an update about our research: http://codecereal.blogspot.com.br/2012/05/qml-themingstyling-update.html