> 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.
*(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
