Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[udig-devel] Scope of GeoWidgets (was gui module to geowidgets?) 
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.
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). 


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


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). 

Jody

Back to the top