Hi David,
On Thu, 2010-10-21 at 00:53 +0200, [email protected] wrote:
> There's a little bit of news on the Maps and Navigation QML bindings front.
thanks for the update. It's always good to be informed.
> The bad news is that it looks like we're not going to get to the point where
> we're comfortable enough with the Maps and Navigation QML bindings to offer
> our usual API promises as of the 1.1.0 release. It also looks like we won't
> be able to make the Map and Flickable work together behind the scenes since
> the Map is kind of outside of the scope of what Flickable was designed for,
> although I hope to add an example of how to do it and potentially some extra
> bits to the QML bindings to make it easier on developers.
That's of course a pity, because since I've started using QML I don't
want to use anything else anymore :) At least not on mobile. On the
other hand it's definitively good to get a clean and stable API.
Regarding Map+Flickable: I don't think it's needed in the first
iteration, because having the map pannable (without kinetics) does work
easily. Of course kinetic scrolling is great, but it could be added
later. Also I don't think it must be realized by actually using
Flickable, it should just show the exact same behavior, since having
different acceleration/deceleration/etc. mixed in on app does not feel
right. We had this in Maemo5 (Gtk vs. Qt) and people generally didn't
like it.
>From my personal (very subjective) point of view it would be great to
have the following in 1.1:
* A way to handle mouse events on MapObjects
* A way to programmatically add and remove MapObjects
* A way to use QML to create custom MapObjects (see below)
With those two you could handle a lot of common scenarios, where some
POIs are shown on a map, the use can touch a POI to trigger an action
(like getting more information, etc.).
I think QML wrappers for routing, searching and landmarks are secondary.
Routing because it's not such a common use-case - searching and
landmarks, because they can easily be handled in C++ code (e.g. they
don't directly manipulate the graphical representation of the map).
> The good news is that pretty soon I'll be looking for 3rd party feedback in
> order to tune what's made available in the final bindings (due in a 1.1.x
> release).
That's great :) And I already have one suggestion - sorry...
I think the QML MapObjects could be more QMLified. For example it would
be great, if we could use any QML item to be a MapObject like, for
example, MapCircle. Maybe like this:
Map {
// Some stuff...
MapObject {
center: Coordinate {latitude: 51.058; longitude: 13.743}
width: 100
height: 100
measuredIn: meters // width/height in meters or pixels
MyFancyQmlItem {
anchors.fill: parent
MouseArea {
anchors.fill: parent
onClicked: doSomething()
}
}
}
}
That way we could reuse all default QML items (like Rectangle, Text,
Image) and also implement complex items, that do complex things like
animations, etc. Imagine a POI that you click and then it smoothly grows
to expose additional information.
> Is anyone else playing with the bindings? Or will it just be me and Conny
> throwing ideas back and forth? :)
Sorry for the long post, this stuff just came to my head and had to go
somewhere. If it's BS or not feasible, please tell me - no problem :)
Also I didn't look at much besides the Map and MapObjects API, so if
I've missed something, please let me know.
Anyways, thank you all for the great work so far!
Cheers,
Conny
_______________________________________________
Qt-mobility-feedback mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback
