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
