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
>>
[hidden email]
>>
http://openlayers.org/mailman/listinfo/dev>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://openlayers.org/mailman/listinfo/dev>
> !DSPAM:4033,46ccb5d4206011096210785!
>
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
