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
[email protected]: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
_______________________________________________
Marble-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/marble-devel
