[udig-devel] Adding modes to edit tools

[Jody Garnett]

Gabriel I love the way this dicussion is heading; if you have not picked 
a topic for the european code sprint yet perhaps this would be a good one?

Jesse and I have had a hard look at the visual feedback as part up 
updating walkthrough 2 and things look a lot better now. I encourage 
people to think about how to visually indicate what is going on to the 
end user. InkScape once again is a great example.

Jody

> Of course I wrote all that to collect critics/comments/suggestions, so please 
> do not hesitate.
>
> Gabriel
>
> On Friday 14 September 2007 16:00:49 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
>>>       
>
>
>