Modify ↓
Opened 8 years ago
Closed 8 years ago
#14913 closed enhancement (wontfix)
Allow removing plugins without needing to restart
Reported by: | naoliv | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | |
Keywords: | Cc: |
Description
While we can enable some plugins without needing to restart JOSM, it seems that this doesn't happen when removing/disabling them: JOSM still asks to restart.
Isn't it possible to remove/disable plugins on-the-fly?
JOSM:
URL:http://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2017-06-08 01:20:59 +0200 (Thu, 08 Jun 2017) Build-Date:2017-06-08 01:32:55 Revision:12343 Relative:URL: ^/trunk Identification: JOSM/1.5 (12343 en) Linux Debian GNU/Linux 9 (stretch) Memory Usage: 247 MB / 3005 MB (82 MB allocated, but free) Java version: 1.8.0_131-8u131-b11-2-b11, Oracle Corporation, OpenJDK 64-Bit Server VM Screen: :0.0 1920x1080 Maximum Screen Size: 1920x1080 Java package: openjdk-8-jre:amd64-8u131-b11-2 Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-13 VM arguments: [-Dawt.useSystemAAFontSettings=on, -Dawt.useSystemAAFontSettings=on] Program arguments: [--language=en]
Attachments (0)
Change History (2)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Considering the minimal benefit and the large issues I think we have much more important things to do in the next decade ;-)
Note:
See TracTickets
for help on using tickets.
Possible, but quite a bit more complex than enabling a plugin on the fly: What should happen if you have a Mapillary layer open and uninstall the Mapillary plugin? (a) reject to uninstall (b) kill the layer (c) remove all buttons and menu entries, but keep the layer and let the plugin linger in the background ...?
Making the plugin ready for install without restart isn't too hard, for many plugins it works out of the box. Still the adoption rate isn't very high, only 48 of 135 plugins support it. I'd like to get that number higher, before starting with this.
On the technical side, it is hard to make sure the plugin is 100% gone. You need to know the plugin code very well, to identify any listeners and hooks that cause the plugin to live on in the background as a zombie. Maybe this is not such a huge problem in practice, though. (The plugin class path rework in #14901 might make it easier to implement this request, btw.)