On 16.04.2012 16:07, Landon Blake wrote:
> 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.
>
probably nothing like kosmo for now, although i'll try to have a loom how they
manage to do so.
prima
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, wrote:
> On 14.04.2012 22:58, Landon Blake wrote:
>> Ede wrote: "that's one way to look at it. another would be
> Lähettäjä: edgar.sol...@web.de [edgar.sol...@web.de]
> Lähetetty: 15. huhtikuuta 2012 13:33
> Vastaanottaja: OpenJump develop and use
> Aihe: Re: [JPP-Devel] startup of PLUS
>
> On 14.04.2012 23:36, Michaël Michaud wrote:
>> Hi,
>>
>>
enough.
-Jukka Rahkonen-
Lähettäjä: edgar.sol...@web.de [edgar.sol...@web.de]
Lähetetty: 15. huhtikuuta 2012 13:33
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] startup of PLUS
On 14.04.2012 23:36, Michaël Michaud wrote:
> Hi,
>
On 14.04.2012 23:36, Michaël Michaud wrote:
> Hi,
>
> IMHO, before changing the whole framework, it would be important
> to understand where the current slowness comes from.
true, but thinking into the future we probably will have
- even more extensions
- valuable extensions with inefficient ini
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.
>
> execu
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 wai
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 c
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 sa
OK.
If I remember correctly the plug-in interface has a initialize and an
execute method. The problem may not be in the design of JUMP, but in
the design of the offending plug-ins. Really, plug-ins should do as
little as possible in initialize and as much as possible in execute.
Not sure if that
looking at it in terms of speeding up startup. possibly introducing a lazy
extension loading, which is loading in background while the workbench is
already shown.
..ede
On 13.04.2012 20:44, Landon Blake wrote:
> So is Ede working on improvements to the PlugInManager, or do we need
> someone to
So is Ede working on improvements to the PlugInManager, or do we need
someone to look at it?
Landon
2012/3/28 Michaël Michaud :
> Hi Ede,
>> i took some time to check that and think that the PlugInManager should be
>> cleaned up first. something along the lines of
>> - more talkative (what does
Hi Ede,
> i took some time to check that and think that the PlugInManager should be
> cleaned up first. something along the lines of
> - more talkative (what does it do, how long does it take)
> - reordered process: find and load one after the other, currently there are
> two loops: one finds the
13 matches
Mail list logo
