[Development] Qt5 missing features

[Charley Bay]

>
> <snip, "theme" GUI interfaces for QML>
>


> 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. <snip>,
> Let me try explain more:
>


> >From user perspective: <snip, want to re-use controls with different
> themes>
>


> >From developer perspective who wants to add support for another platform
> <snip, re-using controls on new platforms>
>


> 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 :) !
>

_This_.

We have the same code on "touch-interfaces" and desktop.  We need this.
 We're using Qt Style Sheets, and they work ok.  (Could be more elegant,
but is good enough, and it *works*.)

IMHO, it seems like this "theming" and "styling" thing should be so much
*easier* with QML.  But, I'm not seeing approaches (yet) on these lists
that will work for us.

This is not a complaint:  The QML declarative paradigm is new, and we must
think about these theme-issues in a new paradigm.  (This is a very positive
thing, IMHO.)

But, my point:  We need *ANY* "theme/style-convention" that *WORKS*.  I
explored many designs in the "way-way-way" past, and they all worked to
varying degrees of success (so we have lots of options):

http://lists.qt.nokia.com/pipermail/qt-qml/2010-November/001772.html

Summary:  We (internally) are pursuing theming-and-styling through
centralized convention with our QML components.  Because we must enforce
these types of conventions ourselves, things like the "QML desktop widgets"
don't exactly work for us, because they don't follow our theme-conventions.
 (Recall that *by-definition*, "themes/styles" work *only* because
components follow a convention.)  And, we've not fully established what
*should* be these conventions (they are in "flux"), but we *know* we *need*
these conventions.

So, for us, if it can't be "themed", we won't/can't use it.  Period.

YMMV, I'm not-at-all disagreeing with other approaches, and understand why
graphic designers are writing custom QML components for their own purposes,
without centralized options for "themes/styles".  That's not us, though:
 Even for our "highly-custom" applications, we *demand* a single location
to maintain the "default-font-color" for the application.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120412/020799c8/attachment.html>