Skip to end of metadata
Go to start of metadata

General design guidelines and goals

Division of tasks

The purpose of the three mentioned projects is clear enough to have a good division of work between them. I suggest following:

  • GeoTools
    • Contain the interfaces (API) and standard implementations of the object interfaces 1
    • Be as UI toolkit independent as possible
  • GeoWidgets
    • Care about the UI interfaces 1 and implementations,
    • Provide adapters from AWT to SWT, where necessary (or should they live in GeoTools as well?)
    • Build on all the before mentioned things
    • Provide widgets for AWT/Swing, SWT and others
    • Give feedback to GeoTools
  • uDig
    • Extend the provided interfaces for own needs, where necessary
    • Extend the widgets for own needs
    • Give feedback to both GeoTools and GeoWidgets

1 See next section

Object interfaces, Application interfaces and UI interfaces

I believe that it is important to separate data interfaces from UI interfaces. Object interfaces describe objects with fields, methods and functions that are independent of any UI toolkit. (With the caveat that even simple classes like "Icon" and "Color" are toolkit dependent. But that's another topic.) They need not (and should not) even be aware that there is some application or widget that uses them. All they need to do is provide the possibility to register listeners.
Application interfaces might extend the object interfaces in order to store application-specific data in the classes or to provide application-specific behaviour or functions. While the object interfaces should be kept free from dependencies on specific projects (such as Eclipse, uDig, GeoWidgets), the application interfaces do not have such limitation.
Also in contrast to the object interfaces, UI interfaces require separate implementations for each UI toolkit. They are directly aimed at visible components, and it might even be necessary to have separate interfaces for AWT/Swing and SWT, although I'd like to avoid this if possible.

Now, how does this work within our projects? Maybe so:

GeoTools:

Object interfaces, (UI interfaces?)

GeoWidgets:

(Application interfaces?), UI interfaces

uDig:

Application interfaces

Other proposed guidlines

  • Intuitive and flexibile. I mention them together, because I suggest that the GeoTools interfaces are kept deliberately simple and intuitive, but allow to be extended easily whenever applications like uDig require additional functions - and they certainly do.
  • Keep the object interfaces free from implementation internals. What I mean is, that Blackboards, Picocontainers and the like should not appear in object interfaces. The can reside in application interfaces. For object interfaces there are usually other solutions.
  • Java5 vs Java1.4. Interfaces must exist and work in a Java1.4, since this is required by the GeoTools project. I'd like to have Java5 versions as well. The design of the interfaces is heavily influenced by the Java version: When working for Java5 only one could do very nice things with "typing" of classes and would probably use Collections more often. While working in Java 1.4, the mentioned typed classes introduce lots of casts and are much harder to understand and to use. Probably a good argument to use them sparsely.

Goals - What do we want for the API and how do we want it?

Following concepts have been suggested by GeoTools members and have found wide acceptance:

  • Proxies(handles) to the data. The "data" stored in a map layer does not contain the data directly, but aquired the data on request from the file, from the internet or from another source.
  • Specialized renderers. This means, that there exist multiple renderers, each one having specific capabilities. The rendering framwork chooses the fastest one (or the one with the best capabilities) from the list of suitable renderers for each data type in a layer. Renderers can cope with one or multiple data types. Here is Andrea's comment:
    • specialized renderers that can leverage the specific nature of the data source [...]
    • choice of different algorithms, for labeling, for example;
    • choice of different trade offs between memory usage and performance (for example, using memory based renderer for small data sets, so that at least those can be rendered instantly)
    • choice of different strategies to handle raster data (for example, we don't really need JAI to renderer a Jpeg or GIF image that does not need to be reprojected)
    Here is Jesses comment

    I personally think that having multiple renderers is better than having one.[...] There are a number of reasons. One is that each renderer is easier to understand because they each have a specific understandable job. Further it allows developers to choose the renderers for their specific application, rather than being forced to use the generic renderer or write a new renderer.

  • Renderer sub modules and interaction. Renderers need to exchange information. It should also be possible to reuse code such as for label rendering, within different renderers. Here is Dave's comment:

    For example, if I spend a lot of time making the labeling in lite "smart", will that work be transferable to the other renderers (ie. shape renderer, and Z Renderer)? If its not, then its harder to justify the work if my postgis layers look good but my shapefiles look 'crappy'.
    What I'm saying is we should consider having rendering components plug-and-playable so we can re-use sub-modules.

    Andrea wrote:

    Maybe we could split the renderer into two component, the data source interaction that builds shapes and resolved styles, and the pure rendering one that does the painting.
    On labeling and separate rendereres, there are other things to consider. Say you want to avoid label overlapping, but you are labeling multiple layers. This requires that those renderers are aware of each other, and work in team. What needs to work togher is only the painting part I guess, since in order to achieve this results you need to load every label into memory first (compute its bouding box, and also have a reference to the labelled geometry in order to know where the label can be moved to avoid overlaps).

Other comments so far

This is a loose, unordered collection of comments I received, which I havn't yet evaluated or put into their correct context:
Richard wrote:

Something else you might want to consider is something that I do for the printing UI in uDig - I have an API set up that will ask a Box to paint itself on an AWT Graphics object, and then it will paint that Graphics object onto a Draw2D canvas (but it works for SWT as well)

Which way to go? Do we need a completely new framework?

Given that both existing frameworks in GeoTools and uDig work for each of them, the question must be raised, whether a completely new framework is desireable or not. The GeoTools framwork does not offer specialized renderers and data proxies, which are desired by uDig. The uDig framework is, in its current state, impossible to use for GeoTools since it is too tightly tied to uDig and Eclipse.
So we will need to create a new framework. The question is rather:

  • Do we take the chance of putting all our ideas and wishes into it and accept the prospect that compatibility with existing classes and interfaces might not be possible in most cases (which means lots of adaptation work) or
  • do we choose a solution with as less effort as possible and as much compatibility to the existing framework as possible and accept that the result might not be completely consistent and will not offer more than, in the very best case, the combined advantages of both solutions.
  • No labels

1 Comment

  1. I've personally always thought a gui framework should be in project like geowidgets, not in geotools itself, so I see no problems with using the migration as an opportunity to create a new one. Though would be good to get Martin D on board with the new solution, as he's done a lot of the code for the gui stuff in geotools.

    Related to that, I think Java 5 interfaces should be fine for geowidgets, the gui should be a layer above, and so geotools shouldn't be using those interfaces. I'm probably the most strict about keeping geotools on Java 1.4, but if gui stuff goes to this project, it should be able to use whatever it wants. The big reason for the 1.4 requirement is server side stuff, server admins upgrade a lot more slowly. For desktop/gui stuff requiring 1.5 is fine.