[Development] Qt5 missing features

[Alan Alpert]

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