Skip to end of metadata
Go to start of metadata

This page is for a general discussion of a new GUI architecture.
(Under construction, feel free to add random thoughts)

Overview

It should be remembered that GeoTools2 exists to allow the creation of applications. It is not intended to actually be one. Because of this, any 'architecture' should not place too many restrictions on how a developer might want to use it. A developer should be able to embed the GUI components we create inside almost any platform structure.

The main issue to be considered is - how to interact with a renderer? i.e. how to navigate, how to style, how to query and how to edit a map shown in a display.

Requirements

The overall architecture should (probably) be platform neutral so as to allow SWT and Swing implementations
It needs to be easy to extend with new tools / variants of tools
It needs an event / notification system to automatically update the renderer should any of the following change:

  • data
  • filters
  • styling
  • selection / highlighting

It should allow for coordination between multiple views.

It should follow the MVC pattern - the entire state (visible extent, styling, selections...) should be external to any viewer component

It should support undo/redo as soon as possible (implies command/action pattern of some form)

Where possible selections / actions should be expressed using Filters - i.e. a select tool that drags out a box should actually generate an intersects or contains filter rather than working out the selected features for itself.

Discussion

The convention when thinking about MVC is that there is one model for the view. However, I think we need to think about having multiple models...

e.g. The style, area of interest, data and current selections should be separate models

Use Cases

Other architectures

There are many other projects out there that face the same issues. The following links point to design documents and javadocs for other projects' GUI designs from which we might beg/borrow/adapt solutions.

  • No labels

3 Comments

  1. To Matthias: the header of the page states clearly that here we are speaking about how to
    design a map pane component that allows map viewing, zooming, panning, selection, editing
    and so in with a general framework that allows library users to add their own way to interact
    with the map. Using Netbeans as a base for building a complete GIS application if out of scope.
    You may want to have a look at mapkenzie tought.
    And yes, dialogs to manage and build coordinate systems would be appreciated if general
    enough I guess (smile)

    Anyway, I did not remove your contribution, just moved it to this comments so it is visible
    but does not gets in the way of the main page topic.

    ---------------------------

    Netbeans Platform, Netbeans-like GUI or?
    by Matthias Basler, c9bama@uni-jena.de

    I currently develop a GIS application (not yet published) that utilizes GeoTools. Currently it uses only the cts-coordtrans module, since I am not very far gone yet. My program uses a Netbeans-like UI with a tree view that shows the hierarchical structure of the project, a properties window that allow to edit an object's properties (e.g. the coordinate system of an object) and a desktop area that is thought to hold the maps, tables and other windows.
    My program contains some GUI elements, that I could imagine to share with this GUI, e.g. a dialog for selecting geographical coordinate reference systems or building them from their components.

    Although I have developed my own GUI architecture, which is much simpler (in both positive and negative sense) than Netbeans Platform, I would think that for a more general project like GeoTools it would be the ideal way to utilize the Netbeans Platform which provides a flexible and comfortable GUI framework. GeoTools would not need to care about the GUI architecture, but could concentrate more on the actual GIS aspects - at least I hope so. (wink)

  2. I moved this comment from the Operations API page (bit more on topic here)

    Posted by Anonymous at Apr 30, 2004 10:09

    The MapContext needs methods like getWidth() and
    getHeight(). So you can set and get the ScreenBounds();
    This has the advantage for the Renderer. You don't need
    work with AffineTransform for a small application.

    I wish me like this:
    ?
    DefaultMapLayer dml=new DefaultMapLayer(fs,style);
    DefaultMapContext context= new DefaultMapContext();
    context.setWidth(100);
    context.setHeight(100):

    context.addLayer(dml);
    Renderer lr = new LiteRenderer(context);
    lr.paint(g);
    ?

    And the creating of a DefaultMapLayer is for me difficult.
    An Contructor like new DefaultMapLayer(fs) is still sufficient.
    You can still use a DefaultStyle for the Layer.
    If you want to change the Style you can make it thereafter.

  3. Anonymous

    HI, It could be very nice if the HUI could be implemented in Eclipse SWT or better in GEF. regards
    Xavier