plugins, e.g. kml plugin can not be loaded via configuration (.json) file on any platform in MSS 1.4.0

[Vladyslav Nenakhov]

Hello,

some weeks ago Jörn Ungermann was so friendly and wrote a small plugin to save flight track from MSS in a kml file. Andreas Hilboll tested it on Linux (MSS 1.3.2) and it worked fine. Unfortunately on my Windows 7 (64bit) i have problems to add this plugin (during MSS is running) via a new configuration (.json) file.

Details: If copy "kml.py" (see attachment) to

D:\Program Files\Anaconda3\envs\mss\Lib\site-packages\mslib\plugins\io

and than load the configuration file "mss_settings_EMeRGe-EU_v2_kml - mod.json" (see attachment) i dont get a new option in "File menu" to save/export flight tracks as kml.

Can it be that in windows the plugins are loaded only at the MSS start from the standard configuration .json file and if you want to load a configuration file later, than locations, default_WMS, etc. from the new configuration file are loaded BUT NOT the plugins which are mentioned in the new configuration file?

Best regards, Vlad

[Vladyslav Nenakhov]

Forgot to mention that i have the same problem in MSS 1.4.0.

[Joern Ungermann]

This exactly correct. The loading of configuration files has been poorly tested and I am not sure why the feature is even there, as it is actually quite different to do correctly, as we see here.

Could you, as a work-around, place the file in a location that is found automatically like $HOME/.config/mss/mss_settings.json ? I got mine on Windows in c:\Users\icg173.config\mss\mss_settings.json You can also set the MSS_SETTINGS environment variable to the proper location (also under Windows).

I'll think on if and how this reloading might be realised, but honestly, I'd prefer to remove the feature.

Thinking about it, a lot of other options will also only be updated upon reopening windows like the TopView.

[Reimar Bauer]

hmm, completly differnt opinion on my site. The environment paramater is a lot magic. Useful. Also Load on a different path should not break anything.

[Joern Ungermann]

The usefulness of the feature is not in question, but implementing it properly is difficult.

We need to have a signal in the main UI, which is triggered upon a change of configuration that every widget that accessed the configuration parameter needs to listen to. In case of a change all widgets would need to change their behaviour. The signal might be a global one for simplicities sake, otherwise we have to pass it as additional information in the constructor of all main views. Especially the plugin actions require some rework as first the "old" actions need to be removed, before the "new" actions can be defined. And the old actions depend on information that was removed when the configuration was changed, which implies that we have to store the old configuration simply for tidying up.

This is difficult to get right...

This is basically a new feature and a complex one at that. Not "just" a bug fix, even though the feature as it is implemented now in 1.4 is probably worse than useless.

[Reimar Bauer]

Because of the scope of changes we can work on it for 1.5

An idea how to solve this is given bei werkzeug/serving.py

http://stackoverflow.com/questions/8831748/how-to-set-up-autoreload-with-flaskuwsgi

[Vladyslav Nenakhov]

@ Joern Ungermann: Both solutions worked great!

If i copy the mss_settings.json in Windows into "C:\Users\Vlad.config\mss" it work and the other solution with MSS_SETTINGS environment variable work also well, you have only to set the full path (inkl. file name).

Thanks a lot!

[Joern Ungermann]

You are welcome! We are also working on making the menu entry actually useful for the intended purpose, but it is currently unclear, in which release (1.4.x/1.5) that will be the case.

[Reimar Bauer]

solved for 1.4.1