On 14.04.2012 22:58, Landon Blake wrote: > Ede wrote: "that's one way to look at it. another would be to say that > most plugins essentially do their initialization in initialize(), > which can be quit extensive especially if they themselves have to find > their extensions e.g. sextante. > > execute() obviously is not the place to do it as this is called by the > gui when the menu entry is selected. users expect prompt answer here." > > I still think this work should be done in the execute method. The > proper way to handle the delay is to provide feedback to the user > while the set-up is taking place, after the execute method of the > plug-in h as been called. This could be done with a progress bar, for > example.
that's why i say the design is not handling these cases user friendly. extensions have only the option to either hold up the start or keep the user waiting on execution. > JUMP's plug-in mechanism was basically a precursor to the plug-in > mechanism that was later used by Eclipse. The only thing a plug-in > should really do in the initialize method is present itself to the > user through the GUI. All the other work should be done when the > plug-in executes. This is important for at least three (3) reasons: > > 1) It keeps OpenJUMP's start-up time as short as possible. > 2) It keeps the RAM footprint of OpenJUMP as short as possible. > 3) It doesn't require the user to wait for a plug-in that may never be > executed during the specific session of OpenJUMP. agree fully, form the two options above this is the better option. still this leaves users wanting to use the extension with the frustrating experience to have to wait in the very moment they want to use something ;) > I believe Eclipse plug-in developers are encouraged to follow the same > example. In fact, Eclipse plug-ins are presented in the GUI with no > code being executed. This is done declaratively. OpenJUMP is more > flexible than this, but the initialize method can be abused by well > meaning plug-in programmers. actually plugins are usually installed by extensions/configurations and classically this runs the respective initialize methods or simply replaces them. > See this link for more info on lazy plug-in loading: > http://wiki.eclipse.org/FAQ_When_does_a_plug-in_get_started%3F just read it and found the idea to "index" the plugin functionality to be presented in the ui fascinating. i'll consider this for sextante which is currently our biggest whale. > Ede wrote: "as laid out above, no it isn't" > > As laid out above, I respectfully disagree. :] > > I'm not saying it would be bad to have OpenJUMP more responsive as the > plug-ins load. I'm just saying I think that treats a symptom and not > the real problem. I'm not sure if your work around would involve > introducing threads to handle plug-in loading. That would make me a > little nervous. Most of OJ's core is not thread safe, and things get > complicated with threads rather quickly. I wish OJ didn't even have a > threaded plug-in interface. That was bad mojo. actually we already have threaded plugins ;).. but what i was talking about was actually just a background threat doing the initialization loop. > > I appreciate all the work you do on OpenJUMP, Ede. Far more work than > I do. I hope you don't mind a little healthy debate on your idea. no problem at all, we could use much more dialog here to come up with bright ideas, like the above. ..ede > On Sat, Apr 14, 2012 at 9:33 AM, Edgar Soldin <ed...@soldin.de> wrote: >> On 14.04.2012 17:47, Landon Blake wrote: >>> OK. >>> >>> If I remember correctly the plug-in interface has a initialize and an >>> execute method. >> >> exactly >> >>> The problem may not be in the design of JUMP, but in >>> the design of the offending plug-ins. >> >> that's one way to look at it. another would be to say that most plugins >> essentially do their initialization in initialize(), which can be quit >> extensive especially if they themselves have to find their extensions e.g. >> sextante. >> >> execute() obviously is not the place to do it as this is called by the gui >> when the menu entry is selected. users expect prompt answer here. >> >>> Really, plug-ins should do as >>> little as possible in initialize and as much as possible in execute. >> >> well they should, which essentially means they don't necessarily do so. >> because the development of extensions is decentralized modifying all >> extensions is essentially impossible. >> showing workbench and keep on initializing would be a workaround. >> >>> Not sure if that is the problem, but it is a thought. In that sense, >>> OJ is already design for lazy loading. >> >> as laid out above, no it isn't ;) >> >> ..ede >> ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
