mhm.. basically I agree with Larry right now. People can get confused.
. For the external plugins they need to know only once that they need to
drag and drop or remove jar files
. For the internal plugins with have now the default-plugins.xml file
the problem with the external plugins would be that they need to support
your interface - anything else wouldn't work.
btw. on the issue with the extension download tool: the problem was, so
I believe, related to the use and unpacking of zip files???
stefan
Sunburned Surveyor schrieb:
> Michael,
>
> You wrote: "...discovering new plugins in the project repository and
> downloading/updating them seems more useful than a local installer,
> that's why I misunderstood Landon's proposal when I read it."
>
> That was one of the ideas I had when I was thinking of the update
> method in the PlugInHandler interface. The method could check a file
> on a web server to see if new versions of a plug-in were available.
> I'd imagine the same mechanism could be used to discover new plug-ins.
> This would work similar to Eclipse.
>
> I always consider Larry's comments carefully, so I will think on what
> he said. Perhaps there is a solution that won't confuse the users.
>
> Please remember I'm not talking about anything that would be forced on
> OJ programmers. It would just be a tool that could be used if
> programmers were interested.
>
> SS
>
> On Fri, Nov 14, 2008 at 2:49 PM, Michael Michaud
> <[EMAIL PROTECTED]> wrote:
>> Stefan Steiniger a écrit :
>>> there has been an extension manager, but this one was rather for
>>> downloading available plugins. the code is still there, but could be
>>> that the plugin needs to be activated (in the xml file)
>>>
>> Yes, that's it.
>> Larry says he had some problems with this plugin.
>> but IMHO, discovering new plugins in the project repository and
>> downloading/updating them seems more useful than a local installer,
>> that's why I misunderstood Landon's proposal when I read it.
>>
>> Michaël
>>> stefan
>>>
>>> Michael Michaud schrieb:
>>>
>>>> Hi,
>>>>
>>>> There used to be a plugin manager in the menu, but I cannot find it
>>>> anymore.
>>>> It was from lat/lon if I remember correctly, but I'm not sure it has
>>>> ever been used the project's plugin.
>>>> Anyone remember ?
>>>>
>>>> Michaël
>>>>
>>>> Sunburned Surveyor a écrit :
>>>>
>>>>> I've got about four plug-ins that I hope to release in January. This
>>>>> includes my reader for GPX files, the latest edition of the Super
>>>>> Select Tool, and a couple of Layer Utilities plug-ins.
>>>>>
>>>>> Some of these are simple plug-ins with a single Jar and no
>>>>> dependencies. So you can just drop them into the /ext folder of
>>>>> OpenJUMP. Other of my plug-ins, like the Super Select Tool and the GPX
>>>>> Reader, depend on external libraries and have I18N and configuration
>>>>> files. I had cooked up part of an installer for the Super Select Tool
>>>>> when I got to thinking that it might be nice to have a tool that could
>>>>> be used to install, uninstall, and update plug-ins for OJ. It wouldn't
>>>>> have to be a part of OJ, it could even run as a separate executable.
>>>>>
>>>>> I was thinking of this simple interface:
>>>>>
>>>>> public interface PlugInHandler
>>>>> {
>>>>> public abstract void installPlugIn(File argOpenJumpFolder);
>>>>>
>>>>> public abstract void uninstallPlugIn(boolean argRemoveSharedLibraries);
>>>>>
>>>>> public abstract void updatePlugIn();
>>>>> }
>>>>>
>>>>> I was thinking of another interface that could be used by
>>>>> PlugInHandler.installPlugIn method implementations to show a standard
>>>>> GUI to the user during plug-in installation/update:
>>>>>
>>>>> public class PlugInInstallerGuiProvider
>>>>> {
>>>>> public abstract JPanel getLicensePanel();
>>>>>
>>>>> public abstract JPanel getInstallConfigurationPanel();
>>>>>
>>>>> public abstract JPanel getAboutPanel();
>>>>> }
>>>>>
>>>>> I thought a library providing these interfaces and some default
>>>>> implementations might help us standardize plug-in management and make
>>>>> the process of installing and removing plug-ins a little easier on the
>>>>> end user.
>>>>>
>>>>> Do you guys have any comments on this?
>>>>>
>>>>> The Sunburned Surveyor
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
