[JPP-Devel] Request from OJ the Merge

[Giuseppe Aruta]

  Hi all,
on OpenJUMP the Merge it was possible to substitute the value of attributes 
using a tool "Replace value", from Layer menu.
 I think this tool could be very useful ported in OpenJUMP. I ask if it is 
possible. Thanks

Peppe




  Hai un indirizzo email difficile da ricordare?
Scegli quello che hai sempre desiderato su Yahoo! Mail
http://it.docs.yahoo.com/nuovo_indirizzo.html-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] R: disable/deactivate menu with plugin?

[Larry Becker]

There is always the " -properties workbench-properties.xml" switch. Just
modify it to point to another path.

Larry

On Wed, Jul 2, 2008 at 10:36 PM, Stefan Steiniger <[EMAIL PROTECTED]> wrote:

> Ok... now the big question:
>
> how can tell OJ to use two workbecnh-properties files?
> because I don't want to mix up the OJ plugins with my own plugins that I
>  programmed over the years?
>
> If one could use multiple files, then this would also make Larrys note
> obsolete.
>
> Stefan
>
> Larry Becker schrieb:
> > Hi Stefan,
> >
> >   Nice work.  I can think of one small issue related to the installer.
> > It will now be necessary to distribute the workbench-properties.xml
> > file.  This means that if someone customizes their file, it will be
> > replaced on the next update, as this will be necessary to get new
> > features in new releases.  People will have to get used to keeping an
> > old copy of their customizations and reapplying them after each update.
> >
> > regards,
> > Larry
> >
> > On Tue, Jul 1, 2008 at 7:07 PM, Stefan Steiniger <[EMAIL PROTECTED]
> > > wrote:
> >
> > Hei,
> >
> > @Paolo... I think I regard your points as nice to have (with respect
> to
> > server-client stuff: although I know that Jump has been also used as
> > base for a web-gis-server ;)
> >
> > @all:
> > I moved today the workbench-properties.xml around to the bin folder.
> So
> > if the next nightly build works with test plugin (I found a very olf
> > "Magnifyer" function ;o) we can start moving first the additional OJ
> > plugins (except data IO). Then we need to check how it will affect
> the
> > ordering of the functions in the menus. I expect a lot of refactoring
> > just for that. But I think we will not break anything, as the changes
> > will be only for the (new to add) initialize methods, i.e. on the gui
> > side only.
> >
> > => any comments on that?
> > mhm.. may be one from myself: The removal of menus such as suggested
> by
> > Carl will not be possible (e.g. the complete removal of tht "Tools"
> > menu), except we are able to move all functions into the xml file for
> > one menu.
> >
> > Something different: I also moved some of the functions in
> > tools/analysis/ to two new submenus.
> >
> > stefan
> >
> > P.Rizzi Ag.Mobilità Ambiente schrieb:
> >  > If I can tell my opinion the whole configuraiton should be in the
> > xml file.
> >  > I don't like the way some plugins are "hardly" configured in Java
> > code.
> >  >
> >  > There should be nothing really "basic" and hardly configured,
> > because it
> >  > will be impossible to remove that and, besides, what is really
> > "basic"
> >  > depends upon what each person would do with OJ.
> >  >
> >  > Then a series of pre-canned XML file could be prepared so that
> > several
> >  > "common" OJ configuration could be started, by choosing one of
> them.
> >  >
> >  > Problem is plugin dependency, but that could be leaved in the
> > hand of the user,
> >  > or whoever prepare the XML file, so that each configuration is
> > coherent
> >  > and working. Or a real third-party container can be used, but
> > that would be
> >  > a very big change in code and philosophy...
> >  >
> >  > I'm sorry this is just my vision, but I can't put any effort into
> > it :-(
> >  >
> >  > Bye
> >  > Paolo Rizzi
> >  >
> >  >
> >  > P.S: And if one day OJ would be so modular that it can be
> > splitted into
> >  > a server part and a client (GUI) part, a special XML file would
> > be used
> >  > to launch a server-only configuration, and then a Web UI could be
> > developed,
> >  > or any WMS client may connect to it.
> >  >
> >  >
> >  >> -Messaggio originale-
> >  >> Da: [EMAIL PROTECTED]
> > 
> >  >> [mailto:[EMAIL PROTECTED]
> > ]Per conto di
> >  >> Stefan Steiniger
> >  >> Inviato: lunedì 30 giugno 2008 18.27
> >  >> A: OpenJump develop and use
> >  >> Oggetto: Re: [JPP-Devel] disable/deactivate menu with plugin?
> >  >>
> >  >>
> >  >> my 2 cents:
> >  >>
> >  >> . Yes for porting the functionality (didn't we ported already)
> >  >> . Question: what do we do then? Move all of the stuff in
> >  >> OpenJUMP/Jump
> >  >> configuration which is not "basic" (basic could be anything that
> is
> >  >> tools) to the xml file?
> >  >> . @Larry:
> >  >> - Can you send such xml file? I would like to see how it
> >  >> looks like. [or
> >  >> is it in fact looking exactly like the workbench-properties.xml
> > file?]
> >  >>
> >  >> stefan
> >  >>
> >  >> Sunburned Surveyor wrote:
> >  >>> I second the comments from Andreas. If I could help port this
> > 

Re: [JPP-Devel] Request from OJ the Merge

[Larry Becker]

Hi Peppe,

  How is the "Replace value" tool different from the "Replace Attribute
Value" tool found under Tools -> Edit Attributes?

regards,
Larry

2008/7/3 Giuseppe Aruta <[EMAIL PROTECTED]>:

> Hi all,
> on OpenJUMP the Merge it was possible to substitute the value of attributes
> using a tool "Replace value", from Layer menu.
> I think this tool could be very useful ported in OpenJUMP. I ask if it is
> possible. Thanks
>
> Peppe
>
>
> --
> Hai un indirizzo email difficile da ricordare?
> Scegli quello che hai sempre desiderato
> prima che lo faccia 
> qualcun'altro!.
>
> Tantissimi nuovi indirizzi sono ora disponibili su Yahoo!
>
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>


-- 
http://amusingprogrammer.blogspot.com/
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] The internal Task.TaskNameListener interface is not necessary.

[Sunburned Surveyor]

See if you can follow this logic.

The Task class declares an internal interface named TaskNameListener.
This internal interface contains a single methor,
taskNameChanged(String argName). There is only one class that
implements this interface, TaskFrame.

However, TaskFrame never uses the String argument from this method. If
there is a name change the TaskFrame accesses the name from the Task
it displays directly.

Unless we think there will be other implementations of the
TaskNameListener in the future, I recommend we remove the
Task.TaskNameListener interface. It is unecessary "code fat". We
should do this instead:

- Replace the list of Task.TaskNameListeners in each Task object with
a list of TaskFrame references.
- Leave a no-argument taskNameChanged method on the TaskFrame class.
- When a TaskFrame is being constructed to display a Task, add a
reference to the TaskFrame to the list of TaskFrames in the Task that
will be displayed.

This will accomplish the same thing, without the need for the
TaskNameListener interface and the taskNameChanged(String argName)
method whose String argument is never used.

The Sunburned Surveyor

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Changes to the TaskFrame class and related classes.

[Sunburned Surveyor]

I have made the following minor changes to improve the TaskFrame class
and related classes:

- Changed the WorkbenchFrame.getInternalFramesAssociatedWith(TaskFrame
argTaskFrame) method access from private to public.
- Changed the WorkbenchFrame.getTaskFramesAssociatedWith(LayerManager
argLayerManager) method access from private to public.
- Modified the WorkbenchFrame.getTaskFramesAssociatedWith(LayerManager
argLayerManager) to use Java Generics.
- Eliminated private constructor in TaskFrame class.
- Modified try/catch statement in constructor of TaskFrame class to
use WorkbenchFrame.handleThrowable method.
- Eliminated the TaskFrame.setTask method.
- Removed the depracated cloneIndex mechanism and completed its
replacement with storage of the cloneIndex in the LayerManager
Blackboard.
- Added a isAClone private boolean member variable.
- Added the public.TaskFrame.isAClone method.
- Added the private TaskFrame.setIsAClone method.
- Modified the TaskFrame.internalFrameClone method to set the isAClone
boolean member variable.
- Modified the updateTitle method to distinguish between TaskFrames
that are clones and not clones when updating the title of a TaskFrame.
- Added the private TaskFrame.createAndSetTaskFrameListener method to
properly add a TaskFrameListener to a TaskFrame when it is
constructed.
- Added the private getCurrentNumberOfClones method to access the
blackboard for the current number of TaskFrame clones. The TaskFrame
class only contained a method to get the NEXT clone number previously.
(This new method is used in the TaskFrame.updateTitle metjhod.)

Please let me know if you have any questions about these changes.

The Sunburned Surveyor

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] R: disable/deactivate menu with plugin?

