On Thu, 12 Apr 2012 17:46:21 ext BogDan wrote: > > From: Alan Alpert <alan.alp...@nokia.com> > > > > To: development@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development