Integrating Qt Quick components in Ministro

Chris Browet cbro at semperpax.com
Thu Feb 2 13:34:14 UTC 2012


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
> >>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20120202/c8f068f3/attachment-0001.html>


More information about the Necessitas-devel mailing list