[Marble-devel] Marble Maps on SailfishOS, roadmap of Marble Maps?

[Dennis Nienhüser]

Hi Friedrich,

Am 18.11.2015 15:44, schrieb Friedrich W. H. Kossebau:
> Hi,
> 
> as mentioned on #marble before, I have started to look into getting 
> Marble
> Maps to run on SailfishOS, natively, so not as Android app (that works, 
> boring
> ;) ).
> And I can report there is already an early alpha version now starting 
> on my
> Jolla phone :)

Lovely! Where are the pics? :-)

> Code once, run everywhere!
> Well, sadly also not the case with Marble Maps: current SailfishOS 2.0 
> is only
> at Qt 5.2.1 and then without QtQuick Controls.
> So current QML code of Marble Maps does not work on this platform. 
> Somewhere
> it was hinted (GCompris has the same problem here) one could simply 
> build an
> own version of QtQuick Controls and somehow use that. But that smelled 
> like
> lots of work and troubles,

Personally I'd still give it a serious try and only ditch it if it 
doesn't work after say four hours of work on it.

> so I told myself that proper platform integration
> is important anyway, which also means using native QtQuick components
> (Silica). And so I forked src/apps/marble-maps into 
> src/apps/marble-maps-
> sailfishos and started to do minimal changes there to quickly reach the 
> state
> where the app starts. Which it does now, both emulator and device. And 
> no code
> changes needed outside of the app itself, libs and plugin build fine 
> out of
> the box (just had to lower minimal cmake version to 2.8.11.2). Yay for 
> clean
> and conservative code here.
> 
> Right now I am busy restoring the complete functionality the (normal) 
> Marble
> Maps app has, seeing how native UI would be used for that.
> Which brings me to this question:
> 
> QUESTION:
> What is the roadmap with Marble Maps? Especially, what features are 
> planned
> for the future? And when will releases happen, will they be done in 
> sync with
> normal Marble releases?

There are two major missing features right now that block the first 
release:
- navigation mode
- vector tiling maps
For both there is an early implementation in master. Navigation mode 
does not need too much work to be finished, mainly proper TTS and user 
interface polishing. Vector tiling however is (despite the really 
awesome progress we made on it) still lots of work to get into a 
reasable state. We collect open tasks at 
https://phabricator.kde.org/project/board/38/

Note however that when speaking of a release above I have the Google 
Play Store in mind. To me this means reaching a pretty polished state to 
meet the expectations of the users there. I'm fine with earlier releases 
on e.g. f-droid or less popular ecosystems like sailfishos.

Releases itself will be out of sync with the KDE release cycle. Instead 
I'd expect to have their own stable branches. With regard to 
translations I'd ship the first version without any, then add them in a 
later version when i18n folks are done with them in a KDE stable branch. 
Maybe a better process emerges for that also when KDE does more Android 
apps in the future.

While the amount of work still needed is quite clear to me the time when 
it will be finished (aka first release) largely depends on the amount of 
free time we have to actually work on it, and that is rather 
unpredictable :-) Then again Google Code-In starts in two weeks and we 
will have a bunch of students working on tasks related to Marble Maps.

> I would like to keep the SailfishOS-fork of Marble Maps in sync 
> feature-wise
> with the normal Marble Maps (perhaps one day, when QtQuick Controls are 
> a
> thing everywhere, the fork could be even undone). And also sync 
> releases.
> Which means, I hope to get Marble Maps/SFOS releaseable in time for KA 
> 15.12
> (3 weeks left :) ).

Sounds good to me. For the two blockers I mentioned above I'd disable 
them both for 15.12 on sailfishos. Navigation mode is easy to disable 
temporarily, see commit 
https://quickgit.kde.org/?p=marble.git&a=commitdiff&h=89c1269 If you do 
your own user interface it is even easier of course. Similar for vector 
tiling maps, just use the openstreetmap.dgml theme instead. You could 
also leave that one in, the bitmap themes are currently used as a 
fallback in vectorosm so it does not look totally broken.

> 
> Find first RPMs on
> https://build.merproject.org/package/show/home:kossebau:sailfishos:devel:apps/marble
> and the code in branch sfos in my clone
> git at git.kde.org:clones/marble/kossebau/marble.git
> 
> Doing the work for now in the clone to have a playground to go wild, 
> but
> should move things over soon to the normal Marble repo patch-by-patch.

Sounds good.

> 
> QUESTION:
> Currently also on build for Android all data and plugins are installed. 
> Even
> for Moon. Marble Maps going to be used by the Chinese on their lunar 
> mission?
> :)
> With Marble Maps only needing support for anything shown with vectorosm 
> and
> mercator display, what is the list of plugins and data which are needed 
> by
> Marble Maps? Would help to cut the size of the package down.

The Android packaging does not include everything that is installed 
during the Android build. The script src/apps/marble-maps/create-apk.py 
decides what to include. For plugins the following ones are in at the 
moment:

55  # Whitelisted plugins, all others are ignored
56  search = ['LatLonPlugin', 'NominatimSearchPlugin', 
'LocalDatabasePlugin', 'LocalOsmSearchPlugin']
57  routing = ['CycleStreetsPlugin', 'OSRMPlugin', 
'OpenRouteServicePlugin', 'NominatimReverseGeocodingPlugin', 
'RoutingPlugin']
58  fileFormats = ['CachePlugin', 'GpxPlugin', 'KmlPlugin', 'OsmPlugin']
59  floatItems = ['ElevationProfileFloatItem', 'ElevationProfileMarker', 
'PositionMarker', 'ProgressFloatItem', 'License']
60  positioning = ['QtPositioningPositionProviderPlugin']

We also run make install/strip instead of make install which has a huge 
impact on size at least on Android.

> And could libastro only link optionally to libmarblewidget? In pure map 
> mode
> stars are not needed, right? (though might change with 2 1/2 D views in 
> some
> future :) )

Isn't it the other way round, libmarblewidget links to libastro?
Currently only SunLocator in libmarblewidget uses astro, all other uses 
are in plugins. Technically it's easy to make that optional but it 
sounds kind of broken to me if sun shading could go away like that. Also 
I'd like to be able to implement things like dynamic building shadows 
(based on the position of the sun) in the future without too much 
hassle. Since libastro is small, what's the problem with shipping it? 
I'd rather keep the stars plugin and similar out but still ship libastro 
to avoid more complexity (=potential bugs) inside libmarblewidget.

Regards,
Dennis