[Development] Qt5 missing features

Alan Alpert alan.alpert at nokia.com
Thu Apr 12 03:00:30 CEST 2012


On Wed, 11 Apr 2012 19:25:41 ext BogDan wrote:
> >> - platform theme APIs, current APIs are good but not enough, BTW
> >>"KeyboardSchemes" enum doesn't seems to used and IMHO doesn't contain
> >>very cross platform values :). For several months I struggle to create a
> >>style plugin for Android, I manage to create the support for a few
> >>classic widgets and I found that the work I did can not be used also for
> >>QML ones. I believe it is a huge waste of time to do the same job twice
> >>in two different ways. IMHO both QML and classic widgets should use a
> >>single theme manager to draw the widgets, of course every single
> >>platform should be able to create its own
> >
> >You might want to take look at the QML desktop components[1], which uses
> >QStyle to draw. Never mind the "desktop" label - they really are QStyle
> >components.
> 
>   We checked QML desktop components, we also had endless discussions which
> one ( desktop, symbian or meego) should be picked as starting base for
> Android QML components, the problem with QML desktop components is that
> not all controls are touch friendly (e.g. lists, editbox, etc.), even they
> have Android look the feel is not the right one. As I said, I believe is a
> waste of time to have 3 completely different ways to draw QML components
> (desktop, symbian and meego) + one for classic widges. If a theme manager
> will do this job (draw the control, provide default style attributes e.g.
> min/max size, palette, font style & size, etc.) you'll get rid of a lot of
> double work, so you'll end up with two QML components implementation, one
> for pointer devices (desktop, N900, etc.) and one for touch devices (N9,
> etc.), the classic widgets will uses the same theme implementation for
> their controls and to get default style attributes. I don't believe
> current QStyle is enough to do this job, probably a new theme manager
> should take its place, some work in this direction is already done in
> QPlatformTheme, it just needs a little bit more love :) !

One thing I don't understand in this discussion is this theme manager concept 
(like QStyle). As far as I can see, the theme manager approach works by having 
a system with functions that are reimplemented to provide all the instructions 
needed to draw standard controls, so each new 'platform' implements a new 
theme manager and the standard controls use that.

Why exactly do we need this level of indirection, when each platform could 
just write their own 'standard controls' and bypass the manager entirely? The 
only case I'm aware of is so that you don't have to alter the code, just 
running on another platform uses 'native' looking controls. But surely that 
could also be solved in a simpler way (like multiplexing plugins)?

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks



More information about the Development mailing list