On Friday 14 September 2007 13:18:16 Adrian Custer wrote:
Hey Gabriel,
Could you update us with a brief blurb about how you decided to tackle
this?
sure! my attempt at the bottom of the message.
Jody suggested inkscape as one source of inspiration and I would
highly encourage this. Inkscape has one of the most intuitive interfaces
and has been the free software program that has gotten the most traction
with friends to whom I have suggested it. If you don't know it, one of
the things it does is have 2 modes of interaction with each object- a
whole object mode and a 'vertex' mode. That duality seems really
important for the editing tools going forward.
cool. I've installed and tried it.
Up till now, it doesn't seem to be that far from what it is (or could be)
possible with udig. The 2 modes of interactions with objects seem cool as
they're bassically a way to modify the whole object or its parts (curves,
vertices, etc). Right now when you need to modify a geometry in uDig you
have only the vertex part of it, but I guess it shouldn't be that
complicated to add a object mode so you can have handles to operate on the
whole object.
Regardles of that lack and the plenty of extra sub-modes Inkscape (and most
tools like that?) have and uDig doesn't, it doesn't seem impossible to
achieve that and I think we could be a big step closer with the extensions
we're developing.
Moreover, I found Inkscape uses the same approach I was thinking of as to
have a single tool for a single pourpose and when selected, enabling a tool
specific toolbar with the applicable modes. A difference could be most of
them in Inkscape are tailored to the edition of a shape when I'm more
focused in the possible modes while in the creation process of the shape.
(i.e. the process in Inkscape seems to be to create a simlpe shape and then
apply a number of modification to get to the desired one, while I'm trying
to create the desired one with the assistance of the tool's "modes").
Anyhow, I would love to
have an update on your thinking,
Ok, here it is what we got so far.
First, I've identified to main kinds of modes: those that adds behaviours
on top the the current tool default ones, and thos that need finer control
over the tool (i.e. taking full control of interactions while active).
My requirement was to create parallels, but I didn't wanted to create yet
another tool for it, as it would be nicer being drawing a linestring and at
any point decide that the next segment to add has to be parallel to another
one, whether that one belongs to the currently being edited geometry or a
segment from another feature in the same or other layer.
So, we already have something similar: snap behaviours. So I've identified
the following *representative* modes to use while creating a linestring (or
a polygon outline):
- snap to vertex: adds a behaviour to the default tool ones
- snap to line: adds a behaviour to the default tool ones
- ortho: : no extra behaviour, contributes an edit point Provider and
changes feedback (the point Provider restricts the target point to be
orthogonal regarding the last edit shape one, and the feedback shows the
ortho segment and the ortho axes centered at the mouse location)
- parallel: completelly replaces the current tool behaviours and takes
control of interaction and feedback
- arc: same as parallel
Note the benefit of extracting out the snapping as a mode: LineTool looses
responsabilities and gets way more simpler, and it is possible to easyly
enable/disable snapping with a single click or shortcut with no need to go
to the preferences page.
So right now we have a line tool with snap, snap to line, ortho and
parallel modes. Each of them adds or takes control of the interactions as
needed and sets their own feedback graphics.
Example: the parallel mode allows to select the reference line at any
moment using the snap area and the snap behaviour (current layer, all
layers, grid...) settled as prefference.
When the reference line segment is selected, the one being drawn is
restricted to the parallel passing through the last added edit shape point,
and the feedback action is to draw a pair of orthogonal axes centered at
the mouse location where one of them is parallel to the reference segment
and the other orthogonal to it.
This way, we tried to leverage the current interaction mechanisms found in
udig while adding temporal modifiers to an edit tool.
Now, implementation wise, its being done as follows:
To be able to meet deadlines I've implemented a new LineTool, which is
almost equal to the current one but with less responsabilities. It is
intended to be incorporated to uDig core when needed.
We found the blackboard as a great place for inter-plugin collaboration
while keeping the plugins decoupled. The strategy is to store the current
EditToolHandler on the blackboard for the modes to be able of taking
control of it.
As you know, the EditToolHandler holds the activators and behaviours that
compose an edit tool, and the list of activators and behaviours are allowed
to be modified.
whenever a mode is selected, it is free to contribute or replace the
behaviours of the edit tool handler held in the blackboard, as long as it
restores it to its original state once the mode is deactivated. This gives
enough freedom as to implement the representative modes stated above and
still keep things as simple as possible (other possible approaches meant
adding a lot of complexity to the current edit tools framework).
When a mode takes control, it can do three things:
- add or replace behaviours
- add or replace activators (generally used for feedback actions)
- change the currently being used IEditPointProvider
IEditPointProvider is the interface for abstracting out the obtention of
the point to add to a strategy object. This leads to a great simplification
of AddVertexCommand and allows its reuse.
So, AddVertexCommand now receives the point to add and adds it. No need to
perform the snap calculation nor any other.
So, whomever configures the AddVertexCommand just pass it the vertex to
add, and has to obtain it from an IEditPointProvider. For example, the
AddVertexWhileCreatingBehaviour takes the IEditPointProvider to use from
the map's blackboard.
When the parallel mode is selected, it sets an IEditPointProvider that
restricts the location of the point to add to the point where the line
parallel to the reference segment passing through the last edit shape point
crosses the normal to the line where the reference segment is contained and
that passes through the mouse location, and so on.
hmmm.. if I am not making it clear just let me know, I might put some
screenshots on the wiki and provide some more concreteness.
Regards,
Gabriel
--adrian
