Message-ID: <539854530.301103.1369112152774.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_301102_1727397589.1369112152774" ------=_Part_301102_1727397589.1369112152774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page is for a general discussion of a new GUI architecture.=
(Under construction, feel free to add random thoughts)
It should be remembered that GeoTools2 exists to allow the creation of a= pplications. It is not intended to actually be one. Because of this, any = 'architecture' should not place too many restrictions on how a developer mi= ght 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.
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 rendere= r should any of the following change:
It should allow for coordination between multiple views.
It should follow the MVC pattern - the entire state (visible extent, sty= ling, 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 interse= cts or contains filter rather than working out the selected features for it= self.
The convention when thinking about MVC is that there is one model for th= e view. However, I think we need to think about having multiple models...<= /p>
e.g. The style, area of interest, data and current selections should be = separate models
There are many other projects out there that face the same issues. The f= ollowing links point to design documents and javadocs for other projects' G= UI designs from which we might beg/borrow/adapt solutions.