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

[Friedrich W. H. Kossebau]

Hi Dennis,

Am Sonntag, 22. November 2015, 10:54:16 schrieb 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? :-)

https://share.kde.org/index.php/s/UdTwzUeffBb0Eav
https://share.kde.org/index.php/s/pXPmwzw99xu00mV

Tried to follow native style where possible (and found Silica to need more 
flexibility, oh well). There are a few small glitches still here and there, 
but the UI for route editing basically works. The completion list needs to get 
a proper z-index though, both circular buttons and the top shadow of route 
editor cover it, might be a similar problem with the normal Maps code as well, 
as that part should be similar in code.

Navigation mode has the problem that with Silica pages on the pagestack seem 
to not show the page below. So I will have to turn the navigation overlay into 
an overlay on the initial page. Which seems not that wrong to me in general. 
But then I have no clue about best practices with QtQuick yet, so happy to be 
told it actually is a good idea.

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

I have to admit I also did the port to Silica for learning more about QtQuick 
;)

But right, it's the old story of code duplication for integration vs. single-
code but half-integration. Undecided on that one, but collecting experience by 
this one.

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

Okay, I see. Thanks for the big picture.

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

Okay, will do that for a first release then.

> > Find first RPMs on
> > https://build.merproject.org/package/show/home:kossebau:sailfishos:devel:a
> > pps/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.

Not today though, but tomorrow should finally see some review requests on 
phab.

> > 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']

Hm, have to see what makes more sense (to me), filtering in RPM %files section 
or skipping the unused per buildsystem. Somehow the latter seems nicer to me, 
especially during development only waiting for build of what is needed is 
nicer :)

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

I hope that the rpm tool does something similar, at least on 
build.merproject.org separate debug packages are automatically created, which 
should contain the stuff stripped, I assume? 

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

Yesyes, typing fingers did not follow mind.

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

Idea was to drop anything not used, simply by principle. No pressing needs, so 
if there is planned functional dependency to libastro even for plain maps, 
fine with me to keep it.

One feature I personally would like for use cases of mine: select a waypoint 
directly from the map. Perhaps by long tap. Is that planned and would anyone 
work with me on that?

Other features for the more distant future I would like to see: a manager for 
routes, so routes can be stored and reused. And syncing routes between 
devices. So one can prepare a route on a device with a big nice screen (with 
desktop marble), and the built-in editor of Marble Maps would be just an 
alternative if the mobile is the only device present. But that's perhaps only 
for the next winter as project for me ;) Too bad the Marble ownCloud support 
died after the GSoC again?

Cheers
Friedrich