Integrating Qt Quick components in Ministro
BogDan
bog_dan_ro at yahoo.com
Wed Feb 8 07:39:57 UTC 2012
Hi Jon,
Thank you for your tips !
Thanks to Kate tip, I've found that qt already has the needed support to draw a nine patch bitmap [1].
Now the biggest problem I'm facing is to determine where and how big these patches are !
Cheers,
BogDan.
[1] http://developer.qt.nokia.com/doc/qt-4.8/qdrawutil-h.html#qDrawBorderPixmap
>________________________________
> From: Jon <jheron at snappyappz.com>
>To: BogDan <bog_dan_ro at yahoo.com>
>Cc: Kate Alhola <kate.alhola at gmail.com>; "necessitas-devel at kde.org" <necessitas-devel at kde.org>
>Sent: Monday, February 6, 2012 10:55 PM
>Subject: Re: Integrating Qt Quick components in Ministro
>
>
>Excuse me if I am way off track here, I am just a novice!
>However, I stumbled upon this blog about a couple of people who created their own nine-patch lib for blackberry os 7. I thought perhaps this may help with your efforts?
>Here is the post :
>http://www.mobiata.com/blog/2011/10/25/building-the-flighttrack-ui-on-blackberry
>And the lib on github:
>https://github.com/mobiata/BlackBerry-NinePatch
>This is probably of no use but I figured it couldn't hurt to put it out there...
>Cheers,
>Jon Heron
>
>On Fri, 2012-02-03 at 01:13 -0800, BogDan wrote:
>Hi Kate, >> Hi,
>>
>> Excuse me if I'm wrong, but why we don't do the same technique
> as Nokia did with qml components for desktop ? They are using the application
> current QStyle plugin to paint all qml controls ! Is there any reason not to do
> the same thing ?
>
> The model is upside down for Android case for several reasons. I can't agree with you :) ! Before I go further I want to make my self clear: I'm not planning to replace (meego/symbina) qml components with qml desktop components ! > 1: We do not have ready desktop style for Android, that's different
> when Qt can use on desktop system ready made desktop style. I know we don't have one now :).
The idea is to use the same code to paint both qml components and classic widgets.
The easiest way is to create a QStyle and use it in both situations. > 2: We have mobile style already as NinePatch/BoderImage format, what
> do we gain if we do NinePatch->Widget->BorderImage and not
> NinePatch->BorderImage ? QStyle != QWidget ! They are two completely different things ! The role of QSyle is *ONLY* to draw controls, primitives, text, etc. check the documentation [1].
QStyle is USED by qt widgets controls to draw them e.g. QPushButton [2] uses current application style [1] plugins to paint its content [3]. The same thing is doing qml desktop components, button control [4], uses [5] the same style [1] for painting [6]. I checked the implementation of BoderImage and it's using [7] qDrawBorderPixmap [8] global function to draw the image, again I see no problem for us to use it in QStyle plugin :) ! So, instead to use AndroidNinePatchImage->meego_theme_engie->BorderImage[9] to paint your control, you'll use AndroidNinePatchImage->style_plugin->StyleItem [10]. > 3: Mobile components set and graphics is much more rich than desktop
> widgets in mapping AndroidStyle->Widgets->BorderImage we lose a lot
> If current 48 control elements [11] + another 10 complex controls [12], defined in QStyle plugin [1] are not enough we can add 0xFFFFFFF custom controls :) > Better idea is to do mthemedaemon that reads NinePatch Images from
> JSon DB and returns BorderImages, then this class can be used
> rendering both components and widgets. When I briefly checked zip file
> you sent, it won't be a big deal. The large work will be mapping
> names of hundreds image names between Android styles and names used by
> components.
>
> I can do proof-of-concept version of themedaemon if i got just
> function to return named NinePatch from JSonDB, backport of Qt5
> class would be best choice because then we have engine ready for Qt5.
> I don't have resources to do all huge work for mapping
> all theme assets.
> Even it seems an easy solution using current Meego/Symbian architecture for Android, most probably soon we'll face big problems.
IMHO the best solution (even if it seems very challenging) is to create our own qml components for Android, of course we should start from existing implementations and to take the best ideas from all, and, the most important, to keep the API compatible with the existing ones. BTW it seems the common API that Qt Quick component styles should implement is almost done, at least for the most usual components : https://bugreports.qt-project.org/browse/QTCOMPONENTS-200 I don't want to start a flame war here, I just believe we can cooperate and make something useful for all people, even they will use the new qml concept or they will stick with the old widgets. > Kate
> Cheers,
BogDan. [1] http://developer.qt.nokia.com/doc/qt-4.8/qstyle.html [2] http://developer.qt.nokia.com/doc/qt-4.8/qpushbutton.html [3] http://qt.gitorious.org/~taipan/qt/android-lighthouse/blobs/unstable/src/gui/widgets/qpushbutton.cpp#line449 [4] http://qt.gitorious.org/qt-components/desktop/blobs/master/components/Button.qml [5] http://qt.gitorious.org/qt-components/desktop/blobs/master/src/qstyleitem.cpp#line954 [6] http://qt.gitorious.org/qt-components/desktop/blobs/master/src/qstyleitem.cpp#line937 [7] http://qt.gitorious.org/~taipan/qt/android-lighthouse/blobs/unstable/src/declarative/graphicsitems/qdeclarativeborderimage.cpp#line577 [8] http://developer.qt.nokia.com/doc/qt-4.8/qdrawutil-h.html#qDrawBorderPixmap [9] http://qt.gitorious.org/qt-components/qt-components/blobs/master/src/meego/Button.qml#line80 [10] http://qt.gitorious.org/qt-components/desktop/blobs/master/components/Button.qml#line21 [11]
http://developer.qt.nokia.com/doc/qt-4.8/qstyle.html#ControlElement-enum [12] http://developer.qt.nokia.com/doc/qt-4.8/qstyle.html#ComplexControl-enum >>
>>>
>>>
>>> There is the possibility of encapsulating widgets in QGraphicItem (as
> QGraphicWidget), thus allowing them to be used in QML.
>>>
>>> I don't know how these QGraphicWidget's handle QStyle,
> though....
>>>
>>> - Chris -
>>>
>>>
>>> On Thu, Feb 2, 2012 at 14:28, BogDan <bog_dan_ro at yahoo.com> wrote:
>>>
>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>> Yes ! BorderImage seems to be exactly the same thing with NinePatch,
> thanks for the tip !
>>>>
>>>>
>>>> Anyway, as I said before I'd like to have a QStyle plugin
> which paints the classic widget also the qml ones, because it seems classic
> widgets are sill use by a lot of people !
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> BogDan.
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Kate Alhola <kate.alhola at gmail.com>
>>>>
>>>>> Sent: Wednesday, February 1, 2012 10:59 PM
>>>>> Subject: Re: Integrating Qt Quick components in Ministro
>>>>>
>>>>
>>>>> Some quick look comments:
>>>>>
>>>>> On Wed, Feb 1, 2012 at 9:20 PM, BogDan
> <bog_dan_ro at yahoo.com> wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> I have good news on this topic, I manage to check (a
> little bit)
>>>>> Android's source code and to extract, the exact,
> android's look and
>>>>> style informations for a few widgets (buttonStyle,
> editTextStyle,
>>>>> radioButtonStyle, checkboxStyle, etc.) and store them into a
> .json file (check
>>>>> the attachment). Because qt 4.x doesn't come with json
> support, IMHO we have
>>>>> two options:
>>>>>> 1 - to use this [1] qt json implementation.
>>>>>> 2 - or to backport Qt 5.x json implementation (my
> favorite option,
>>>>> because it seems more complex and complete than the first one).
>>>>>>
>>>>>> I need more time to finish the extraction class (which
> will be part of
>>>>> the next Ministro release), so, if someone wants to step in and
> begin the Qt
>>>>> implementation it will be very appreciated !
>>>>>>
>>>>>> To understand how android paints the widgets you have to
> check a simple
>>>>> widget how it's painted. So let's check Button class
> [2], which extends
>>>>> TextView class [3] which extends the View class [4].
>>>>>>
>>>>>> How it works:
>>>>>> - Button class only pass to its super class (TextView)
> the style
>>>>> attribute (com.android.internal.R.attr.buttonStyle)
>>>>>> - TextView class pass the same information to its super
> class (View) then
>>>>> in its constructor (check "public TextView(Context
> context, AttributeSet
>>>>> attrs, int defStyle)" ) extracts text informations
>>>>> (e.g.TextAppearance_textColor,TextAppearance_textSize,
> TextAppearance_typeface,
>>>>> etc.) which are used to draw the text (check onDraw (...)).
>>>>>> - View class in its constructor (check "public
> View(Context context,
>>>>> AttributeSet attrs, int defStyle)") extracts a few
> informations e.g.
>>>>> View_background, View_paddingLeft, etc. which are used to paint
> the basic parts
>>>>> of the widget (e.g. the background).
>>>>>>
>>>>>> If you check the json file, you'll see that there
> are more than one
>>>>> .png files used to paint the background, one for every view
> state (enabled,
>>>>> disabled, pressed, etc.). Android split every .png file into
> nine pieces (it
>>>>> uses nine patch technique [5], [6]) which are used to
> seamlessly resize the
>>>>> widget. AFAIK there is no support for such a thing into Qt, so
> IMHO this is the
>>>>> first thing which must be implemented.
>>>>>>
>>>>>
>>>>> The nime patch looks exactly same than Qt BorderImage (
>>>>> http://developer.qt.nokia.com/doc/qt-4.8/qml-borderimage.html )
>>>>>
>>>>>
>>>>> Also, system that uses different images for different states is
>>>>> exactly same that is used on components
>>>>> meegotouch-button-background-pressed.png
>>>>> meegotouch-button-background.png
>>>>> meegotouch-button-background-selected.png
>>>>> ....
>>>>> and this for all combinations, inverted, disabled ...
>>>>>
>>>>> The problem then comes more than could we do some mapping of
> Android
>>>>> and MeeGotouch states like
>>>>> meegotouch-button-background ->
> buttonStyle_View-background_Enabled.png
>>>>>
>>>>> MeeGocomponents uses mthemedaemon plugin that fetch images, so,
> if we
>>>>> could make just mapping names
>>>>> and json query, we could in theory get theme engine.
>>>>>
>>>>> Symbian components uses svg images , meegocomponents
> borderimages .
>>>>> There is very little
>>>>> difference in component API's. Least what I have used,
> porting on apps
>>>>> were mostly changing import statements
>>>>> and change of some colors.
>>>>>
>>>>> Kate
>>>>>
>>>>>> This weekend I hope to have enough time to create a wiki
> page which will
>>>>> describe the content of the json file.
>>>>>>
>>>>>> Cheers,
>>>>>> BogDan.
>>>>>>
>>>>>>
>>>>>> [1] https://github.com/ereilin/qt-json >>>>>> [2]
>>>>>
> http://www.java2s.com/Open-Source/Android/android-core/platform-frameworks-base/android/widget/Button.java.htm >>>>>> [3]
>>>>>
> http://www.java2s.com/Open-Source/Android/android-core/platform-frameworks-base/android/widget/TextView.java.htm >>>>>> [4]
>>>>>
> http://www.java2s.com/Open-Source/Android/android-core/platform-frameworks-base/android/view/View.java.htm >>>>>> [5]
> http://developer.android.com/reference/android/graphics/NinePatch.html >>>>>>
>>>>>> [6]
>>>>>
> http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch >>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Yes, sadly we have to get our hands very dirty.
>>>>>>> First step is to identify all Qt components then we
> have to find
>>>>>>> Android's corresponding components, then we must
> extract the style
>>>>> &
>>>>>>> look information to a central location (IMHO Ministro
> should do this
>>>>> job), then
>>>>>>> any application which starts will peek this infos from
> that location
>>>>> and use
>>>>>>> them to paint all controls.
>>>>>>> Second step is to check how Android paints the
> controls, here the
>>>>> things will
>>>>>>> become dirty, we have to check
>>>>>>> "frameworks/base/core/java/android/widget/TextView.java"
> from
>>>>> Android
>>>>>>> source code and it seems we have to use a lot of
> private data, I hope
>>>>> the
>>>>>>> Android versions are not so different.
>>>>>>> Third step is to change Ministro in order to extract
> all the infos we
>>>>> need to
>>>>>>> paint our controls.
>>>>>>> Fourth step is to create a QStyle plugin (which
> will be used by QML
>>>>> as well)
>>>>>>> which loads the data extracted by Ministro and use it
> to paint the
>>>>> controls. If
>>>>>>> the extract procedure is very fast (less than 10ms), I
> doubt it will be
>>>>> that
>>>>>>> fast :), we can skip the third step and extract the
> data directly in
>>>>> QStyle.
>>>>>>> Fifth step, if everything works, we must get drunk
> !
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> BogDan.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> While I don't agree on "almost all
> applications have the
>>>>> same
>>>>>>> look" (as far as I can see, the only fully common
> UI element is
>>>>> the
>>>>>>> menu/toolbar combo), I respect your choice.
>>>>>>>>
>>>>>>>> The first step would be to define what is the
> "Android
>>>>> style". Is
>>>>>>> there some Google guidelines you plan to follow?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> - Chris -
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 3, 2012 at 17:45, BogDan
> <bog_dan_ro at yahoo.com>
>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think none of your examples are good to
> follow :) The
>>>>> reason why
>>>>>>> meego doesn't use QtStyle to draw the widgets is
> because meego
>>>>> doesn't
>>>>>>> have a "native" style. Symbian is even
> worst, open any two
>>>>>>> applications on symbian and you'll see that none
> of them have the
>>>>> same look
>>>>>>> & style :) On Android is a different story, almost
> all applications
>>>>> have the
>>>>>>> same look & style, so if we want to have a first
> class citizen
>>>>> port, all Qt
>>>>>>> applications *MUST* look the same as any android
> application. I'm
>>>>> choosing
>>>>>>> to make QStyle plugin because this way all Qt
> applications will benefit
>>>>> from it,
>>>>>>> either they are made using old-fashion widgets or QML
> components.
>>>>>>>>> For me a good android style is a top priority,
> I don't
>>>>> believe
>>>>>>> I'll have enough time to finish it till beta 1 but
> who knows ...:)
>>>>> maybe if
>>>>>>> other people will join me we can split the work and we
> can have this
>>>>> feature in
>>>>>>> time for beta1.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> BogDan.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> and please note that the Qt quick
> components (either
>>>>> symbian or
>>>>>>> meego) don't use Qt widget styles. All the
> components are drawn in
>>>>> qml so
>>>>>>> the componenets would unfortunately not benefit from
> your work on a
>>>>> widget
>>>>>>> style.
>>>>>>>>>>> - Chris -
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 22, 2011 at 21:53, BogDan
>>>>> <bog_dan_ro at yahoo.com>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>
>>>>>>>>>>> Please accept my apologize for the
> slow reply.
>>>>>>>>>>> I think before we'll integrate the
> components into
>>>>> Ministro,
>>>>>>> we must do a few things:
>>>>>>>>>>> - the components MUST use
> Android's style, next
>>>>> year
>>>>>>> I'm planning to create a style plugin for
>>>>>>>>>>>
>>>>>>>>>>> widgets which should be used by Qt
> Quick Components for
>>>>> Android.
>>>>>>>>>>> - wait until Nokia finishes to define
> the API for Qt
>>>>> Quick
>>>>>>> components [1]. We can't afford to break the API
> after we release
>>>>> it :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> BogDan.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>> https://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200 >>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi guys,
>>>>>>>>>>>>
>>>>>>>>>>>> What would the steps be to
> integrate the Qt quick
>>>>> components
>>>>>>> for Android to Ministro as a package?
>>>>>>>>>>>>
>>>>>>>>>>>> - Chris -
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Necessitas-devel mailing list
>>>>>>> Necessitas-devel at kde.org >>>>>>> https://mail.kde.org/mailman/listinfo/necessitas-devel >>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
_______________________________________________
Necessitas-devel mailing list Necessitas-devel at kde.org https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>
>
More information about the Necessitas-devel
mailing list