Native GTK4/libadwaita interface for Linux phones

[x-vlad-x]

Hi! I've built a native GNOME interface (GTK4 + libadwaita) for Organic Maps, aimed at Linux phones (developed on a FuriLabs FLX1s with Phosh) and also usable on desktop GNOME. It follows the Android app's UX: full-screen map in a GtkGLArea (drape on its own GLES3 contexts), the core's touch gestures, search, place page, routing and turn-by-turn navigation with voice, map downloader, bookmarks and tracks, layers and settings, all translated via the existing data/strings. It uses the unmodified core plus a small CMake hook, and keeps Qt6Core/Network for the existing Qt platform layer.

Screenshots and current code: https://github.com/x-vlad-x/organicmaps-gtk
Related: organicmaps/organicmaps#6624, organicmaps/organicmaps#5305, organicmaps/organicmaps#8390

After an email exchange with @biodranik, I'd like to contribute it upstream rather than maintain a fork. Before opening PRs I'd like to confirm:

1. a top-level gtk/ directory next to qt/, built with a CMake option (e.g. BUILD_GTK_APP, off by default) and a CI job;
2. how it should be shipped (a separate Flathub app for Linux phones, or part of app.organicmaps.desktop) and which app ID it should use;
3. a series of PRs: build option + map view with touch gestures, then search, place page, routing/navigation, downloader, bookmarks, settings;
4. parts of the code were generated with an LLM assistant (Claude) under my direction; I reviewed and tested everything on device and will mark it in each PR, as PR_GUIDE asks. Please tell me if that is a problem for this contribution.

Happy to adjust anything to fit the project's plans 😊

[biodranik]

1. The gtk/ directory in the root directory should work.

I’d like to understand: if you’re keeping a dependency on Qt, why not use either QML or the native Qt interface? What exactly is the advantage of GTK? Recently, another contributor vibe-coded a QML version for Sailfish (which apparently can be used anywhere Qt 5 or higher is available), which is in review now: #13772

2. It’s hard to tell now. Does your port work on desktops? Could you send a video demo of your port? (By the way, we can share it on social media if you don’t mind.)

What we have right now is a developer version with minimal desktop functionality. It would be great to have a working and user-friendly version for both mobile and desktop (including Windows). If the difference between the desktop and mobile versions is too big, we could release app.organicmaps.mobile, for example.

3. It’s preferable to split pull requests and stack them on top of each other (if they depend on previous ones). If something can go straight into master, it’s better to put it there right away. Smaller PRs will be easier to review and merge.

In general, we’ll only be able to help with LLM reviews (since we don’t have any experience with GTK ourselves, don't have a device and capacity to test). So we’ll assume you’ve read through and tested it yourself. Our main focus during the review will be on changes to files shared across all projects. gtk folder content will be under your (maintainer) responsibility.

4. There is no problem with LLM-assisted development, if developer/contributor takes full responsibility for fixing and maintaining it. LLM is a (powerful) tool. A human is responsible on how to use it.

5. The preview builds can be removed from FlatHub after the release; it’s no big deal as long as it’s clearly stated there that these builds aren’t officially from us. They help you gather feedback, right?

6. Is FlatHub the best place for the release? Should we, for example, upload the build directly to GitHub Releases? Or somewhere else later?