KDE Geolocation Services
Cyrille Berger Skott
cberger at cberger.net
Thu Nov 4 18:59:51 GMT 2010
On Thursday 04 November 2010, John Layt wrote:
> On Thursday 04 November 2010 07:23:38 Cyrille Berger Skott wrote:
> > On Wednesday 03 November 2010, John Layt wrote:
> > > * Comes packaged with lots of other services that we don't need, such
> > > as Solid, Phonon and kdepim equivalents.
> > It is worth to note that QtMobility is very modular, so you get a
> > different library for each of the services. And at least on debian, you
> > get one package per library. In other word, having other services in
> > QtMobility should not really be an objection to QtLocation.
> That's good to know, I kinda assumed it would be given the talk around a
> more modular Qt. Do you know if it can be broken down even smaller, say
> just the Location part and not the Mapping/Navigation part?
No, there is a reason why we don't have one library per class :)
> > An other point to consider is that if you intend to build a cross
> > platform application that would run also on Meego/Symbian, it might be
> > better to use an already existing service on that device rather than
> > using an other library (to reduce memory footprint). So unless, a new
> > API provides a significant advantage, I don't see it gaining users
> > compared to what is already in Qt.
> Aye, that's the big point in QtMobility's favour, and the possibility of
> getting access to the Ovi map services too. Even Torsten says it will be
> better if mobile is what you're targeting. And the Mobile profile of
> kdelibs would almost certainly exclude our api as duplication. Our extra
> library itself would be very light, really a thin wrapper for talking to
> the same services as QtMobility, but then you may need the Marble Map
> widget too.
> However, that ignores our number one use case, desktop apps, a case of the
> tail wagging the dog right now. The main thing most apps will want is
> simply the current location, no maps or navigation required, so the full
> QtLocation may be overkill,
Yes. Just keep in mind that many desktop apps might want to be ported to
mobile. If you are just interested in desktop, then it might be ok to look at
> Choosing QtMobility also almost feels like a betrayal of the Marble guys as
> it would inevitably mean apps would choose to use the QtMobility Map and
> Navigation stuff for compatibility, unless Marble has some feature they
> really need (Offline mode? OSM?).
I will be hard on you :) but there is no feeling in software development, so
not such thing as betrayal. It is about choosing what is best for your
application. Since you have a sprint, it is a good opportunity to investigate
what you want marble to be, and how it relates to QtMobility :) I haven't
investigated the API fully (I was mostly interested in showing a vehicule
position on satelite pictures, and sadly only google maps could provide me the
resolution I needed), but there might be the possibility for marble to act as
a QtMobility backend.
In the end if (lib)Marble does not have a significant advantage, other than
"we are KDE", people are going to use QtMobility.
> Then again, the Qt Map widget may be designed for mobile use cases only and
> may be a usability nightmare on a desktop, it may not integrate that well
> into our desktop environment, may not have offline data, etc, so apps may
> well want to use Marble, in which case why bother with QtMobility at all?
True. An other idea could be to have the marble widget API compatible with the
one of QtMobility, so it is easy to switch, when the application is build for
the desktop it use marble, when it is build for a mobile device it use the one
Cyrille Berger Skott
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-core-devel