Port to GNU+Linux

[scottAnselmo]

Use case

StreetComplete is an extremely productive app that enables anyone to easily identify and fill in missing data in the field. With the emergence of FOSS based phones like the librem5 in the 2H of 2019, Android users who use Android because of the existing FOSS ecosystem like F-droid will start to transition to GNU+Linux phones running PureOS or Plasma Mobile. However, because there is no StreetComplete equivalent yet, their ability to make OSM contributions will be limited. I and others would like to be able to contribute to OSM w/ a FOSS app on a FOSS phone.

Proposed Solution

StreetComplete is ported to GNU+Linux. Development documentation for developing for GNOME/Plasma Mobile enviroments can be found here. Regardless of choosing GNOME or Plasma Mobile development methodoliges, the end product should be distributed via Flatpak so it can be used across both.

Due to the herculean nature of this task it may be worthwhile to consider creating issue(s) and starting a bounty via BountySource so that people like myself can contribute to to help encourage feature parity with Android's version.

[rugk]

You could try to run anbox, which emulates Android and then run StreetComplete in it. However, as for a native application, I think that is just too much work.

[westnordost]

That's too much work. It would be a completely different application. In my opinion, for any new mobile OS, be it FOSS or not, it is imperative that they support running applications written for Android, so mirror the Android API in one way or the other.
The mobile OS market is simply saturated, no software creator will bother creating a completely different application for some per mill of the market share.

[okias]

I understand that it's probably new application, but I also missing it (running GNOME on my tablet which I could use it + I ordered Linux phone)
Software ported to GNU/Linux can be used also desktop OS. Even on laptop, you can improve OSM.

It's really far away from Android API, but there is anbox. Sadly, it's not best solution, due to fact it just only emulates Android, so it'll be more battery consuming and not so well integrated.

TBH it's same as Linux on desktop. It's smaller market share, but still viable and offering more privacy and freedom.

[Fale]

Given #5421, will this be simpler and - therefure - sensible to implement?

[derkrasseleo]

Given #5421, will this be simpler and - therefure - sensible to implement?

Probably, yes, as Kotlin Multiplatform supports Linux as well

[westnordost]

Yes, once it is done, it would be easier to do. But it will be some time since we reach #5421, it very much depends on the (developer) community interest in contributing there.

[westnordost]

For a Linux phone port, it would be probably somewhat of a small step, depending on how complicated it is to package an app for a Linux phone.
Also, all access to system APIs like (GPS) location, scheduling of background jobs, taking pictures, launching a browser, database access, persistent key-value storage etc. need to be re-implemented for that platform. It's not little to do, but in comparison to reimplementing the whole UI in Compose Multiplatform, i.e. what we have to do right now to achieve #5421, it is little.

For a Linux Desktop (+ Windows Desktop, ...) port, it would be more work, because some consideration needs to be put into what should be changed for a desktop variant of the app. I.e.

• the user cannot be assumed to be on-site anymore: Some quests will not be solvable remotely and thus should never be displayed. Some other (new) quests may only be conveniently solvable from remote, e.g. countring the number of parking spaces in a parking lot and stuff like that.
• possibility to show (best) aerial imagery in background would be indispensable
• integration of street view imagery (Mapillary, KartaView, Panoramax, ...) might be important
• layout should be adapted for larger screen sizes
• some things should probably be adapted taking into account people generally use mouse + keyboard on desktop computers rather than touch. This means that advanced features, like adapting the geometry of elements would become feasible to do. (On touch screen on mobile devices, it is just too awkward.)

[derkrasseleo]

For a Linux Desktop (+ Windows Desktop, ...) port, it would be more work, because some consideration needs to be put into what should be changed for a desktop variant of the app. I.e.

I just wanted to reply that I didn't mean a desktop app is needed, but now that I think about it, an OSM editor for desktop with StreetComplete level quality and extended features like JOSM would be awesome

[Fale]

Personally, I would be more interested in the Linux Phone option in the short/medium term.
Surely having SC on Linux Desktop would be nice, but it will need a lot of changes, as @westnordost mentioned.

[derkrasseleo]

Personally, I would be more interested in the Linux Phone option in the short/medium term. Surely having SC on Linux Desktop would be nice, but it will need a lot of changes, as @westnordost mentioned.

Of course, that's what I meant. For now, SC should be focused on mobile, but maybe desktop in the future.