Good day (or night)!
I got an impression that during long time no matter what kind of forces are
made we are swimming in the same swamp: UDIG core functionality is buggy,
unpredictable, unstable.
Here are just my minds about what breaks the "user-friendly" motto. I try to
think from the point of view not the developer but the user.
1) Rendering.
A lot of time was spent to learn, debug and understand rendering
multi-threaded architecture. Significant improvements were changed by bugs
and back for the time being.
Does the user really need progress of each layer rendering? Especially when
dozen of layers is on the map and rendering itself is time consuming task.
Updating status message, etc takes UI thread time.. There is a one composite
rendering thread that can be a "user" job and report whether rendering is
going on.
The same situation with layer status decorations. I would like to have an
option to switch off rendering progress decoration. stupid endless blinking
effects in Layers view. Lets make a rendering itself stable with good
architecture, then decoration. Question of priorities and concentrating on
really important and critical things.
Composite rendering thread that merges buffered images from usual layers
rendering threads - when the layer is rendered - updating is performed, no
updating during progress (again - the question of priorities - what is more
important: performance and clear logical behavior like "rendered->updated"
or UI tricks like "let's the user see our cool rendering progress at
run-time").
Some job is needed to refactor RendererCreator. Clean up the handling of
events when project model is changed: I mean I add layer - renderer context
must be created on the fly and the layer has to be rendered; I add multiple
layers - the same behavior but by one time - handling of multiple events by
one time. Such kind of improvements are desired.
2) Commands executing.
The use case: I have 10 layers. I press quickly press Zoom In, Zoom Out,
Zoom In, Zoom Out. 4 commands. Rendering is crazy! Each command forces
refreshing 4 times. I suppose composite renderer must somehow on the fly to
force current running rendering to be restarted if bounding box is changed.
This kind of optimizations are not that trivial, agree.. but I am a stupid
user working with "user-friendly"..
Commands merging, composing, whatever. It is for future thinking..
3) UI
UI standards: If I select project item, map item, layer item and press
"Delete" button. Let's assume that deleting works properly:) If I delete
prohect, popup window asks me about acknowledgement of deleting. If I delete
map, it disappears forever. what if I accidentally pressed "Delete" button
when the map was selected...
The unified behavior is strongly expected by stupid users..
4)"Selection" policy
There are various selection tools like box selection or feature selection.
Again, the user expects the similar behavior of all "selection" tools.
Selection is done in context of layer and map. I am a "stupid" user, I
expect a kind of "substitution" policy. I select features by "Box selection"
tool - the selection is highlighted. I select one feature by "Feature
selection" tool, the previous selection is cleared, or "substituted" by the
new one how I call it. Selection is performed by Filter API in Layer object.
One layer is always selected, or active. Selection tools perform selection
in current layer, while all previous selections in other layers in context
of current Map must be cleared. Only one map, one selected active layer
always, selection being performed by selection tools substituting any other
selections in any layer of the current map.
That what the users expect.. from experience.
As a developer I would like to have a kind of special GeoSelectionService
that is a singleton object in Map instance. All selections are made through
GeoSelectionService and wrapped into IGeoSelection interface. Tools create
selections through GeoSelectionService by passing selected objects wrapped
into IGeoSelection , like ISelection works.
=====================================
IGeoSelection extends IAdaptable{
//selection always in context of layer
Layer getLayer();
//if selection is made by filterm this is not null, but it can be in
//specific selection implementations
Filter getFilter();
//depends on implementation
getAdapeter(Class);
//Just iterates through set of objects like in IStructuredSelection
Iterator iterator();
}.
===========================
Why would I like that improvement? Something that is selected on the map is
a kind of persistent selection during switching over workbench parts.
Eclipse workbench selection service is a general solution and not
appropriate here because depending on part, tool, viewers we have different
selection providers but what I wrap into IGeoSelection is something
persistent and present on the map (Filter-based selection, or other
approaches).
Imagine we have good SelectionEditor of the UDIG of the future :) that can
edit one feature, or set of attribute values from multiple features defined
selected by Filter (we are working with that kind of editor now). It can
listen GeoSelectionService and always get IGeoSelection with necessary
information when selection is changed by any selection tool (that are going
to work through singleton GeoSelectionService to perform selections).
The tool made a new selection, SelectionEditor got changes, MapEditor is
changed -> SelectionService listens MapEditor activation and gets current
selection and sends as an event to update listeners like SelectionEditor.
We solve lots of problems. Substitution policy and unified behavior for
tools. Updating selection graphics and clearing the old ones is easy because
everything goes through one point - GeoSelectionService (now
ContextModel.select(..) is a kind of such point, but not extendable..
standalone service is preferable). Only one IPartListener in
GeoSelectionService to update selection from activated MapEditor in its
listeners - more clear architecture, less chances to create a listeners
hell.
IGeoSelection - something that is created on the map with "selection"
semantics.
5)Feature editor.
We are implementing feature editor based on new TabbedPropertySheetPage and
its framework. IGeoSelection can wrap just one feature and editor can create
UI for attibutes editing like it is now. Also IGeoSelection can wrap just a
filter of the layer and the editor will create UI to set values for
appropriate attribute types and then perform batch updating through
FetaureStore.modifyFeatures(AttributeType[], Object[], Filter).
We have selection tools that provide IGeoSelection to GeoSelectionService.
We have editor that listens GeoSelectionService and creates necessary UI for
the particular contents of IGeoSelection.
6) Editing tools
We know the situation. bunch of work is needed. There should be capability
to switch off all animations. Seems a lot of work was devoted to create and
fix animation when the core functionality of editing tools is so raw. The
question of priorities for users: what is more important - animation or how
to create a line with good UI response time.
7)Catalog
Catalog is not friendly at lot. It is simple and brutal. But is a core thing
like ArcCatalog.. all resources are coming into application through catalog
- a kind of central geographical resources repository. Resources must be
lazily activated. Is IService interface good enough to be a kind of
lightweight descriptor for the data source? Seems, yes, but if to switch on
all logs, when UDIG is opening, a lot of warnings appear like
WARNING: projection (.prj) for shapefile:
file:/D:/eclipse/kuviogis-workspace/db2shp/2006_09_13/18_03_58/MHGIS_GISA1_K
UVIO.shp is not available
for shapefiles contained in Catalog. Seems something tries to load data
source to create label, whatever, not lazy now.. (debugging has shown that
CatalogPlugin.title() methods causes loading resources in Catalog during
opening the application when there is no opened editors..
8) Copy/paste
If this is not ready and buggy, I would like to hide that functionality
until it starts to work properly. I copied layer in Layers view and pasted
to another map. The application starts to be crazy, rendering has broken,
etc.
Refactor all places where copying/pasting is available, test, fix or hide
for the time being.
9) what else... Friends! it is not a complain but an attempt to clear Augean
stables, make a Plan.
That is a critical for the following development. I am glad to discuss
problems and collaborate to repair them, concentrate on really important
thing and the day will come when we will be able to implement custom
functionality in our projects, not endless fighting with basics..
Regards,
Vitali Diatchkov.
Arbonaut Oy,
Finland
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
