Ede: I look forward to seeing what you come up with. If it is anything like the plug-in manager Jukka described, OpenJUMP users will love it.
Landon On Sun, Apr 15, 2012 at 3:14 AM, <edgar.sol...@web.de> wrote: > 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 ------------------------------------------------------------------------------ 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
