Hi, IMHO, before changing the whole framework, it would be important to understand where the current slowness comes from.
I think that loading just what is needed should not be too long as the whole OpenJUMP core loading is quite fast. If no solution can be found, I think that it is better to wait a little at startup time than when the plugin is used the first time. Lazy loading can be great, but I wonder what will happen when it will add a menu item, a button or a menu while the user is already working... If we want a better control on the loading process and on the memory usage, we may need a plugin manager able to load/unload extensions. my 2 cents Michaël > 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. > > 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. > > 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. > > See this link for more info on lazy plug-in loading: > http://wiki.eclipse.org/FAQ_When_does_a_plug-in_get_started%3F > > 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. > > 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. > > Landon > > > > 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 > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
