Web interface discussion

[albar965]

I don't know if it make sense to add this to one of the numerous PRs. Therefore, I'll just start a discussion here.

@u-an-i Can we rename the names in the dropdown box in the web interface to make them more user friendly:

1. "ol-map" -> "OpenLayers Dynamic Map"
2. "no exclusive plugin" -> "Static Map"

A lot of people use the web interface and most are not developers. 😉
The names are just suggestions. Let me know if you have a better idea.

Also, I think the legacy map can be removed for good. No need for three map styles.

@KOKAProduktion or @u-an-i : Can we be sure that the new address http://MYCOMPUTER:8965/html/2021-a/index.html does not break these addons: https://flightsimulator.me/simulators/flight-simulator/panels/105-ingamepanel-navmap-for-flight-simulator and https://flightsim.to/file/43086/little-navmap-vr-panel ?

Not sure. Maybe the API is not affected, is it?

Sorry for being a pedantic nuisance. 🙃

Alex

[u-an-i]

@albar965 no problem,

the name of the folder of the plugin is the name shown in the menu. I don‘t know whether space and uppercase work. I‘m currently out of reach of my development machine. If they don‘t, i can think of a mean to seperate the name of the plugin from its path.

web api is solely server-delivered. The html files don‘t matter except someone lets fetch one of them, then their path would have to be adjusted.

The url is sth which can be cosmetically fixed to only be the server domain.

Legacy: if you like we can remove the toggle from the menu. I would leave the files so that someone can use them if desired and see how to work without web api.

The folder structure itself was prework currently not being necessary: it allows „old versions“ of the web frontend to be accessible for those who grew used to a particular one in case someone makes breaking changes in a new one.

[u-an-i]

JSON plugin description : good idea! Will do as soon as possible.

Will remove the menu entry then too.

[albar965]

Thanks. I intend to make a public 3.0.7.rc1 the next days or week. I have to fly over LNM a few times (aka testing 🙃 ) before.

[bkielczewski]

@u-an-i yes, I'm an author of the panel. I'm not affected by anything inside web you have, since I replace that with my web content. I would be affected if document root will be served from /html but I can adapt to this.

[u-an-i]

@albar965 i plan to overhaul the plugin and toolbar interface and make it completely JSON configuration based. The toolbar API’s functions took a JSON configuration already only for example, those would be moved from a code call to the static JSON file being the plugin configuration. The init function call will be replaced by the use of JS’/Browser‘s postMessage. This is slightly uncomfortable to use for the developer and the success of the cleanup function call i cannot catch without guessing it should have suceeded after x milliseconds but it completes security, i will make it as easy to use as possible and automatic to understand from the documentation as i achieve.

[albar965]

@albar965 i plan to overhaul the plugin and toolbar interface and make it completely JSON configuration based. The toolbar API’s functions took a JSON configuration already only for example, those would be moved from a code call to the static JSON file being the plugin configuration. The init function call will be replaced by the use of JS’/Browser‘s postMessage. This is slightly uncomfortable to use for the developer and the success of the cleanup function call i cannot catch without guessing it should have suceeded after x milliseconds but it completes security, i will make it as easy to use as possible and automatic to understand from the documentation as i achieve.

Sounds good. I continue with 3.0.7.rc1 public (not sure when). Your change can also be added to the next rc or the release. No problem.

Alex

[bkielczewski]

Ok, just fyi, here's what I'm using at the moment:

• http://localhost:8965 <- assuming document root is served from here
• Not relevant here probably, but I'm parsing the output of tags: {airportText}, {airportRunwayText}, {airportComText}, {airportProcedureText}, {airportWeatherText}, {flightplanText}, {aircraftProgressText}, and I depend on what's in there since don't have an API for that.
• I'm calling /mapimage to get map tiles
• From API I'm calling '/api/sim/info', /api/map/features

If you were to move document root from / to /html, I could check for /html first, and if that would return 404 I could fall back to /,

[u-an-i]

Document root remains /

[albar965]

Anything to add or correct in the changelog?

littlenavmap/CHANGELOG.txt

