the marble (map) replacement dilemma

Dirk Hohndel dirk at hohndel.org
Wed Jul 12 03:22:12 PDT 2017


I enjoyed actually staying out a discussion for a while :-)

On Wed, Jul 12, 2017 at 01:17:09AM +0300, Lubomir I. Ivanov wrote:
> On 12 July 2017 at 01:02, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> > On Tue, Jul 11, 2017 at 2:37 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> >>
> >> in terms of complexity, the context menu would be harder for me to do
> >> over google maps (HTML / JavaScript), while the Qt Location (QML) one
> >> should be trivial.
> >
> > It sounds like the Qt Location one might be better, then - supports
> > offline caching, has reasonable (although perhaps not best-in-class)
> > satellite imagery, and allows us to escape to an external browser
> > easily..
> >
> > Are there any issues on mobile where one or the other would be much preferred?
> 
> we haven't touched the mobile subject, but to my understanding the Qt
> Location solution should just work on mobile (untested by me for the
> time being).
> while the google maps solution requires a browser engine. we are
> planning to move away from the deprecated QWebKit to QWebEngine, but
> Thiago mentioned that QWebEngine has licensing issues on iOS and
> QWebKit has to be used there, which means that we might have to use
> QWebKit if we want a map in the mobile version.
> 
> so given these complications, Qt Location might be the right choice in
> terms of eventual mobile support.

So far on mobile we haven't had a marble equivalent - we simply open links
to Google Maps in a browser window.

I already thought that Qt Location was likely the better solution overall,
but if that would also give us something we could use on mobile, that
would certainly shift my bias even more in that direction.

/D


More information about the subsurface mailing list