Consider moving GUI out of osmscout-server to clients

[PureTryOut]

From a user perspective, the current approach doesn't make much sense. Why would they launch a different app if they want offline maps in the other?

I understand wanting to share maps between multiple apps, but that's still possible when moving the UI to download maps to the clients themselves, but actually downloading them through osmscout-server.

If osmscout-server would provide some API (possibly with dbus?) then the clients could provide the UI to download and update maps and other data that needs to be downloaded.

Benefits:

• The user wouldn't need to leave the client for any of it's functionality, hugely improving usability
• Apps using other toolkits (e.g. GNOME with GTK) can make use of osmscout-server

[Olf0]

Sorry, I wholeheartedly disagree:

• Maintaining multiple, different UIs in various map client apps will IMO quickly lead to divergent quality, features etc. of these map management UIs for OSM Scout Server.
• This means multiplying the efforts to reach the same goal: A proper UI for OSM Scout Server
• This also means implementing a locking / synchronization scheme for multiple map client apps managing OSM Scout Server's maps at the same time.
• Many of the apps, which are able to use OSM Scout Server as a map provider, can also be well used without it. I.e. with other (online) map providers, a setup some prefer (for better quality maps and routing, if one has a sufficient data plan). For them an integrated map management UI for OSM Scout Server would simply constitute unnecessary clutter.
• The settings of most apps, which are able to use OSM Scout Server, are already quite extensive and continue to grow as new functionality is added (foremost Pure Maps). Additionally integrating a map management UI would add another big settings category.
  You may take a look at OSMand (for Android), which integrates the map management UI into the same app. IMO this is a good example of an app with settings far too extensive for non-techies.

AFAICS there is no fundamental hurdle to add other UI front-ends to OSM Scout Server, e.g. one using GTK3.
This approach keeps all UI implementations in one place (OSM Scout Server) ...

• from the users' perspective: Maps for OSM Scout Server are managed with OSM Scout Server.
• from the programmers' perspective: There is a single GIT repository for OSM Scout Server with all its UIs.
• from a bug reporter's perspective: There is single issue tracker for OSM Scout Server with all its UIs.

[rinigus]

I have the same reservations as @Olf0 . It seems to be strange for new users to get offline functionality from some other app, but it starts to make sense as soon as there are multiple apps using the same storage. When compared to common solution in Android, you just don't have anything to compare with since each app comes with its own offline storage format and keeps it all in house. That's probably that's why an expectation to see all from the same app as well.

[rinigus]

Current arrangement works rather well and I am closing this as all who wanted have voiced the opinion. I don't exclude having DBUS API for such additional GUI/backend decoupling, but that is not in plans for now.