Lines 56 to 70 in 3203169

	### Random Flight Generation
	* Added shortcut to random flight creation: Menu `Flight Plan` -> `Generate Random Flight`. This
	opens the search dock window and activates the controls to generate a random flight.
	* Added a dialog window where a user can select either a fixed departure or a fixed destination
	airport for the random plan generation. Add at least one airport to your flight plan to enable this
	function. #1013
	* Random plan generation now puts the change on the undo/redo stack once the user accepts a
	generated flight. This is the same behavior as used in the flight plan route description which
	allows to restore a previous flight plan and its changes.
	* Adjusted the maximum distance for random flight plan to realistic values.
	The maximum is 10.800 NM.
	* Fixed the minimum and maximum distance for random flight search not being saved on exit.
	* Performance improvements and random selection for departure and destionation functionality
	by [u-an-i](https://github.com/u-an-i).

and

littlenavmap/CHANGELOG.txt

Lines 161 to 175 in 3203169

	### Web Interface
	* Fixed missing aircraft trail in web interface.
	* Fixed KML overlays not shown on the web interface.
	#### Improvements and fixes by [u-an-i](https://github.com/u-an-i) and [KOKAProduktion](https://github.com/KOKAProduktion)
	* Default display mode now uses a new navigation method. Click to center the map around the
	click-spot and use the mouse wheel to zoom in or out.
	* The plugin `Dynamic touch and drag map` enables a dynamic map which has smooth scrolling
	(click-and-move) as well as zooming with the mouse wheel. Note that neither the AI/multiplayer
	aircraft nor the flight tracks of the user aircraft are shown in this mode. Small display errors
	like duplicate labels can appear.
	* Legacy map removed.
	* More restructuring, performance improvements and updated documentation for the web API.

Alex

[u-an-i]

good!

hint: use "random flight" instead of "random plan" throughout 1. . 1.'s last point typo: "destionation"

2.'s last point: "web frontend in general, web API, web plugin API, web toolbar API and web theming CSS templates; useful for developers and people who wish to enhance or modify the web frontend experience." instead of "web API".

[albar965]

Thanks. Done.

[albar965]

@u-an-i and @KOKAProduktion
I've got this report from a user where the log ends with before crashing:

[2024-07-10 7:47:20.425 DEBUG]: TemplateCache: trying cached /progress_doc
[2024-07-10 7:47:20.425 DEBUG]: TemplateCache: trying cached /progress_doc
[2024-07-10 7:47:20.426 WARN ]: Trying to construct an instance of an invalid type, type id: 206946128
[2024-07-10 7:47:20.426 WARN ]: Trying to construct an instance of an invalid type, type id: 206942544
[2024-07-10 7:47:20.426 WARN ]: Trying to construct an instance of an invalid type, type id: 206947728

Anybody has a clue where this happens?

I can also attach the full log if needed.

Alex

[u-an-i]

Sorry, sim connection did not establish using the built version.

3.0.8 crashed neither:

Bildschirmaufnahme.2024-07-16.044910.mp4

[bkielczewski]

Thanks for checking. I need to spend time playing around with different combinations of things so maybe then I can give you a pattern you could reproduce. I wouldn't worry for just failed responses, the number of requests that makes with even few threads is too much to be realistic. it's just that crash that's bad.

[albar965]

Maybe it makes sense to track all usage of the MapQuery, AirportQuery and maybe other query classes and put a mutex around it.

In the meantime I found a stacktrace reporter (cpptrace) which actually works on all LNM supported platforms. This should help a bit to catch these issues.

BTW: I did not get further reports about similar crashes. Might happen rarely.

[bkielczewski]

Just to let you know, I've tried to reproduce it again with my plan (on 3.0.8) and failed this time, it just worked.
Also last few flights I didn't get crashes. So I'm like unable to give you anything at this time and that's a bit crazy.
Anyway, I agree it's probably rare, I also didn't get reports like that from my panel users.
If you could add something that would make a log entry when the process quits that would be good for the future reports like that I imagine. If the crashes come back, I'll try to reproduce.

[albar965]

Thanks @bkielczewski .

I added more mutexes to database accesses in the webapi. This might help to get rid of the crashes no matter how rare.
There is more stuff which has to be synchronized like the user aircraft which might change in the middle of an access.

[albar965]

@u-an-i and @KOKAProduktion

Sorry to be a PITA, but I see several issues with the web interface (no plugins activated, Firefox):

• Android (Samsung S23): The map fills only the top left quarter of the screen. Everything else working as expected. The issue disappeared after reloading. Probably no biggie.
• Lenovo P11: Map is fully visible, but tap to jump/move seems to jump erratically (i.e. to a nearby but a wrong position).
• Users report zooming not working on iPads which I cannot reproduce on a MacBook using Firefox.
• Starting on Safari I get a message "User interface not rendering correctly, switch to legacy". Which it does and this seems to work ok. I thought we removed the legacy. Better keep it for now.

The biggest issue I see so far is the click-to-move but maybe I do not understand the logic there.

Maybe it makes sense to always keep zoom and move buttons on the interface to workaround/mitigate such issues. Also keep legacy in the web interface menu. Sorry, I know it was my stupid idea to remove it.

I'll go ahead and make a release 3.0.9 anyway. Maybe we can improve the interface for 3.0.10.

Alex

[u-an-i]

@albar965 #1177 fixes Firefox mobile / desktop touch / click move and corrects map size for iPad Safari.

Zooming works for me on my iPad, see video. Note: zoom is to current image center not pinched fingers center.

zoom.mp4

(video recorded before iPad map size fix)

Safari Mac works for me in BrowserStack (real devices, real browsers):

The map not filling screen thing could have been due to old cached CSS, Safari (any "recent", but not on Windows!) all support the current web ui and iPad has the finger pinch zoom since I reworked the web ui in 2021. I hope reports regarding those browsers are only due to old versions.

[albar965]

Perfect! You fix things faster than I think. Good one for 3.0.10. 👍

[albar965]

@u-an-i and @KOKAProduktion :
I made the last two monstrous commits to release/3.0 because of an crash report sent my a user which indicated a synchronization problem when accessing the HtmlInfoBuilder ending in a crash in SQL classes using prepared statements. Easily found thanks to the stack trace now included.

I cleaned the query class management where classes took queries from all over the place (NavApp). Always a bad idea and quite messy. HtmlInfoBuilder and MapPaintWidget and their aggregates now use Queries which bundles all like MapQuery and allows easy locking (querymanager.h.

I hope this helps with some of the crashes seen in the past.

Going further I noticed that you already use mechanisms to do the work in the main thread / eventqueue by using invoke (albeit with direct connection?) or queued connections. Not sure if all the sync stuff I added is needed but definitely for the HtmlInfoBuilder.

Are there any other places in web and webapi that might need synchronization?

[u-an-i]

web in LNM is the requesthandler. This basically still works like it used to. I am not aware of synchronisation needs therein. It defers its work to (a) MapPaintWidget if I remember correctly.

webapi @KOKAProduktion is expert on. I can have a look too if you're busy.

[albar965]

web in LNM is the requesthandler. This basically still works like it used to. I am not aware of synchronisation needs therein. It defers its work to (a) MapPaintWidget if I remember correctly.

Thanks for confirmation. I guess there is no need to look closer. Most places I checked run in the main thread context.