[udig-devel] Breakdown of scope between projects

[Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>]

Chris Holmes wrote:

> > > if we could consider moving the 'gui' module from geotools to
> > > geowidgets.  You know the one that few of us use, that we get a

Yeah I understood your point - I was just trying to confirm what 
Matthias and James intended.

> > I could totally see the rendering system being broken out (and made
> > to opperate against interfaces). It is more then pure view, it is pure
> > visualization.

> don't think I'm at advocating splitting out the rendering system (at
> least not yet).

James was - the shapefile renderer module scared him, we only want to 
break out modules when they can hide safely behind an interface.

  All I was thinking of was these classes:
> http://svn.geotools.org/geotools/trunk/gt/module/migrate/src/org/geotools/gui/
>
> They're in migrate, but I don't know that anyone is going to actually do
> the migrate.  I'm suggesting we migrate them into geowidgets.  Or will
> geowidget be a refactoring?  Basically when people ask 'where did the
> gui module go?' can I say 'look at geowidgets'?

Lol - that is a sensible plan. But we do have to consider the where at a 
technical level such a split should occur.

> > GeoAPI
> > - specifications (such as SLD, Feature, Filter)
> > GeoTools
> > - data objects (such as SLD, Feature, Filter)
> > - visualization (such as renderers, Canvas)
> > GeoWidgets
> > - model (wraps data w/ events)
> > - controler (allows modification of model via commands)
> > - widgets (swt,swing,opengl)
> > - canvas (such as Java2D, Draw2D, OpenGL raster)
> > UDig
> > - Formal breakdown into plugins, tools, keyboard shortcuts
>
>
> This break down sounds good to me.  Though you have canvas twice, in
> geotools under visualization, and in geowidgets.  Or does gt2 define
> the general, and geowidgets the individual interfaces?

gt2 defined the interface (or we could use the GeoAPI Canvas/Graphic 
interfaces) and geowidgets would have the Swing and SWT implementations. 
 The interface needs to be defined at the geotools level or higher so 
that the renderer can opperate against them.

> > > Also, Matthias - I'm sure we can find you some tools to support
> > your
> > > project, if you're willing to commit to it and take a decent lead.

Yeah I second that Matthias - if you are not already set up lets get 
this show on the road :-)

> Is there a nice way to separate it out?  Though I think I'm fine with
> event notification in gt2, as long as it's actually maintained and used
> - which hasn't been the case in the past.

It could be that the geotools classes should just bite the bullet and 
issue modification events?  I generally get worried when things start to 
have events - it is a real hinderence to reuse.

There is a reason why GeoAPI has Feature interface without events, and 
Graphic representation of a Feature w/ events.  Such separations are 
good, often application writers have a preexisting data structure they 
just want to see on a map - the less that is needed to support the 
Feature interface the more likely they are to use geotools. This benifit 
is the only thing the JUMP Feature system does bettern then us.

Jody