[Development] Qt5 missing features
Alan Alpert
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:
Button {
anchors.margins: 5000
backgroundColor: "fuchsia"
}
> 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
either :(
> * 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 [1] I can't use it because Android has another (IMHO smarter)
> approach [2], 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 [3], 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
> followed[4]:).
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.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
More information about the Development
mailing list