[Qt-components] QML component APIs and techniques
martin.jones at qinetic.com.au
Fri Jan 11 00:22:00 CET 2013
On Fri, Jan 11, 2013 at 2:48 AM, Bache-Wiig Jens
<Jens.Bache-Wiig at digia.com>wrote:
> On Jan 10, 2013, at 3:18 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Thursday, January 10, 2013 15:02:25 Alberto Mardegan wrote:
> >> On 01/10/2013 12:33 PM, Aaron J. Seigo wrote:
> >>> once we have our list of targets, to then have someone (anyone, but
> >>> someone
> >>> who will help take this process through to completion :) take each
> >>> component one by one in whatever order amuses them and start a thread
> >>> this list for that component. a wiki page for that component should
> >>> be started $SOMEWHERE for each component to catch the results.
> >> Maybe we can reuse this:
> >> http://qt-project.org/wiki/Qt_Components
> > sure.. that looks like a perfect place assuming that we won't be
> stepping on
> > anyone's toes ... though it seems it hasn't had any activity for 6
> months so
> > perhaps there aren't any toes to step on ;)
> Agreed. It is perfectly usable for this purpose. The page has been unused
> since the collapse of components for Meego And Symbian but since all of the
> proposed component sets more or less derive from these, it is clearly a
> good place to start. We should probably all use these names and conventions
> by default unless there are good reasons to deviate from them, in which
> case we bring them up to at least explain our reasoning.
The Meego and Symbian components have a large API, so I think they should
be used as a reference for naming the properties, rather than a starting
point for an API.
> And just so people are aware of it. We are planning to ship yet another
> set of components in Qt 5.1. They will be fairly general purpose but with
> the main intent being to offer a replacement for core desktop widgets in Qt
> Quick. However we are already adding certain things like PageStack to the
> set so making a general purpose mobile touch application using only
> built-in components would be feasible. I don't think they would ever be a
> complete replacement for any of the platform specific APIs, but they will
> be the only set that would be generally available on all platforms and
> might perhaps become a standard.
> > the Component APIs table would be the interesting spot for us where we
> > link the individual API exploration pages from each component (Button,
> > Checkbox, etc) as well as add new ones as needed.
> Note that I have mixed feelings about API coordination due to having tried
> this before with Symbian and Meego and partially failed while spending an
> amazing amount of time arguing over small issues. And this is time that we
> don't really have available right now. When you have multiple toolkits
> developed by different teams for different goals, it is somewhat counter
> productive to force a common API on them. But I am optimistic that we can
> find at least some shared ground.
The trick is to define a minimal API, e.g. a Button has "text" property and
"clicked" signal. Much more than that and it won't suit some platforms,
especially those that are performance conscience and don't want features
unnecessary for their design.
> Did anyone look into standard icon naming? (which was oddly one of the
> bigger problems when co-ordinating meego vs symbian API).
I suppose that typically these are exposed via an imageprovider. If it
really is too hard to name them all identically across all platforms then
It may be easiest to simply define a set with a unique provider name, e.g.,
"image://openicon/up_arrow.png", and allow each platform to provide an
"openicon" imageprovider that maps to their own icons.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qt-components