[udig-devel] Adding modes to edit tools

[Jesse Eichar]

Hi Gabriel,

Basically I like and agree with your plan so I don't have too much to  
say.  It is follows much of our conversation on the IRC.  One thing  
that isn't so clear to me is what the extension point would look like  
for adding modes to a tool.

Jesse


On Sep 14, 2007, at 7:00 AM, Gabriel Roldán wrote:

> 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
>
>