Turning off a plug in?

redbellyacres

Is it possible to turn a plugin on and off as needed, or do I have to uninstall every time?

rittels

To turn a plugin off completely, windy needs to reload. Ideally loading a different plugin should reload windy and launch the plugin immediately.

It would be great if we could launch the plugins from the URL. The open plugin buttons could link to the address of the plugin. (please @ivo, @marekd )

I have been planning on listening for other plugins (in my plugins) and deactivating all the Dom elements, map layers and listeners if a different plugin opens, but it is no 365 on my todo list.

mhaberler

@rittels said in Turning off a plug in?:

It would be great if we could launch the plugins from the URL. The open plugin buttons could link to the address of the plugin. (please @ivo, @marekd )

This is important for usability for sharing a plugin setup, which is needlessly cumbersome right now. And it is easy to fix.

It should come down to passing a link which includes the plugin name, AND the set of parameters to the plugin. Opening the link should open windy, install the plugin listed, and set the parameters as per URL. Totally fine if that works only for blessed plugins.

Right now we stand at 'pass a screenshot as png'.

Please make that possible.

thanks, Michael

marekd

@rittels @mhaberler Plugins aren't used very much right now. We would like to wait a little more for feedback before continuing our development. But thanks for the feedback! It is already on my "maybe at some point" TODO list :-)

mhaberler

@marekd said in Turning off a plug in?:

@rittels @mhaberler Plugins aren't used very much right now.
@ivo

Usability might be a cause for that.

I've given tutorials to my particular community on windy usage and have been invited for more, next in Switzerland in March. They are basically 'this is the philosophy and now let me hold your hand' events. And @rittels puts in a lot of hours into working in feedback.

So I'm somewhat dubious if your argument holds water if you look at specific segments, not just the overall usage.

Of course plugins cater to specific community, even local use only. Plugins which are used by everybody and his dog are not going to happen IMV.

Even if this is so, it is clear to me that user extensibility of a weather application has been a phenomenal success and has raised the bar for others

Maybe it is worth reconsidering what the relation of the open-source part of windy (right now - user-contributed client-side plugins only) and the closed-source part (server side and curated client-side code) is to be in the future

Example - what about open-sourcing the non-core/not-license-encumbered parts of windy to stimulate more user contribution?

Let's take the 'Upload KML, GPX or GeoJSON file' as a case in point:

it is a tad lame as it stands - 'can display polylines in color, issue closed'.
No attention to importing files generated by plugins given
if I want to make it useful for say displaying route planner or traj GPX files, I need to re-implement the whole yadayada, not just extend and build on what is already there

ad 2. I'm fine with that in principle - I do not expect you to jump every hoop users come up with. We're happy to fix that ourselves. But then you need to grease that capability a bit. Going closed source in irrelevant areas has a cost: usability is one of them. And I'd be fine to do that under a 'do with it what you want' license.

Another example: Integration of custom data layers, and a way to share them.

Any plans in that direction? this could be a significant booster for acceptance, and creating applications which even you never thought of.

And some markets, btw - just look at how an average nation aviation weather office displays its data. Mine makes me weep ;-)

Michael

marekd

@mhaberler Thanks for your valuable feedback. Of course, we have been thinking about these points. And from time to time these things come into consideration. But every decision has pros and cons.

Pros:

You already wrote almost everything, thanks.

Cons:

We tried to open-source some parts of our code base. However, contibuting was rather exceptional. Only exeption is Leaflet-KML plugin, where people are really handy: https://github.com/windycom/leaflet-kml
We are really small development team, and at this moment, we have no capacity for code reviewing 3rd party pull requests
And it is same for refactoring the client source code to make it partly open-source

I am sure we would come up with more pros and cons, but this is not the point. I would like to say: first of all, we need to ensure some income, hire more developers and then developing and improving not just plugins, but everything (we have so many released, but still kind of unfinished, projects).

I am a huge fan of open source and I would be more than happy to achieve what you wrote, but we need some time :-) But if you would like to be a core contributor and help us, for example, with route planner, feel free to write me at marek.dorda@windy.com. This is the least we can do at the moment.

rittels

Hi @marekd

I appreciate that we have the opportunity to write plugins. It is fun and challenging, and the feedback has been very positive.

I understand the following:

You cannot check all the plugins and, consequently you do not want a URL address ending up as a bookmark in someone’s browser or in a website, leading to a possibly dysfunctional Windy page.
I respect that @ivo is worried about a security risk from the URL query string, with the possibility of someone introducing malicious code. I am probably ignorant, but is it different from strings from input elements or file upload?
The plugins do not play well together, as @redbellyacres implied. It is probably our job to clean up everything we have changed when another plugin opens, but it is rather tedious. Some of the plugins and layers loaded are huge, and performance deteriorates if many are loaded. It would be simpler just to reload Windy when another plugin is clicked.
You have big projects and do not have time to refactor the core Windy, but I think the plugin system works very well.

From our perspective:

It would be amazing to share or save a planned trajectory or flightplan through social media (e.g. whatsapp) or as bookmark. As the week goes by, one can check every now and then whether we will be able to fly on the weekend. It would boost the usefulness of the plugins a lot!

I suggest a compromise:

The feature to open (approved) plugins from the URL, with the query string, but when the plugin opens a disclaimer appears stating, for example:

You have opened a windy plugin: name of plugin.
Windy.com did not create and is not responsible for the plugin.
Go here (npm readme) for more information and here (community link) to comment on the plugin.
Button: Continue to plugin, or button: Take me back to Windy.com.

It is thus one extra click, but the user knows he is in experimental terrain.

please move to the definitely at some point todo list :-) .

marekd

@rittels I agree we should improve plugins usability and actually I like your suggestion. It has been queued into "at some point todo list", with a higher priority :-)