[Stefan Steiniger]

Hei Larry,

Want I meant is a bit different (sorry for all the spelling errors). My 
problem is that I want to provide 2 property files. In Eclipse I tried 
it with 2 times calling -properties with different files, but then it 
picks only the first one.

Stefan

Larry Becker wrote:
> There is always the " -properties workbench-properties.xml" switch. Just 
> modify it to point to another path.
> 
> Larry
> 
> On Wed, Jul 2, 2008 at 10:36 PM, Stefan Steiniger <[EMAIL PROTECTED] 
> > wrote:
> 
> Ok... now the big question:
> 
> how can tell OJ to use two workbecnh-properties files?
> because I don't want to mix up the OJ plugins with my own plugins that I
>  programmed over the years?
> 
> If one could use multiple files, then this would also make Larrys note
> obsolete.
> 
> Stefan
> 
> Larry Becker schrieb:
>  > Hi Stefan,
>  >
>  >   Nice work.  I can think of one small issue related to the
> installer.
>  > It will now be necessary to distribute the workbench-properties.xml
>  > file.  This means that if someone customizes their file, it will be
>  > replaced on the next update, as this will be necessary to get new
>  > features in new releases.  People will have to get used to keeping an
>  > old copy of their customizations and reapplying them after each
> update.
>  >
>  > regards,
>  > Larry
>  >
>  > On Tue, Jul 1, 2008 at 7:07 PM, Stefan Steiniger
> <[EMAIL PROTECTED] 
>  > >> wrote:
>  >
>  > Hei,
>  >
>  > @Paolo... I think I regard your points as nice to have (with
> respect to
>  > server-client stuff: although I know that Jump has been also
> used as
>  > base for a web-gis-server ;)
>  >
>  > @all:
>  > I moved today the workbench-properties.xml around to the bin
> folder. So
>  > if the next nightly build works with test plugin (I found a
> very olf
>  > "Magnifyer" function ;o) we can start moving first the
> additional OJ
>  > plugins (except data IO). Then we need to check how it will
> affect the
>  > ordering of the functions in the menus. I expect a lot of
> refactoring
>  > just for that. But I think we will not break anything, as the
> changes
>  > will be only for the (new to add) initialize methods, i.e. on
> the gui
>  > side only.
>  >
>  > => any comments on that?
>  > mhm.. may be one from myself: The removal of menus such as
> suggested by
>  > Carl will not be possible (e.g. the complete removal of tht
> "Tools"
>  > menu), except we are able to move all functions into the xml
> file for
>  > one menu.
>  >
>  > Something different: I also moved some of the functions in
>  > tools/analysis/ to two new submenus.
>  >
>  > stefan
>  >
>  > P.Rizzi Ag.Mobilità Ambiente schrieb:
>  >  > If I can tell my opinion the whole configuraiton should be
> in the
>  > xml file.
>  >  > I don't like the way some plugins are "hardly" configured
> in Java
>  > code.
>  >  >
>  >  > There should be nothing really "basic" and hardly configured,
>  > because it
>  >  > will be impossible to remove that and, besides, what is really
>  > "basic"
>  >  > depends upon what each person would do with OJ.
>  >  >
>  >  > Then a series of pre-canned XML file could be prepared so that
>  > several
>  >  > "common" OJ configuration could be started, by choosing
> one of them.
>  >  >
>  >  > Problem is plugin dependency, but that could be leaved in the
>  > hand of the user,
>  >  > or whoever prepare the XML file, so that each configuration is
>  > coherent
>  >  > and working. Or a real third-party container can be used, but
>  > that would be
>  >  > a very big change in code and philosophy...
>  >  >
>  >  > I'm sorry this is just my vision, but I can't put any
> effort into
>  > it :-(
>  >  >
>  >  > Bye
>  >  > Paolo Rizzi
>  >  >
>  >  >
>  >  > P.S: And if one day OJ would be so modular that it can be
>  > splitted into
>  >  > a server part and a client (GUI) part, a special XML file
> would
>  > be used
>  >  > to launch a server-only configuration, and then a Web UI
> could be
>  > developed,
>  >  > or any WMS client may connect to it.
>  >  >
>  >  >
>  >  >> -Messaggio originale-
>  >  >> Da: [EMAIL PROTECTED]
> 
>  >  

Re: [JPP-Devel] Request from OJ the Merge

[Stefan Steiniger]

:)

