Plugin housekeeping

rittels

@ivo, @marekd, @mhaberler, @vicb, @jakubvrana, @johnckealy, @jacobsjo, @okocedion.

Hi everyone.

There have been few problems with the current plugin loader:

If you click the open button when the plugin has already loaded, it tries to reload the plugin and then hangs, since the modules have already been defined.
If you open another plugin, the listeners and dom elements remain active, which becomes messy. You can use onclose, but this is triggered when the plugin element is closed, not when a different plugin is opened. Also, generally, you want to be able to close the pane, but keep the plugin active.

I created a module to help fix these problems:

It loads as an external dependency and installs as a module in the W object (W.windy-plugin-module-pluginCoordinator). It loads just once, through the 1st plugin that contains it. It is included in all my plugins. You can include it in your plugins by adding it to the config.js file's dependencies array. It is executed immediately when loaded, and does not need to be imported in the plugin. I published it on npm: https://www.npmjs.com/package/windyplugin-module-plugin-coordinator. See the readme file for more detail.

Ideally this functionality can be included in the plugins-plugin.

I have created a number of other modules, commonly used in my plugins, also published on npm (pickerTools, airspaces, infobox and rplannerWrapper). I will still comment on them and place them on github.

Let me know what you think.

jacobsjo

Seems like good idea.

A few things to consider:

The fact that the plugin version has to be specified is a bit annoying as it would require new plugin versions every time this module is updated. Also, if I understand the code correctly it is not loaded again once it is loaded once (irrespective of version) so if one plugin loads an old version and then another plugin requires something from a newer version, it would break.
It would be good to have a standard way to close/disable a plugin other than just closing the pane. In my case in the sun-position plugin, it would be good to be able to keep the dial at the picker open while the pane is closed. However, you should still be able to close it somehow...
A minor bug: On mobile, the load button is grayed out but still says "Load" instant of "Loaded"

I think it is a good idea to have a community-driven module that handles these things (whether included in windy directly or as dependencies of other plugins). It could also include some CSS changes needed on windy stuff so that plugins are less likely to interfere with each other. For example, my sun-position plugin includes

#device-mobile #bottom {
	z-index: 2; // makes timeline appear on top of the pane in mobile
}

to make sure the timeline is in front of the bottom pane on mobile. Other plugins with fullscreen panes might want to be displayed in front of the timeline, so having a fixed z-index everyone can count on (that is larger than 0) would be good. I am sure other plugins have some of these "hacky" things as well...

As a final note, could you put these modules into their own GitHub repo? That would make cooperation on additional features easier. (And having them in a fork of windy-plugins doesn't quite make sense.)

rittels

Hi @jacobsjo

Agree with everything you said.

Unfortunately the users browser caches the dependency, so you have to specify the version. You can force reload with ?"+Math.random(), but this needs to done from inside windy. (Also will take longer to load for a dependency which should hopefully be stable.)

(Ideally it should be inside the windy-plugin, maybe one-day.)

Exactly the point of the pluginCoordinator. It sets the lastOpened property to false for your plugin and if W.plugins["windy-plugin-sun-position"].onOtherPluginOpened() exists, will call it when another plugin opens. So for example you can say:

this.onOtherPluginOpened = () => {  /*instead of this.onopen*/
   isOpen = false;
   d3.select(".picker").select("svg").remove()
}

Unfortunately the module only executes once it is opened. So if you click "open", it will work, but if you click "load" (for the 1st time), it still hangs. 😟
yeah, I do lots of hacky things, so if onOtherPuginOpened is called, you can clean it up if you want.
Yep, u are right, will make new repo for the modules.

Thanks for your answer.

jacobsjo

Alright, I see your points.

(1) That makes sense, but maybe the module could have a simple logic that checks if an older version is already enabled and disables that one, so the newest version that is a dependency of any installed plugin is used.

(2) Right, but that doesn't include the possibility to keep the svg together with another plugin. Ideally, I would like to have a function onOtherPluginUsesPicker() that is called before another plugin wants to draw something at the picker; triggered by that plugin calling plugin_coordinator.usePicker(). Also, a parameter with the other Plugins name would make sense in these callbacks so you can whitelist other plugins that are compatible.

(4) Cleaning up the csv is a bit annoying. I still think that having a module for standard plugin csv stuff (windy object z-levels, bottom panes on mobile etc.) would make sense and simplify plugin development.

I'll take a look at the module code tomorrow again and maybe try out some of these things myself :)

johnckealy

@rittels great work! You're really on it :)

rittels

@jacobsjo

Disabling the older module is tricky, it consists of a bunch of listeners, which will all have to be deactivated. Certainly possible. Just deleting the module from W does not work.
Yep, good idea to send the ident, included it. The onOtherPluginOpened function is called on rqstOpen, thus before the new plugin does anything. You can then keep the svg when another plugin opens, or check the name of the plugin and decide whether to remove it.
I dynamically load stylesheets for my other external modules. You can start with a standard style sheet.

I moved the modules to a new repo: https://github.com/rittels/windy-plugins-modules.

Ideally the pluginCoordinator functionality should be included in the plugins-plugin.

Thanks @jacobsjo version control added.

marekd

@rittels @jacobsjo Thank you guys fot the great job! I am just finishing 2 other projects, then I would like make some basic changes and fixes at plugins. I would use your code if you agree. Thanks!

rittels

@marekd

Thanks!! Please use our code.