Hi,
>> Not sure I understand how you want to manage true extensions.
>> I think an extension which is not included in PLUS distro still need to
>> be initialized through its initialize method rather than through
>> default-plugins.xml (or did I miss something).
>>> yes ;).. the "new" default-plugins.xml cannot only initialize, but also
>>> modify and/or place a plugin. it can even only do the second, leaving the
>>> initialization completely to the original extension.
>> Nice ! I forgot that. Is there a page explaining new default-plugin
>> syntax/options in the wiki. I did not found. Would be useful
> nope, was too lazy. plan to add a commented header to the xml file. didn't
> come around to do it 'til now.
>
> SNIP
>>> I think there may be a few reasons
>>> why it should go in plugins menu rather than in tools menu :
>>> - it may take place in another menu than tools
>> then why 'Plugins'? that's even more generic than 'Tools'
> Right. I think it makes sense for plugins added by the user. But it does
> not make sense for extensions like the one we add in PLUS version.
>
> maybe, but probably not, as users simply cannot expect extension's plugins to
> show up under 'Plugins'. that's up to the author (or us now).
>
> the actual point for me is probably to clean our main menu items. we
> essentially need
> File, Edit, View, Layer, Customize, Tools, Window, Help
> which makes
> Sextante, Raster, Plugins
> obsolete. they could easily go into 'Tools' eg. as submenus. #
>
> or even better, how about placing external* extension's plugins under a new
> main menu entry (exactly one) called 'Extensions'? this way a user could
> expect for them to appear there. just an idea.
That's exactly what the menu 'plugins' has been made for. In my
localized version, I called it 'Extensions' (in french). I don't
remember why it has ended up as 'Plugins' in english. A little confusing.
That said, we have no reason (and no easy way) to "force" extension's
author to use this menu. For me, This menu is mainly an incitative way
to gather free extensions.
Maybe Raster should stay appart as suggested by Stefan and Peppe.
Sextante could make its place in 'Extensions'.
Michaël
>
> *(meaning undefined in default-plugins.xml, because not delivered with an OJ
> edition)
>
> SNIP
>>>> - it may be easier to find a tool in plugins menu for a user if he knows it
>>>> added it as an extension (dropping a jar in ext dir)
>>> as i understand it, only a minority of our extensions are placed into
>>> 'Plugins'.
>> Not sure. And extensions which are not in plugins menu are often out of
>> tools menu (sextante, drivers, printer, colorchooser...)
> exactly my point. we should decide, whether here or there, but not in both
> places.
>
>>>> Note that I'm not against moving current extensions from Plugins to
>>>> Tools where it makes sense, but redirecting MenuNames.PLUGIN to
>>>> MenuNames.TOOLS seems a bit rough.
>>> just a way to prevent unknown extensions to place themselves into 'Plugins'
>>> after we took the effort to remove it.
>> I see.
>> I now remember when I created the "plugins" menu that I wanted to avoid
>> the multiplication of main menus (sextante, roadmatcher create their own
>> menu, and extension authors tend to create a new menu for each new
>> extension).
> yeah, we could prevent that programmatically. how about the Extensions menu
> above? i choose the name because it resembles what lands in there. external
> plugins installed by extensions.
>
> on the other hand, why make a difference? why not stuff all extensions,
> whether external or not, under Tools and have users expect them there?
>
> so many possibilities :)
>
>> So I would say that you re right when you want to place plugins at their
>> right place rather than in plugins menu, but as you can't avoid plugin
>> authors to create their own menu,
> well, i can.. as the API goes through FeatureInstaller which we control ;)..
> of course could an author still hack around that, but for the sake of
> argument let's say we can.
>
>> letting a plugins menu maybe an
>> incitative way to gather extensions in a single menu rather than letting
>> them spread along the menu bar in an inconsistent way ("plugin",
>> "extension", "extensions", "myextensions"...)
> which again makes me suggest to redirect attempts to create a submenu in our
> main menu to some other menu ('Extensions','Tools','Plugins') to keep the
> main menu clean.
>
> of course that would defy the Open in OpenJUMP quite a bit. so maybe we just
> settle to place delivered extensions in PLUS properly, like i already did
> with the Printer Plugin. this would mean anything under 'Plugins', 'Sextante'
> and 'Raster' would go under 'Tools' or wherever else we think approriate.
>
> Jukka, what do you think?
>
> ..ede
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Jump-pilot-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