it should be the same, as I ported it - but renamed it for clarification

stefan

Larry Becker wrote:
> Hi Peppe,
> 
>   How is the "Replace value" tool different from the "Replace Attribute 
> Value" tool found under Tools -> Edit Attributes?
> 
> regards,
> Larry
> 
> 2008/7/3 Giuseppe Aruta <[EMAIL PROTECTED] 
> >:
> 
> Hi all,
> on OpenJUMP the Merge it was possible to substitute the value of
> attributes using a tool "Replace value", from Layer menu.
> I think this tool could be very useful ported in OpenJUMP. I ask if
> it is possible. Thanks
> 
> Peppe
> 
> 
> 
> Hai un indirizzo email difficile da ricordare?
> Scegli quello che hai sempre desiderato
> prima che lo faccia qualcun'altro!
> .
> Tantissimi nuovi indirizzi sono ora disponibili su Yahoo!
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 
> 
> 
> 
> -- 
> http://amusingprogrammer.blogspot.com/
> 
> 
> 
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> 
> 
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] R: disable/deactivate menu with plugin?

[Larry Becker]

I'm sure that would be a relatively easy mod to the code that loads the
workbench-properties.  We can define a convention that your
workbench-properties file will be called, say, my-workbench-properties.xml.
Then all we have to do is add the "my-" and load it too.

