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