[udig-devel] Re: [Geotools-devel] Scope of GeoWidgets (was gui module to

[Chris Holmes <cholmes@xxxxxxxxxxxxx>]

Quoting Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>:

> Chris Holmes wrote:
>
> > Ok, I may be off here on the intentions of geowidgets, but I'm
> wondering
> > 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
> bunch
> > of questions about why it's not in some releases (because it's in
> > legacy or migrate because no developers really support it).  I
> think it
> > could generate more interest for geowidgets, and would give us a
> more
> > contained place to point people looking for gui type functionality.
>
> There is really two things going on here. Rendering (and the model of
> Map/Layer(Data+Style) that rendering is based on. And widget such as
> SWT
> Container, Swing Panel or OpenGL Canvas (or GeoAPI Canvas abstraction
> of
> the same).
>
> 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.
Ok, this area is far from where my expertise in geotools lies.  But I
don't think I'm at advocating splitting out the rendering system (at
least not yet).  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'?

>
> The gui widget part is a bit more fun. We start to have events and
> threading issues and in general it is a bit more complicated. In the
> origional emails Mattias was looking to follow up his excelent
> contribution to uDig (of a CRS chooser) with something a bit more
> generic and reusable in SWT and Swing (and possibly even
> Spring/STRUTS).
>
> I had in mind GeoWidgets defining the a series of Models for things
> like
> CRS and then providing a widget that can be used to "edit" or
> "choose"
> the content.  SLD makes for an interesting example.
>
> Now these models are pretty *small*, the data is already defined by
> geotools, the model simple adds information such as the current
> "selection" and other book keeping values to to keep track of the
> view
> state. Any such model would have events (something that helps when
> the
> geotools data objects don't have a proper event system).
>
>
> Here is a perfect example:
>
http://svn.geotools.org/udig/trunk/plugins/net.refractions.udig.style.sld/src/net/refractions/udig/style/sld/simple/StrokeViewer.java
>
> Stroke viewer "edits" a SLD Stroke.
> It has a model:
>      boolean enabled = false;
>      Color color = null;
>      double width = Double.NaN;
>      double opacity = Double.NaN;
>
> And a view:
>      Button on;
>      StolenColorEditor chooser;
>      Combo size;
>      Combo percent;
>
> And a controler is contained in a sync() method.
>
> I would assume the widgets project would result in three jars:
> - geowidgets-model.jar
> - geowidgets-swing.jar
> - geowidgets-swt.jar
>
> The idea being that any opperation code that is shared between
> geoserver, udig, geovista and IanS's netbeans project can offer up
> geowidget models as a way for the hosting application to control
> their
> state.
>
> This was however only my understanding, the recent questions about
> Map/Layer and so on point in a different direction - towards the
> establishment of a neutral canvas for rendering content.
>
> There three paths forward on the model side of things:
> - GeoAPI Canvas/Graphic - not full evaulated
> - uDig Map/Viewport/Layer/StyleBlackboard - flexable, offers ideal
> separation, not quite what people expect
> - GeoTools Map/MapLayer/Style
>
> And three proposed targets for widgets: Java2D, SWT, OpenGL - on the
> rendering side they can all be hidden behind one interface (indeed we
> render to both Java2D and SWT for udig.
>
> Swing and SWT have a similar construct for an event thread, all it
> really amounts to is that any system better be based on commands. Ie
> Tools produce commands that effect the model. Of more concern is
> worker
> thread behavior and when/how they are allowed to update the model.
> Once
> again these are often best formulated as a command which the
> controller
> can execute in the appropriate thread.
>
> The hard part is keeping the models as pure data (aka they should not
> do
> work).
Sounds like good thoughts, again, far from where my expertise lies.

>
> > Perhaps it's not the intent of geowidgets to handle the same type
> of
> > things, but I like the idea of having geotools split up a bit more,
> so
> > that for example people wanting to hack on the gui stuff don't have
> to
> > build main every time.  Thoughts?
>
> 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?

> I know the existing gui classes had various tools defined as a series
> of
> callbacks for their "canvas". I would much rather see those things
> defined as proper commands con the canvas controler, and leave the
> registration and tool selection as an application specific concern.
>
> Basically I know geotools did not want to be an application, I want
> to
> confirm that GeoWidgets does not want to be an application.
Agreed.  Though with a name like geowidgets it seems like the intention
is not to be an application.

>
> > 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.
> SVN
> > at refractions, confluence and jira at codehaus, downloads at
> > sourceforge (well, you can get sf on your own).
>
> It is still a tricky problem :-) the data/model split.
> We should also ask James what he wants to do?
>
> As an example of the difficulty consider DataStore, it defines a nice
> data model for feature access.  It also defines an event model for
> driving user interfaces (and redraws).
>
> However it took two years before the first person (Jesse) hooked
> up the the event system and changed the bugs out.
>
> Currently the SLD implementation (named Style) completly lacks event
> notification.
>
> So james, how would you like us to proceed? Should we add event
> notification to the geotools classes? I know for example that this is
> one of the reasons we subclass DataStores so much in udig (so we can
> figure out when the connection is broken and provide user interface
> notification).

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.

Chris

>
> Jody
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/