Steven M. Ottens wrote: > Hi Pierre, > > I'm currently more involved in user interaction design and not so > much in coding so it could be that I'm cutting corners which are hard > to cut but: > > why do you need to switch between modifyFeature control and > deleteVertex control? > IMO you can stay in modfiyFeature mode and allow the user to delete a > vertex by selecting it and press the delete key or hit the right > mouse button and select 'delete' . > I am aware that this approach forces the user to understand that a > webpage has more controls than mere links: keyboard, scrollwheel and > the right mouse button behave differently than in the classic Web. > I've been a great advisory (?) of backwards compatibility but > sometimes you need to take the extra step and force people to spend > 10s more time to get the new paradigm to save 9s every time they do > the action. > > This rambling has mainly focussed on your approach of feature editing > and doesn't solve you core question of preservation of selection, > sorry about that. I hope you solve your issue but even more I hope > you reconsider your current design (TBH there are valid reasons to > keep your current design, but ease of coding isn't one IMHO :) >
I like the idea of creating small, single function controls. Then additional controls can be created that aggregate these. I think this gives us the most flexibility. We've done a lot of work to get things this way currently. So you've got a drag handler. A box handler has a drag handler. Then, a zoom box control has a box handler. This way, other things can also make use of the drag handler (like the drag pan control) and other things can make use of the box handler (like a box selection control). The same goes for feature editing. We've now got a drag feature control in the trunk. This uses a drag handler and a feature handler. Alone, it doesn't do that much, it lets you drag feature around. We're also putting together a modify feature control. This uses a select feature control and a drag feature control. Together, it lets you select a feature and drag around its verticies. Next, we need delete vertex and add vertex controls. Alone, these would do just what they say. These could be aggregated with a modify feature control (and even a draw feature control if you like) into a single feature editing control that lets you drag around verticies, add new ones, and delete existing ones. Combined with a draw feature control, this would give you one control to draw and edit. Of course, there will be a lot of room for help from interaction designers. Ideally, we'll be able to use a combination of keyboard and mouse input to activate and deactivate specific functionality in these controls. So, perhaps you were suggesting the same - but I wanted to make sure that it was clear that it *doesn't* make sense to develop the full-featured editing control before having the individual pieces in place. Tim > good luck > steven > > On Aug 22, 2007, at 2:44 PM, Pierre GIRAUD wrote: > >> Hello all, >> >> Recently I worked on Tim's code to enhance the editing >> functionnalities. >> >> The result can be seen in the camptocamp/feature sandbox. >> >> I'm now facing an little issue. What is frustrating for the user is >> that each time he switches between the two different editing controls >> (modifyFeature and deleteVertex), the current selection is lost. The >> user need to reselect a feature so that he can modify it. >> >> The problem is that when a control is deactivated, the select control >> it relies on is also deactivate and the selectFeature.unselect() >> method is called. >> >> Does someone has an idea of a workaround to let a control preserve >> selection so that another control can use it ? >> >> Regards >> >> Pierre >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://openlayers.org/mailman/listinfo/dev > > _______________________________________________ > Dev mailing list > [email protected] > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,46ccb5d4206011096210785! > _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
