[udig-devel] Adding modes to edit tools

[Gabriel Roldán <groldan@xxxxxxxx>]

Hi all,

I've being talking with Jesse about a problem I need to face and would love
any more feedback. Bellow is the chat log,
but lets first resume the problem.

As part of our current editting tools and spatial operations project, I need a
way to create line segments parallel to a
segment from another feature, whether it is a line or polygon feature, from
the same layer or not.
One option is to create a new tool, but it has many disadvantages:
 - having a different tool for each extra behaviour adds too much clutter
 - it does not allow to create a parallel segment when needed and keep adding
vertexes freely for the same geometry

A possible approach would be for edit toold to have "modes" of operation, 
where they set up the default behaviours, but plugins may contribute/replace 
them.
Think of it as an extra toolbar enabled when the create line/polygon tool is 
selected, allowing to temporally select a mode for a tool, like ortho lines, 
snap mode, parallel, arc, etc. They get enabled and disabled on user's 
demand.

Chat log with Jesse and Jody:

[21:40] <groldan> Jesse_Eichar77: ping
[21:41] <jgarnet1> he is not here right now
[21:41] <groldan> hey Jody
[21:41] <groldan> ok, np. Do you have a minute?
[21:42] <groldan> for a udig talk?
[21:42] <jgarnet1> I have a long build
[21:42] <jgarnet1> will that work?
[21:42] <groldan> guess so :)
[21:42] <groldan> the thing is I have a mandate to create a "parallel" line
tool
[21:42] <groldan> which, instead of being a new tool
[21:43] <groldan> should be a "mode" for the actual line tool
[21:43] <groldan> by inspecting jira, the following issues are related:
[21:43] <groldan> http://jira.codehaus.org/browse/UDIG-1279
[21:43] <groldan> http://jira.codehaus.org/browse/UDIG-1208
[21:43] <groldan> http://jira.codehaus.org/browse/UDIG-787
[21:44] <groldan> I spent most of this week trying to figure out how to deal
with it without bothering on the udig code base itself (aka, just a plugin)
[21:44] <groldan> but I can't realize it
[21:44] <groldan> it seems to me, taking care of those three issues would just
make the room for this kind extra functionality for existing tools
[21:45] <groldan> as it doesn't make sense neither to create a
specialized "line tool" for every extra "behaviour" needed
[21:45] <groldan> like setting an ortho mode, a parallel mode, a snap to line
mode, etc
[21:45] <groldan> ah, and an "arc" mode
[21:45] <groldan> so far so good
[21:46] <groldan> now I'm fighting my very limited knowledge of the udig
internals
[21:46] <groldan> so I was going to ask for some direction and agreement on
the approach
[21:46] <groldan> :)
[21:47] <jgarnet1> just looking now
[21:49] <groldan> so these editing tools "sub modes" would work like modifiers
for the create line, point and polygon tools. Say there's an extra toolbar
with the allowable modifiers enabled when one of them is selected
[21:53] <groldan> by now, I don't know how to: 1. create a new toolbar and
enable their actions depending on the selected edit tool. 2- create an
extension point so plugins can add behaviours at un time. 3- make
those "behaviours" collaborate with the AddVertexCommand, as right not that's
who call the snapping function, but we need a way to temporally disable
adding a vertex while editing and "parallel" mode is selected, so we can
select a segment we want the one being
[21:53] <groldan> edited to be parallel to
[21:53] <jgarnet1> sorry martin got me for a moment....
[21:53] <groldan> np
[21:53] <groldan> I'm going to send all of this to the ml
[21:54] <groldan> just thought I could steal a bit of jesse's or your time
before that, and even send that email with a bit more of sense :)
[21:58] <-- Jesse_Eichar77 ha dejado este servidor.
[22:01] <-- jgarnet1 ha dejado este canal.
[22:03] --> Jesse_Eichar77 se ha unido a este canal
(n=Jesse_Ei@xxxxxxxxxxxxxxxxxxxx).
[22:03] <Jesse_Eichar77> hey gabriel
[22:04] <Jesse_Eichar77> just got back from lunch
[22:04] <groldan> hey Jesse, np
[22:04] <groldan> did you read what I was telling Jody?
[22:05] <Jesse_Eichar77> So sounds like you want to add another snapping mode
[22:05] <Jesse_Eichar77> (for sake of a better name)
[22:05] <groldan> hmmm.. I guess its more than that
[22:05] <Jesse_Eichar77> right.
[22:06] <groldan> I guess something like the framework thing described in that
jira issue would apply
[22:06] <Jesse_Eichar77> you need modes and a way to configure them/the tool
[22:06] <Jesse_Eichar77> what else
[22:06] <groldan> http://jira.codehaus.org/browse/UDIG-1208 I mean
[22:06] <groldan> in general, that's it
[22:06] <groldan> implementation wise, there are a couple things that scares
me
[22:07] <groldan> first, my intuition is that those modes could be added at
runtime by an extension point what LineTool,PolygonTool, etc need to process
[22:08] <groldan> and they should work like those being mutually exclusive
[22:08] <Jesse_Eichar77> agreed
[22:08] <Jesse_Eichar77> also agree
[22:08] <groldan> joy! seems this week of digging was not so a waste of
time :)
[22:09] <groldan> then, the thing that scares me is that AddVertexCommand
would need a revamp
[22:09] <groldan> as it is being raised by a behaivour, but the command is
calling the snapping to vertex code
[22:09] <groldan> am I right?
[22:09] <Jesse_Eichar77> that could be... feedback has to be considered too.
[22:10] <Jesse_Eichar77> yes you are correct
[22:10] <Jesse_Eichar77> AddVertexCommand is what does the work..
[22:10] <Jesse_Eichar77> The behaviour just configures it.
[22:10] <groldan> so things are going to get a bit more complicated, in the
sense that behaviours settled up at runtime will be "collaborating"
[22:10] <groldan> and sometimes a click won't mean adding a vertex
[22:11] <groldan> but, for example, selecting a line segment from a feature in
another layer....
[22:11] <groldan> (that's when one selects the "parallel" mode and needs to
select which segment to make the parallel to)
[22:11] <Jesse_Eichar77> so there are two different issues we'lre talking
about....
[22:12] <Jesse_Eichar77> 1. Behaviour of the AddVertex Command...
[22:12] <Jesse_Eichar77> 2. Modal behaviour of a tool
[22:12] <Jesse_Eichar77> right ?
[22:12] <groldan> sure
[22:13] <Jesse_Eichar77> so the first isn't too bad provided we have a
strategy object that decides where the final vertex is placed.
[22:13] <Jesse_Eichar77> (four problems how to express these in a UI and in a
extension point)
[22:14] <groldan> the strategy object being the Provider?
[22:14] <Jesse_Eichar77> let me look at the code its been months
[22:14] <groldan> sure
[22:14] <Jesse_Eichar77> no essentially as a replacement for the
performSnapCalculation
[22:14] <Jesse_Eichar77> it could be a provider though
[22:15] <Jesse_Eichar77> now that you mention it...
[22:15] <groldan> yup
[22:15] <groldan> that makes sense tome
[22:15] <Jesse_Eichar77> so modality of the tool.
[22:16] <Jesse_Eichar77> right now they are organized in lists, ordered lists,
exclusive lists, advanced lists.
[22:16] <Jesse_Eichar77> (I'm talking about the EventBehaviours_
[22:16] <Jesse_Eichar77> )
[22:16] <groldan> what do you think of the approach of the extension point for
adding mutually exclusive event behaviours?
[22:16] <groldan> yup
[22:17] <groldan> or may be there would be needed to extend more, I don't know
[22:17] <groldan> making a new kind of behaviour?
[22:18] <Jesse_Eichar77> We could follow the eclipse Command extension point
pattern.
[22:18] <Jesse_Eichar77> you define a command
[22:18] <Jesse_Eichar77> then you can define a binding to the command
[22:18] <Jesse_Eichar77> then you can organize the bindings into
configurations.
[22:18] <Jesse_Eichar77> we might not need the binding step but the pattern is
applicable.
[22:18] <Jesse_Eichar77> (these are keyboard commands)
[22:19] <groldan> that means snap to vertex should be one of them. I.e. the
preference as it is right now just to tell where to look for, but being able
to enable and disable snapping while creating a line through one of this
modifiers
[22:19] <Jesse_Eichar77> The difficulty is knowing where to inject the
behaviour.
[22:19] <groldan> ah... saw some applied, but I'm not familiar at all with it
(not the pattern, but eclipse)
[22:19] <Jesse_Eichar77> hmmm. YOu know how they do toolbars and menus.
[22:20] <Jesse_Eichar77> they add group markers to the places where things can
be added.
[22:20] <Jesse_Eichar77> (I'm just brainstorming at this points)
[22:20] <groldan> cool, but reached the limit of my knowledge of the rcp
platform. So, that's homework for me :)
[22:21] <Jesse_Eichar77> :)
[22:21] <Jesse_Eichar77> Essentially when you create a toolbar
[22:21] <Jesse_Eichar77> you can layout the buttons
[22:21] <Jesse_Eichar77> but you can also add places where things can be
added.
[22:21] <Jesse_Eichar77> You can also set certain actions as being
(retargetable)
[22:22] <groldan> cool, I'm following you
[22:22] <Jesse_Eichar77> so in certain contexts the action's behaviour can be
replaced by another action's behaviour
[22:23] <Jesse_Eichar77> That's not a bad pattern to follow. Worth looking
into at any rate.
[22:23] <groldan> hmm... ingesting the idea...
[22:24] <Jesse_Eichar77> usually a retargetable action is set using the method
ActionSets.setGlobalAction( id, newAction);
[22:24] <Jesse_Eichar77> (don't know how that applies to our situation)
[22:24] <groldan> so, if I'm understanding correctly...
[22:25] <groldan> we could replace the action in course by another one, but it
needs to be temporally
[22:26] <Jesse_Eichar77> could be.
[22:27] <Jesse_Eichar77> Another thing we could do is just have branches of
MutualExclusiveBehaviours
[22:27] <Jesse_Eichar77> that are only valid under certain configurations
[22:27] <Jesse_Eichar77> that would make it easier to make large wholesale
behaviour changes
[22:27] <groldan> that's what I thought of, but just because that's the only
way I know of
[22:27] <Jesse_Eichar77> There are benefits to both.
[22:28] <Jesse_Eichar77> the mutualexclusive idea is good because the
structure is static
[22:28] <Jesse_Eichar77> but it makes for very complex behaviour trees
[22:28] <groldan> indeed
[22:30] <groldan> the other way a new simpler action takes the mandate on
demand... ?
[22:31] <groldan> ("action" might not apply in this context?)
[22:32] <Jesse_Eichar77> that is correct.
[22:32] <Jesse_Eichar77> an outside context can control what the current mode
is and replace the behavior based on what it decides
[22:33] <groldan> yes...makes sense. But how do we decide which one is better?
[22:34] <Jesse_Eichar77> :) good question.
[22:34] <Jesse_Eichar77> thinking...
[22:34] <groldan> (I would say the simpler the better)
[22:34] <groldan> (but have no ide how to code the simpler in this case :) )
[22:34] <Jesse_Eichar77> Agreed on both accounts.
[22:35] <groldan> guess I'll need a bit of prototyping
[22:36] <Jesse_Eichar77> Yeah I think some research is required here...
[22:36] <Jesse_Eichar77> the last issue is how to manifest the choice in the
UI...
[22:37] <groldan> thought of the extra toolbar plus hotkeys to enable disable
the "modes"
[22:37] <groldan> is that what you mean?
[22:37] <Jesse_Eichar77> Yeah.
[22:38] <groldan> so that way makes sense to you?
[22:38] <Jesse_Eichar77> I'm going to think about it for a while.
[22:38] <groldan> cool
[22:39] <groldan> finally
[22:39] <groldan> if we get to a sensible solution... would it be acceptable
to incorporate it on the 1.1.x branch?
[22:39] <Jesse_Eichar77> At a glance it does.... but I'm not sure how it goes
with my long term vision of the toolbars.
[22:39] <Jesse_Eichar77> I don't like it much right now
[22:39] <groldan> agreed, well, I'm open to any suggestion
[22:40] <Jesse_Eichar77> feel free to put it on the 1.1.x branch.
[22:40] <Jesse_Eichar77> I'll merge it onto trunk when its there...
[22:40] <groldan> fantastic
[22:40] <Jesse_Eichar77> but remember that people depend on 1.1.x branch
[22:40] <groldan> that's why I ask, we depend on it :)
[22:40] <Jesse_Eichar77> haha
[22:40] <Jesse_Eichar77> ok cool
[22:41] <groldan> hey, thanks a ton for your time and thinking, should I post
the log with my message to the ml?
[22:41] <Jesse_Eichar77> please that would be great