<div dir="ltr">Personally for me unless we can get the whole thing nice and smooth I really think the old click-drag still should stay as default and the click-click mode + tools is added to ctrl modifier.  I know it adds more complexity but I don't think "move" is the default action we should take on a node unless we are told that is what the user is wanting to do.  I also understand the desire to be more cad like and add more control on the drawing tools but unless done right it's going to give people a bad experience.<div><br></div><div>- Nathan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 7:32 AM, Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14 September 2015 at 07:07, Saber Razmjooei<br>
<span class=""><<a href="mailto:saber.razmjooei@lutraconsulting.co.uk">saber.razmjooei@lutraconsulting.co.uk</a>> wrote:<br>
> The new changes assume:<br>
>  - User always wants to move a vertex<br>
>  - Only one single vertex is selected<br>
><br>
> But in general, the node tool is also heavily used for deleting, adding and moving vertices. With the new behaviour it is a bit confusing for users how the other tasks can be done, when it gets automatically locked on a single node.<br>
<br>
</span>There's a long blocker list relating to regressions in the map tools, eg:<br>
<br>
- deleting a node: the rubber band is not removed<br>
- deleting a node: when finished, the next node should be pre-selected<br>
(this pre-selection should by synchro with the table view selection<br>
model).<br>
- right-click should cancel the edition of the node (but keeps it pre-selected)<br>
- for point layers, there is no visual feedback of the point being<br>
moved (no rubberband)<br>
- editing in table view: changes should be applied to the rubberband<br>
on keypress (not on editing finished), and when editing is finished it<br>
should ends the digitizing (clear rubberband)<br>
( all from <a href="http://hub.qgis.org/issues/13276" rel="noreferrer" target="_blank">http://hub.qgis.org/issues/13276</a>)<br>
- split tool errors: <a href="http://hub.qgis.org/issues/13273" rel="noreferrer" target="_blank">http://hub.qgis.org/issues/13273</a> and<br>
<a href="http://hub.qgis.org/issues/13347" rel="noreferrer" target="_blank">http://hub.qgis.org/issues/13347</a><br>
- inability to add parts to null geometries - refs<br>
<a href="http://hub.qgis.org/issues/12885" rel="noreferrer" target="_blank">http://hub.qgis.org/issues/12885</a><br>
<br>
I tried to do some digitising in master last week and honestly it was<br>
unusable for geometry editing. Lots of regressions and unexpected<br>
behaviour compared to the smooooth editing machine that 2.8 is! I<br>
understand master is a work-in-progress, but can we get some<br>
confirmation of which issues will be addressed prior to 2.14?<br>
Marco/Denis? If there's no funding to address these then I think they<br>
should be prioritised for the 2.14 bug fixing period.<br>
<span class="HOEnZb"><font color="#888888"><br>
Nyall<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div>