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 _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
