[Development] Qt5 missing features
alan.alpert at nokia.com
Thu Apr 12 11:17:57 CEST 2012
On Thu, 12 Apr 2012 17:46:21 ext BogDan wrote:
> > From: Alan Alpert <alan.alpert at nokia.com>
> > To: development at qt-project.org
> > Cc:
> > Sent: Thursday, April 12, 2012 6:20 AM
> > Subject: Re: [Development] Qt5 missing features
> > On Thu, 12 Apr 2012 11:28:43 ext Lincoln Ramsay wrote:
> >> On 04/12/2012 11:00 AM, ext Alan Alpert wrote:
> >> > One thing I don't understand in this discussion is this theme
> > manager
> >> > concept (like QStyle).
> >> ...
> >> > Why exactly do we need this level of indirection
> >> Because of this:
> >> import Widgets 1.0
> >> As opposed to this:
> >> //import MeeGoWidgets 1.0
> >> //import SymbianWidgets 1.0
> >> import DesktopWidgets 1.0
> >> If there was a "standard API" defined for a
> > "components" and each
> >> platform provided something that was source-compatible with this API
> >> then that would work too (without indirection) but I haven't seen
> > anyone
> >> suggesting that a platform's "components" should adhere to
> > some
> >> "standard API".
> > I suggest it :) . It's a de-facto standard already if you can simply
> > comment
> > in the appropriate import.
> >> People are coming at this from a "one source, multiple targets"
> >> viewpoint, which clashes with QML's "one source, one target"
> > design. I
> >> suspect that people do not want to maintain otherwise
> >> virtually-identical .qml files for each target platform just because
> >> the components have a different import, or a different name for an
> >> element.
> > This doesn't require a theme manager abstraction. It could be handled
> > with a
> > Widgets import that resolves to MeeGoWidget,SymbianWidgets or
> > DesktopWidgets based on runtime platform. (this approach does also
> > require the 'standard API'
> > you mention, but that's still not a theme manager - it requires quite
> > different actions to make it a reality)
> A theme manager will make the things much more simpler and clear for the
> user and when it comes to add support for other platforms.
> Let me try explain more:
> From user perspective:
> * AFAIK currently there is no easy way to create a custom theme for QML
> controls, so if I want to completely change the look of my controls I
> don't want to rewrite them :) I want to specify simple attributes to the
> theme manager and it should do the magic for me, something similar with Qt
> Style Sheets, of course now you'll say that it was too complex and almost
> nobody use it, I agree that it was complex but something simple must take
> its place, because I believe that something is better than nothing :) !
The theory is that, since QML is a UI specification language, "rewriting" them
in QML is the exact same as specifying simple attributes. It's certainly has
similarities to Qt Style Sheets (but simpler ;) ). Perhaps the 'theme engine'
would be like the custom components in the components labs project, and
platform implementations would look like:
> From developer perspective who wants to add support for another platform:
> * I want to do the style job once for both QML and classic widgets,
> without a theme manager I don't see how it can be done !
I didn't think of this one - good point! I don't see an easy way around this
> * Some platforms have too complex controls to be draw using an existing
> QML implementation, the live example is Android platform where almost
> nothing can be used from existing style implementations, not even
> BorderImage  I can't use it because Android has another (IMHO smarter)
> approach , the image contains all the informations you need to draw it
> properly, it contains padding informations and informations about the
> margins, even the name says it has 9 patches, is not true, it can contain
> more than 9 check , which is great, because you can draw much more
> complex controls with it.
> Probably again you'll complain that it doesn't follow the standard you
What's this 'existing QML implementation' thing? The approach to creating a
custom 'button' in QML can be the same as a custom 'button' with QWidget. It's
as easy to subclass QQuickPaintedItem and draw something as it is to subclass
QWidget and draw something.
Keep in mind - that's a custom widget not just re-theming the button. It might
be more involved that the theme manager approach, but it might also be less if
you have to go to C++ to instantiate a native control anyways.
Nokia, Qt Development Frameworks
More information about the Development