regards,
Larry

On Thu, Jul 3, 2008 at 11:33 AM, Stefan Steiniger <[EMAIL PROTECTED]> wrote:

> Hei Larry,
>
> Want I meant is a bit different (sorry for all the spelling errors). My
> problem is that I want to provide 2 property files. In Eclipse I tried
> it with 2 times calling -properties with different files, but then it
> picks only the first one.
>
> Stefan
>
> Larry Becker wrote:
> > There is always the " -properties workbench-properties.xml" switch. Just
> > modify it to point to another path.
> >
> > Larry
> >
> > On Wed, Jul 2, 2008 at 10:36 PM, Stefan Steiniger <[EMAIL PROTECTED]
> > > wrote:
> >
> > Ok... now the big question:
> >
> > how can tell OJ to use two workbecnh-properties files?
> > because I don't want to mix up the OJ plugins with my own plugins
> that I
> >  programmed over the years?
> >
> > If one could use multiple files, then this would also make Larrys
> note
> > obsolete.
> >
> > Stefan
> >
> > Larry Becker schrieb:
> >  > Hi Stefan,
> >  >
> >  >   Nice work.  I can think of one small issue related to the
> > installer.
> >  > It will now be necessary to distribute the
> workbench-properties.xml
> >  > file.  This means that if someone customizes their file, it will
> be
> >  > replaced on the next update, as this will be necessary to get new
> >  > features in new releases.  People will have to get used to keeping
> an
> >  > old copy of their customizations and reapplying them after each
> > update.
> >  >
> >  > regards,
> >  > Larry
> >  >
> >  > On Tue, Jul 1, 2008 at 7:07 PM, Stefan Steiniger
> > <[EMAIL PROTECTED] 
> >  > >> wrote:
> >  >
> >  > Hei,
> >  >
> >  > @Paolo... I think I regard your points as nice to have (with
> > respect to
> >  > server-client stuff: although I know that Jump has been also
> > used as
> >  > base for a web-gis-server ;)
> >  >
> >  > @all:
> >  > I moved today the workbench-properties.xml around to the bin
> > folder. So
> >  > if the next nightly build works with test plugin (I found a
> > very olf
> >  > "Magnifyer" function ;o) we can start moving first the
> > additional OJ
> >  > plugins (except data IO). Then we need to check how it will
> > affect the
> >  > ordering of the functions in the menus. I expect a lot of
> > refactoring
> >  > just for that. But I think we will not break anything, as the
> > changes
> >  > will be only for the (new to add) initialize methods, i.e. on
> > the gui
> >  > side only.
> >  >
> >  > => any comments on that?
> >  > mhm.. may be one from myself: The removal of menus such as
> > suggested by
> >  > Carl will not be possible (e.g. the complete removal of tht
> > "Tools"
> >  > menu), except we are able to move all functions into the xml
> > file for
> >  > one menu.
> >  >
> >  > Something different: I also moved some of the functions in
> >  > tools/analysis/ to two new submenus.
> >  >
> >  > stefan
> >  >
> >  > P.Rizzi Ag.Mobilità Ambiente schrieb:
> >  >  > If I can tell my opinion the whole configuraiton should be
> > in the
> >  > xml file.
> >  >  > I don't like the way some plugins are "hardly" configured
> > in Java
> >  > code.
> >  >  >
> >  >  > There should be nothing really "basic" and hardly
> configured,
> >  > because it
> >  >  > will be impossible to remove that and, besides, what is
> really
> >  > "basic"
> >  >  > depends upon what each person would do with OJ.
> >  >  >
> >  >  > Then a series of pre-canned XML file could be prepared so
> that
> >  > several
> >  >  > "common" OJ configuration could be started, by choosing
> > one of them.
> >  >  >
> >  >  > Problem is plugin dependency, but that could be leaved in
> the
> >  > hand of the user,
> >  >  > or whoever prepare the XML file, so that each configuration
> is
> >  > coherent
> >  >  > and working. Or a real third-party container can be used,
> but
> >  > that would be
> >  >  > a very big change in code and philosophy...
> >  >  >
> >  >  > I'm sorry this is just my vision, but I can't put any
> > effort into
> >  > it :-(
> >  >  >
> >  >  > Bye
> >  >  > Paolo Riz

Re: [JPP-Devel] R: disable/deactivate menu with plugin?

[Stefan Steiniger]

mhm.. that is a interesting and simple (=doable) idea :)
one could actually also fix the name for the standard file, e.g. 
standard-plugins.xml or stdplugin-config.xml or so

