Plugin interface
Split off from #1391.
Essentially: what types of functional plugins should iD support and how? Should it be a js interface? How should they be installed?
So, in light of recent news about feature extraction plugin, is there a plugin API now? Can anyone make some example plugins?
Hi! Is there any progress on plugins? If I want to extend an editor, is JOSM a better choice at the moment?
@bhousel I looked at the PR #3503 to understand the interface you were thinking for this. When you mention events for plugins to hook into, did you imagine these as new events or existing ones used inside iD? If existing, are these events documented anywhere?
For example, I'm trying to add a plugin to the inspector when someone selects (or hovers) on a node in the map, but I'm having trouble finding the correct object to listen on and event to listen for.
When you mention events for plugins to hook into, did you imagine these as new events or existing ones used inside iD? If existing, are these events documented anywhere?
Existing events, unless we think of other ones that a plugin might need. For example, the intro walkthrough uses events on the history and map objects to watch for everything a user does, prompt them, advance them through the tutorial steps.
As far as documentation goes, we don't have anything yet, sorry! Tracking this task on #3743. Unfortunately I need to balance a lot of different things in this project - and bugfixes and features that help new mappers have taken priority over features for power users or iD developers.
For example, I'm trying to add a plugin to the inspector when someone selects (or hovers) on a node in the map, but I'm having trouble finding the correct object to listen on and event to listen for.
Nice, you might want to look at the info panels that I just added in v2.3.0 - this might be a good way to extend iD right now until we figure out plugins.
If your code matches the interface of the other info panels, you could probably inject it directly into the uiInfoPanels object, before bootstrapping the iD ui() in index.html. uiPanelLocation is probably the simplest one to look at as an example or starter code.
Thanks for the pointers! The panels look useful, so I'll try that, but I'll have to see if they are useful as an editing interface (instead of just info display).
I think some small additions to iD that maybe not everyone would want would be neat as plugins: Adding a box with 'commonly used combinations for this tag, from taginfo' or something would be good for example
By the way, for minimal plugin implementation, access to a variable with the iD context will be sufficient. This is done in one line of code.
The rest can be implemented with browser extensions or user scripts.
By the way, for minimal plugin implementation, access to a variable with the iD context will be sufficient. This is done in one line of code.
Lets discuss hacky access to coreContext in #11039, and keep this issue for "official" plugins, like a socket:* editor or a traffic sign visualiser. There are proof of concepts already, but there's a lot more discussion that needs to happen first.