KDE Geolocation Services

[Cyrille Berger Skott]

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 
alternative.

> 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 
of QtMobility.

-- 
Cyrille Berger Skott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101104/79a813de/attachment.htm>