stefan

Larry Becker wrote:
> I'm sure that would be a relatively easy mod to the code that loads the 
> workbench-properties.  We can define a convention that your 
> workbench-properties file will be called, say, 
> my-workbench-properties.xml.  Then all we have to do is add the "my-" 
> and load it too.
> 
> regards,
> Larry
> 
> On Thu, Jul 3, 2008 at 11:33 AM, Stefan Steiniger <[EMAIL PROTECTED] 
> > wrote:
> 
> Hei Larry,
> 
> Want I meant is a bit different (sorry for all the spelling errors). My
> problem is that I want to provide 2 property files. In Eclipse I tried
> it with 2 times calling -properties with different files, but then it
> picks only the first one.
> 
> Stefan
> 
> Larry Becker wrote:
>  > There is always the " -properties workbench-properties.xml"
> switch. Just
>  > modify it to point to another path.
>  >
>  > Larry
>  >
>  > On Wed, Jul 2, 2008 at 10:36 PM, Stefan Steiniger
> <[EMAIL PROTECTED] 
>  > >> wrote:
>  >
>  > Ok... now the big question:
>  >
>  > how can tell OJ to use two workbecnh-properties files?
>  > because I don't want to mix up the OJ plugins with my own
> plugins that I
>  >  programmed over the years?
>  >
>  > If one could use multiple files, then this would also make
> Larrys note
>  > obsolete.
>  >
>  > Stefan
>  >
>  > Larry Becker schrieb:
>  >  > Hi Stefan,
>  >  >
>  >  >   Nice work.  I can think of one small issue related to the
>  > installer.
>  >  > It will now be necessary to distribute the
> workbench-properties.xml
>  >  > file.  This means that if someone customizes their file,
> it will be
>  >  > replaced on the next update, as this will be necessary to
> get new
>  >  > features in new releases.  People will have to get used to
> keeping an
>  >  > old copy of their customizations and reapplying them after
> each
>  > update.
>  >  >
>  >  > regards,
>  >  > Larry
>  >  >
>  >  > On Tue, Jul 1, 2008 at 7:07 PM, Stefan Steiniger
>  > <[EMAIL PROTECTED] 
> >
>  >  > 
>   >  >
>  >  > Hei,
>  >  >
>  >  > @Paolo... I think I regard your points as nice to have
> (with
>  > respect to
>  >  > server-client stuff: although I know that Jump has
> been also
>  > used as
>  >  > base for a web-gis-server ;)
>  >  >
>  >  > @all:
>  >  > I moved today the workbench-properties.xml around to
> the bin
>  > folder. So
>  >  > if the next nightly build works with test plugin (I
> found a
>  > very olf
>  >  > "Magnifyer" function ;o) we can start moving first the
>  > additional OJ
>  >  > plugins (except data IO). Then we need to check how it
> will
>  > affect the
>  >  > ordering of the functions in the menus. I expect a lot of
>  > refactoring
>  >  > just for that. But I think we will not break anything,
> as the
>  > changes
>  >  > will be only for the (new to add) initialize methods,
> i.e. on
>  > the gui
>  >  > side only.
>  >  >
>  >  > => any comments on that?
>  >  > mhm.. may be one from myself: The removal of menus such as
>  > suggested by
>  >  > Carl will not be possible (e.g. the complete removal
> of tht
>  > "Tools"
>  >  > menu), except we are able to move all functions into
> the xml
>  > file for
>  >  > one menu.
>  >  >
>  >  > Something different: I also moved some of the functions in
>  >  > tools/analysis/ to two new submenus.
>  >  >
>  >  > stefan
>  >  >
>  >  > P.Rizzi Ag.Mobilità Ambiente schrieb:
>  >  >  > If I can tell my opinion the whole configuraiton
> should be
>  > in the
>  >  > xml file.
>  >  >  > I don't like the way some plugins are "hardly"
> configured
>  > in Java
>  >  > code.
>  >  >  >
>  >  >  > There should be nothing really "basic" and hardly
> configured,
>  >  >