Missing top priority features in Organic Maps and GNOME Maps

Sounds like we're making slightly different assumptions there then. My assumptions is that the "eventually" for Gnome Maps to get feature parity with Organic Maps would be a very long time if ever, and that a front end for Organic Maps would be significantly quicker.

It sounds like your assumption is those features could be implemented in Gnome Maps in a reasonable amount of time, and are a goal of the project.

Also the Organic Maps core already has a team of maintainers so it would just be the front end that needs additional maintenance. I'm not sure it's definitely the case that that maintaince burden would be bigger than the burden of adding (many) big features to Gnome Maps, that they potentially wouldn't otherwise need to add. Generally the Gnome philosophy seems to be to keep core apps relatively simple, and just cover the most common use cases, whereas Organic Maps could go beyond that.

@baarkerlounger I have a similar view here (although we should probably check with the developers). Organic Maps seems to be actively adding features, and if they continue at this pace it will take time for GNOME Maps to catch up.

Additionally, if we do get GTK/QT frontend(s) working, Organic Maps contributions will give more "bang for the buck" as adding a feature to Organic Maps will make that feature available for more platforms.

So I think it makes sense to try for this approach first. If the Organic Maps maintainers are opposed to it for some reason (eg. adding more maintenance overhead, etc., or insight that it would take an enormous amount of work to add a new frontend) then we can shift focus to GNOME Maps as a second option.

After writing the above, I saw that @Pirate Praveen has asked GNOME Maps about using Organic Maps core which will bring a bunch of features over. That's a good option too (possibly the best) since we will get the features quickly into a frontend that is already actively maintained.

@Badri Sunderarajan I think it is better if someone who agrees with adding GTK+ front end asks Organic Maps developers about it.

I can see gtk+/libadwaita was already suggested and rejected https://github.com/orgs/organicmaps/discussions/4408#discussioncomment-5321779 (from what I understood - qt works beyond gnu/linux for android and ios too I think).

I asked Organic Maps developers about raising funds for this feature https://github.com/orgs/organicmaps/discussions/4408#discussioncomment-10835472

@baarkerlounger I was not looking at gnome maps having full feature parity with organic maps, just the high priority features of offline maps and turn by turn navigation. Also unlike most other apps, maps / navigation app with full screen in qt may not be as bad as we imagine.

We got a positive response from Organic Maps. So as a next step, we can do budget estimation, setup a targeted fund raising option in Organic Maps OpenCollective page and also look for developers / free lancers in places like fossjobs.net

@Pirate Praveen regarding the Qt part: my impression of Qt is "downloads half the KDE stack to run" which I try to avoid on GNOME or XFCE. But I guess that's only apps tailored for KDE (not necessarily Qt itself). I'm assuming Organic Maps is just using Qt for the UI and not all the other stuff, which makes the compromise considerably better.

@Badri Sunderarajan I think downloading and running qt in addition to gtk is a temporary but reasonable step (given our constraints - funds / developers) until gnome maps gains these features (though it could take a long time).