[Marble-devel] Re: KDE Geolocation Services

[Torsten Rahn]

On Thursday, 4. November 2010 19:59:51 Cyrille Berger Skott wrote:
> > 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?). 

There's lots of features, merits and capabilities that Marble has over 
QtMobility. Some of these features at the core are unlikely to go into 
QtMobility and others are unlikely to be replicated in the midterm.

> I will be hard on you :) but there is no feeling in software development,

Indeed. That still doesn't keep me from cuddling our beautiful Marble.

> 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

Exactly. And that's what we are going to do. :-)

> :) 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.

I've heard a similar suggestion by other people who haven't looked at both 
APIs fully. 
Good news: This kind of thinking probably indicates that you have the talent 
to become a manager.
Bad news: I don't think that it's feasible or desirable in terms of design 
differences, project goals, merits (for either project) and requirements.  
Making Marble a "backend" would mean that you'd have to create new code and 
that you'd probably only be able to reuse very little code due to the design 
differences and due to the fact that Qt Mobility covers very few (but surely 
important)  use cases that Marble offers. 
 
> In the end if (lib)Marble does not have a significant advantage, other than
> "we are KDE", people are going to use QtMobility.

I think Marble does have its merits. The unfortunate thing is certainly that 
the Qt Mobility API has the potential to cover several frequent and important 
use cases. So it will certainly "steal" some mindshare away. That's a pity for 
us but so far we only had very little serious "competition", so we have been 
rather lucky so far.

> > 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?

Maybe. Also Marble has some focus on wow-ing people with some of its features. 
Qt Mobility is clearly more minimalist. That doesn't mean that Marble couldn't 
be an appealing solution for Mobile but it might indicate that there is some 
possibility for both solutions  

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

Yes. There are a few classes which are more or less comparable. It's 
interesting to do this comparison and come up with ideas for improvements for 
both (even if due to different requirements there might not be an immediate 
opportunity for sharing the same class). But I clearly see an interesting 
opportunity for improvements and convergence in the mid/long term there. 


BR, 
Torsten