<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 26.09.2014 16:35, Olivier Dalang
wrote:<br>
</div>
<blockquote
cite="mid:CAExk7p1W8TJPyYp+Nx_nZ7iw3TkGLwTj3yn_sKxDN0Cxe+TPbQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<p>Hello,</p>
<p>Thanks Denis for the initiative ;)</p>
<p>If we are to provide both behaviours, I'm strongly in favour
of a user preference rather than the modifier key. At some
point, we'll want to use modifier keys for other uses (lock
orthogonal move, alternate tool mode, etc.), and this will get
very confusing.</p>
<p>To me, the reasons to implement a click-move-click behaviour
becomes evident when you have to edit a lot of features. It's
much more effort to achieve precision while holding the button
(tension in the hand), you must be a finger acrobat to
pan/zoom while editing, and you can't answer the phone neither
;)<br>
</p>
<p>Still, I'd suggest once the click-move-click feature is
developed, all of us try it for one week or so, and only then
we decide whether we want to provide both modes or not.<br>
</p>
<p><br>
</p>
<p>While on the topic of map tools, I was thinking of the
following improvements to the QgsMapTool class:</p>
<p><b>1. Implement snapping directly in the QgsMapTool class
rather than in each subclass</b><br>
From what I understand of the source, currently, more or less
every subclass of QgsMapTools provides it's own logic for
snapping (or more generally: for conversion from pixel
coordinates click to map coordinates click). In this context,
I don't see how we can achieve cleanly a cross-tool numerical
input system.</p>
</div>
</blockquote>
I wonder if it wouldn't be interesting to work directly on the mouse
pointer position for the snapping. That would allow handling this at
a higher level than the map tools.<br>
<br>
Regarding transformation of coordinates, I suppose you speak of
being able to trigger the event from the code using pixel
coordinates or using map coordinates ?<br>
This sounds like a good idea for me to add these methods maybe at
the QgsMapToolEdit level.<br>
<br>
<br>
<b>2. Implement pre-click highlighting of
features/nodes/edges/rings/... (depending on what the current tool
accepts)</b><br>
<blockquote
cite="mid:CAExk7p1W8TJPyYp+Nx_nZ7iw3TkGLwTj3yn_sKxDN0Cxe+TPbQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<p>This type of visual feedback will make editing much more
intuitive. Take the "move node" tool. It's only by mistake
that user can learn that it also acts on edges. Take the move
tool : when two features overlap, you have no idea on which
feature you'll act. Etc. This could also be done directly in
QgsMapTool, so that we are sure it's consistent across tools..</p>
</div>
</blockquote>
As Leyan pointed out you would get very bad performance. Although,
we are discussing with Martin about having a cache of all currently
rendered features. This would allow much better performance for
snapping, and for the proposed idea of highlighting.<br>
<blockquote
cite="mid:CAExk7p1W8TJPyYp+Nx_nZ7iw3TkGLwTj3yn_sKxDN0Cxe+TPbQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<p>Think at how easy it would then be to develop other map tools
: almost only the tool logic, and no boilerplate code at all.
What do you think ?</p>
</div>
</blockquote>
Yes, this sounds like a nice goal. It might take some time though ;)<br>
<blockquote
cite="mid:CAExk7p1W8TJPyYp+Nx_nZ7iw3TkGLwTj3yn_sKxDN0Cxe+TPbQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<p><br>
</p>
<p>Best regards,</p>
<p>Olivier</p>
<p><br>
</p>
<p><br>
</p>
<div class="gmail_quote">On Sep 25, 2014 8:49 AM, "Andreas
Neumann" <<a moz-do-not-send="true"
href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
I think we should be open-minded towards Denis ideas and not<br>
categorically reject any changes in curent behaviour.
Enabling the CAD<br>
mode enables a lot of possibilities compared to the current
mode.<br>
<br>
I am not a CAD expert either, but I am often impressed about
how<br>
efficiently my Autocad colleagues can edit/construct data.<br>
<br>
Therefore I would support the option to switch between
Graphics/CAD<br>
mode. There could even be a button in the editing toolbar
switching<br>
between the two modes, though I would expect that people
would like to<br>
stay in one mode most of the time, once they get used to
either mode.<br>
<br>
From Denis proposals listed below I would prefer option 3
(Provide both<br>
behaviours and choose which one to use in options). The
above suggested<br>
switch mode button or a modifier key could be added as well,
though I<br>
see it as convenience and not absolutely necessary at the
start.<br>
<br>
Andreas<br>
<br>
Am 25.09.2014 05:46, schrieb Denis Rouzaud:<br>
> Hi all,<br>
><br>
> I'll try to summarize.<br>
><br>
> *QEP*: I don't mind doing one, but I think it's a bit
early since we are<br>
> still discussing.<br>
><br>
> *Problematic*: Drag'n'drop map tools prevent from
enhancing CAD tools in<br>
> QGIS. For this, it is *required *to add click-click to
all map tools.<br>
><br>
> *Other softwares:*<br>
> CAD softwares use click-click actions while design and
GIS (Mapinfo,<br>
> what about ESRI?) use drag'n'drop.<br>
> New users or even current users might be afraid of such
a change.<br>
><br>
> *Pros of methods:*<br>
> Advantages of click-clik:<br>
> * allow other actions to be done in the movement<br>
> * allow cancelling the action (this was not pointed out
yet)<br>
> Advantages of drag'n'drop<br>
> * More intuitive (for non-CAD users, which I believe is
the majority)<br>
><br>
> I see *3 (and a half) solutions* (thanks to Matthias
for pointing some):<br>
><br>
> 1.*Replace current* drag'n'drop to click-click<br>
> + simplest solution to maintain<br>
> - need time for new users to get used to this<br>
><br>
> 2.*Enable both* click-clik and drag'n'drop: a short
click will free the<br>
> node/feature while a long click (*) will allow
drag'n'drop.<br>
> + both solutions are here<br>
> - might be confusing for a "standard" user to make a
short click and<br>
> have a node moving without knowing what to do (although
escape would<br>
> cancel the thing)<br>
><br>
> 3. Provide both behaviours and *choose which one to use
in options*<br>
> (e.g. enable CAD behaviour for map tools).<br>
> + both solutions are here<br>
> - behaviour not coherent along the different
installations<br>
><br>
> half solution: click-click in map tools, allow
drag'n'drop in the main<br>
> identify tool. Like *Microstation*.<br>
> - this works only for move features (i.e. not feasible
for rotate and<br>
> node tools)<br>
><br>
> Please comment these solutions, to see if there's a
consensus.<br>
> I'll start and vote for 1. ;)<br>
><br>
><br>
> Cheers,<br>
> Denis<br>
><br>
><br>
> * The determination of what should be done is made on
the distance in<br>
> pixels from the press position to the release position.
If it's small it<br>
> is considered as a short. Time might also get into
consideration: if you<br>
> long-click but don't move it could be considered as
cancel.<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On 24.09.2014 10:56, Denis Rouzaud wrote:<br>
>> Hi all,<br>
>><br>
>> There is somehow an inconsistency in the behaviour
of the current<br>
>> editing map tools.<br>
>><br>
>> Some, like add features, uses the left click to
trigger the action.<br>
>> Others, like the node tool or move feature use
press-pan-release mouse<br>
>> events:<br>
>> * mouse press to select the node/feature<br>
>> * mouse mouse to move it<br>
>> * mouse release sets the position.<br>
>><br>
>> I would propose to standardise this and for the
latter tools propose<br>
>> the following work flow:<br>
>> * left click enables the move<br>
>> * left click again to validate at position<br>
>> * or right click to cancel<br>
>><br>
>> Why changing this?<br>
>><br>
>> If you look at CAD software, they also use the
proposed approach. And<br>
>> there's a reason for doing so, which is valid for
QGIS too.<br>
>><br>
>> We are looking at improving the CAD tools in QGIS.
In this area, I<br>
>> recommend trying the fantastic CADinput plugin made
by Olivier Dalang.<br>
>> The plugin works on top of any map tool and enables
CAD tools for each<br>
>> of them.<br>
>><br>
>> The problem with the press-pan-release map tools is
that you can't<br>
>> truly interact while you are actually in the action
of the map tool<br>
>> (holding the click):<br>
>> * you can't click anymore and this prevents from
using intermediate<br>
>> points (you have to use the tool several times and
repeat the<br>
>> operation as many times as intermediate points you
need)<br>
>> * it is not really user friendly to have to press
keys while holing<br>
>> the click<br>
>><br>
>> This is why, changing the map tools behaviour is
requested if we want<br>
>> to go further with CAD tools in QGIS.<br>
>><br>
>> Regarding the future of CAD tools in QGIS, I am
quite sure the plugin<br>
>> proposed by Olivier would be a good way to go for
QGIS, but it still<br>
>> might be a bit early to integrate it in core. The
idea is rather first<br>
>> to extend the API and propose ready to use methods,
so it will be easy<br>
>> to implement your preferred solution in a plugin.<br>
>><br>
>> But first, we need to standardise the map tools.<br>
>><br>
>> So, the bottom line, any objection to changing the
behaviour of:<br>
>> * edit node tool<br>
>> * move feature<br>
>> * rotate feature<br>
>> * move label<br>
>> * rotate label<br>
>> * any other press-pan-release map tool that I am
not aware of<br>
>> ???<br>
>><br>
>> Best wishes,<br>
>><br>
>> Denis<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Qgis-developer@lists.osgeo.org"
target="_blank">Qgis-developer@lists.osgeo.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a moz-do-not-send="true"
href="mailto:Qgis-developer@lists.osgeo.org"
target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Qgis-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</body>
</html>