[udig-devel] Re: use of swing

[Matthias Basler]

Adrian wrote:
> Looks like each one of us gets to have a go at answering you. :-)

Now is my turn. ;-)

> [...] The current state of those projects is that
> any can get you started down a particular approach but with each you
> will quickly end up on your own.

... which not only I find unsatisfying.

Given that we have (at least) four approaches to the same basic problem:
- JMapPane in geotools
- GeoWidgets project
- OGC GO-1 specification
- uDig's widgets

it should be possible to create something out of it that gets people going much more quickly. This was my idea 1.5 years ago and I still consider it a good idea, although my first attempt to realize it with the GeoWidgets project suffered from a series of shortcomings:

1. Building widgets for Swing AND SWT at the same time did turn out to be much more work than I expected. Almost no chance of sharing any code...

2. Probably the worst shortcoming: GeoWidgets was a one man project, so although I get a lot of help for my questions there was a lack on coordination, code review and way too few feedback on the question whether I was running into the right or wrong direction with some coding details. Partly my fault, sure!
Also I alone don't feel capable of keeping pace with the developments in GeoTools/uDig - and I don't understand some parts of the library well enough either.

3. Problems with the "road to go", especially
  - Should GeoWidgets continue to support both Swing/AWT and SWT?
    Regularily users query for Swing, JMapPane is Swing. On the other hand
    I am meanwhile working with SWT/JFace and uDig also is. Hmm...
  - Should it support only Geotools or should it support other GIS
    libraries via an additional layer of abstraction? I tried this
    and it leads to overly complicated/inconvenient APIs.
  - Should it be "freestyle" (i.e. as feature rich as possible") or
    should it try to follow the restrictions of some specification(s),
    lets say GO-1?
  - Which version of Geotools was/is stable enough but has enough
    features to serve as a sustainable basis for Geowidgets without
    having to rewrite half of it for the next version?
    Still an issue for me.

4. Problems with the status of GeoTools, it did not support all the
   features that I wanted to have in my widgets - and sometimes cannot,
   since it restricts itself to a lot of specs.
   (Example: No map layer groups in Geotools.)

5. Different goals. I am geared towars a desktop GIS and image processing,
  GeoTools/uDig still has its priority in WebGIS (OGC) and vector data.

6. Lack of time (I am currently busy on DB related software.)
  Problem is: Spending "a bit of time" on such project does not work,
  it takes a lot of time just to keep up to date to what is going on
  in GeoTools and uDig community and which API might be deprecated
  tomorrow.

If we all have good ideas on how to solve the above problems I am definitely willing to continue work on GeoWidgets (maybe this winter). But I think it requires a coordinated effort between GeoTools, uDig, me and others that are interested in and capable of UI programming. Otherwise it will not be practicable and the result will not meet everybody's goals.

The planned step to extract some of the uDig widgets and contribute them to GeoWidgets would certainly be a good idea - not only would it increase the number of widgets in the GeoWidgets project, but  - more important - it would also ensure that the code base is actively used - which means better coordination, quality control a.s.o.

(Sorry for the rant.)

P.S. Question to Amy Johnson:
Are you just looking for existing widgets (which if so?) or do you have interest in working to improve the situation?
-- 
Matthias Basler
matthiasbasler at earthflight.org