<div dir="ltr"><div>Hi</div>> 2) select by polygon: behaves the same<br><div><br></div><div>For select by polygon, there is an additional option: right-clicking allows you to select features intersecting with existing polygon shapes (so that you do not need to capture the same geometry):</div><div><a href="https://twitter.com/lutraconsulting/status/1040328624002527232">https://twitter.com/lutraconsulting/status/1040328624002527232</a><br></div><div><br></div><div>Regards<br></div><div>Saber</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 11 Apr 2019 at 08:30, Bernhard Ströbl <<a href="mailto:bernhard.stroebl@jena.de" target="_blank">bernhard.stroebl@jena.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
@Marco I can second Cory that the selection tools' behaviour is <br>
different between 2.18 (tested on Win) and 3.* (tested on Win and Ubuntu)<br>
1) select by rectangle: behaves the same (click + drag)<br>
2) select by polygon: behaves the same<br>
3) select by freehand: behaves differently: 2.18 click + drag 3.* click <br>
+ click<br>
4) select by circle: behaves differently: 2.18 click + drag 3.* click + <br>
click<br>
I have no strong feeling for either behaviour (hardly use options 2 to <br>
4) but I would think that the behaviour should be consistent within QGIS <br>
(either all click + drag or all click + click). Click + drag is well <br>
established (e.g. Inkscape, Bentley Microstation) at least for the <br>
rectangular selection, so maybe it would be better to use this approach. <br>
Furthermore this is how the rectangular selection works in the layout, too.<br>
<br>
@Cory concerning the vertex-editing tool there has been a lot of <br>
discussion and there were good reasons to change its behaviour. A lot <br>
has been improved recently: most prominent IMHO: feature can be locked <br>
for exclusive editing with a right click (similar to selecting a feature <br>
for editing in 2.*) but can be edited directly without locking e.g. by <br>
simply picking and moving vertices. May I therefore ask you to try again <br>
with current master (or a nightly build)? And may I further ask you to <br>
forget how it was in QGIS 2 and simply try how it works in 3?<br>
AFAIK there is no "standard" in mouse behaviour for vertex editing. CAD <br>
uses click + click (I can at least say for Microstation), Inkscape uses <br>
click + drag, so if one or the other seems familiar might depend on <br>
one's background.<br>
<br>
just my 2ct<br>
<br>
Bernhard<br>
<br>
Am 10.04.2019 um 17:38 schrieb Marco Bernasocchi:<br>
> Hi<br>
> <br>
> On 09.04.19 02:53, Cory Albrecht wrote:<br>
>><br>
>><br>
>> Cory Albrecht <<a href="mailto:maps@hanfastolfe.com" target="_blank">maps@hanfastolfe.com</a> <mailto:<a href="mailto:maps@hanfastolfe.com" target="_blank">maps@hanfastolfe.com</a>>><br>
>><br>
>> <br>
>> 8:14 PM (37 minutes ago)<br>
>> <br>
>> <br>
>> to Régis<br>
>><br>
>> Hello Régis,<br>
>><br>
>> Sorry for not being clear - I mean when using the selection tool in <br>
>> freehand mode. I am definitely not talking about the identification <br>
>> tool, assuming you're referring to the same thing that I am thinking <br>
>> of? Ctrl+Shift+I, or the icon that is the cursor with a the letter "i" <br>
>> in a sold blue circle. I'm not sure I would call that new as it's been <br>
>> part of QGIS since I started using it in about 2015. Perhaps you're an <br>
>> old salt from the 1.x days? ;-)<br>
>><br>
>> As a principle of UX design, ideally, the user should do the same <br>
>> action - click and drag - for any type of selection, both to maintain <br>
>> internal consistency in the application and with common ways of doing <br>
>> things in the broader computer universe. This lets people learn new <br>
>> software quickly by having a set of transferable actions that can get <br>
>> them up and running and doing rudimentary things quickly. It also <br>
>> helps reduce unintended errors caused by using common actions that get <br>
>> unexpectedly interpreted different than the user is used to. Things <br>
>> like this contribute to how easy or frustrating an application is to <br>
>> use, both for new and long time users.<br>
>><br>
>> 1. For the "Select Feature(s)", click and drag to indicate the <br>
>> diagonally opposite corners of a selection rectangle.<br>
>> 2. For the "Select Features by Freehand", click and drag to create an <br>
>> irregular blob of selection area.<br>
>> 3. For the "Select Features by Radius", click and drag to indicate the <br>
>> centre of a selection circle and it's radius.<br>
>><br>
>> In 2.x the answer to all of those was yes, but in 3.x it's yes, no, no.<br>
> I just tested and the answer are, as Régis mentioned, the same as in <br>
> 2.18 ( tested using 3.4.4). the behavior you describe is only true when <br>
> you activate "select by polygon".<br>
>><br>
>> In vector and raster drawing applications, drawing rectangles, circles <br>
>> and blobs is done by click and drag, as is selecting rectangular, <br>
>> circular or irregular blobby areas. If you release and click elsewhere <br>
>> then drag, you start drawing a new object, or you discard the first <br>
>> selection and start outlining a new one. Word processing and text <br>
>> section, video editors and frame selection, sound editors and lengths <br>
>> of time in a track, they all have the user do these conceptually <br>
>> similar tasks in the same way - click and drag to create a selection , <br>
>> new click discards old selection.<br>
>><br>
>> Another principle of UX design is that you don't change how a user <br>
>> does something unless there is clear benefit that outweighs the <br>
>> trouble of relearning, especially for action concepts that are common <br>
>> in the broader sphere. When you make changes without benefits you <br>
>> cause friction in your user flows (some call those "point points"), <br>
>> and that means people find that task (and potentially the application <br>
>> as a whole) difficult and frustrating to use.<br>
>><br>
>> For those three methods of selection there's nothing to be gained by <br>
>> making QGIS 3.x the odd one out in how this is done. There's no <br>
>> benefit added by extra functionality in these selection methods. All <br>
>> it does is create pain points, both by being different from everybody <br>
>> else and by being inconsistent internally.<br>
> That is exactly why QGIS does it the same why as other tools.<br>
>><br>
>> The exception to this is the poly gone selection tool. I've never <br>
>> encountered it outside of QGIS and ArcGIS. Drawing applications have <br>
>> polygon drawing tools in which you sequentially click the polygon's <br>
>> points, just like how you create features on polygon or line layers in <br>
>> QGIS, but there's no polygon selection analogue. As such it makes <br>
>> sense to take the feature creation method of sequential clicks over <br>
>> for use in a polygon selection tool rather than coming up with a whole <br>
>> new user flow like click and drag and tapping the space bar for the <br>
>> points.<br>
>><br>
>> And so I wonder - what was the rationale behind making this change?<br>
> <br>
> a very quick google search returned the whole rationale to changing the <br>
> behavior of the Node tool [0] but none for the behavior you describe, <br>
> which I could not reproduce. Could you show us a screencast?<br>
> <br>
> [0] <a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/69" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues/69</a><br>
> <br>
> oh, and cheers<br>
> <br>
> Marco<br>
> <br>
>><br>
>> On Mon, Apr 8, 2019 at 6:00 AM Régis Haubourg <br>
>> <<a href="mailto:regis.haubourg@gmail.com" target="_blank">regis.haubourg@gmail.com</a> <mailto:<a href="mailto:regis.haubourg@gmail.com" target="_blank">regis.haubourg@gmail.com</a>>> wrote:<br>
>><br>
>> Hi Cory,<br>
>> I must say I didn't notice any difference on the selection tool<br>
>> behavior on my side.<br>
>> I don't think there was any explicit attempt to homogenize the<br>
>> selection behavior with the node tool new ergonomy.<br>
>><br>
>> Just a check, in the maptool dropdown list for selection tool, are<br>
>> your using the freehand selection tool or the classical clic and<br>
>> drag selection tool?<br>
>><br>
>> I've seen similar surprising issues with the new "identify" tool<br>
>> that now can interrogate features in a polygon. Users got confused<br>
>> when they changed this behavior by mistake. Could that be your case?<br>
>> Cheers<br>
>> Régis<br>
>><br>
>> Le lun. 8 avr. 2019 à 01:09, Cory Albrecht <<a href="mailto:maps@hanfastolfe.com" target="_blank">maps@hanfastolfe.com</a><br>
>> <mailto:<a href="mailto:maps@hanfastolfe.com" target="_blank">maps@hanfastolfe.com</a>>> a écrit :<br>
>><br>
>> I was wondering why the selection tool behaviour in 3.x was<br>
>> changed from the implementation in 2.18?<br>
>><br>
>> In 2.18.x when you wanted to select features in a layer, you<br>
>> clicked the primary mouse button, held it, and moves the mouse<br>
>> cursor over the items you wanted to select - known as "click<br>
>> and drag". To help, a shape was drawn on screen for the user<br>
>> to know what they had already dragged the mouse over top of.<br>
>> To add to the selection you used shift plus click and drag, to<br>
>> remove, Ctrl plus click and drag. It the way select tools work<br>
>> broadly across computer world and is intuitive because of it's<br>
>> ubiquity - learn it once, use it everywhere.<br>
>><br>
>> In 3.x, however, instead of using that common method, it has<br>
>> changed to click and release and move the mouse around. This<br>
>> is a common UI method to set focus to an item for subsequent<br>
>> actions but still be able to move the mouse around without<br>
>> selecting or affecting any other items. I know things would<br>
>> work slightly different in QGIS because of having a distinct<br>
>> selection tool that one must activate, but this removes<br>
>> intuitiveness from the application and makes it more difficult<br>
>> to use without any corresponding gain in functionality.<br>
>><br>
>> A similar change has also happened in the vertex editor where<br>
>> in 2.18.x single clicking on a vertex used to mean select, and<br>
>> you had to drag (click and hold) to move it. Now, if you click<br>
>> and release, it unexpectedly drags the vertex around as you<br>
>> move the mouse.<br>
>><br>
>> QGIS having it's own, non-standard mouse actions for tasks<br>
>> that are common (select, copy, delete, etc…) across all types<br>
>> of data (text in a wordprocessor, frames in a movie editor,<br>
>> features in a map editor, etc…) is counter-intuitive and<br>
>> confusing, especially if those non-standard actions are<br>
>> already commonly used for other common user interface actions.<br>
>><br>
>> It's almost like the QGIS development team has decided that<br>
>> Ctrl+V will now mean "Cut", Ctrl+X will mean "Copy", and to<br>
>> copy have to use Alt+F1 for "Paste". Extending common user<br>
>> interface actions for something in QGIS that has no exact<br>
>> parallel but is still conceptually similar to that common<br>
>> action, like how Ctrl+Alt+V means paste what was copied into<br>
>> the buffer into a brand new layer, that makes sense. But<br>
>> ignoring decades of common UI actions that are in the muscle<br>
>> memory of probably all users makes the programme frustrating<br>
>> and tedious to use as one has to constantly remind themselves<br>
>> that QGIS is different.<br>
>><br>
>> _______________________________________________<br>
>> QGIS-Developer mailing list<br>
>> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> <mailto:<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a>><br>
>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> Unsubscribe:<br>
>> <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> QGIS-Developer mailing list<br>
>> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> List info:<a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> Unsubscribe:<a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> -- <br>
> Marco Bernasocchi<br>
> QGIS.org Co-chair<br>
> <a href="mailto:marco@opengis.ch" target="_blank">marco@opengis.ch</a> <mailto:<a href="mailto:marco@opengis.ch" target="_blank">marco@opengis.ch</a>><br>
> +41 (0)79 467 24 70 <tel:+41794672470><br>
> <br>
> OPENGIS.ch Logo <<a href="https://www.opengis.ch" rel="noreferrer" target="_blank">https://www.opengis.ch</a>><br>
> <br>
> <br>
> __________ Information from ESET Mail Security, version of virus <br>
> signature database 19173 (20190410) __________<br>
> <br>
> The message was checked by ESET Mail Security.<br>
> <a href="http://www.eset.com" rel="noreferrer" target="_blank">http://www.eset.com</a><br>
> <br>
> '�z�Zr �r ^�)�j[p��Z��'~��zJ&�W�� ��{^� �iק<br>
> <br>
<br>
<br>
-- <br>
Bernhard Ströbl<br>
Anwendungsbetreuer GIS<br>
<br>
Kommunale Immobilien Jena<br>
Am Anger 26<br>
07743 Jena<br>
<br>
Tel.: 03641 49- 5190<br>
E-Mail: <a href="mailto:bernhard.stroebl@jena.de" target="_blank">bernhard.stroebl@jena.de</a><br>
Internet: <a href="http://www.kij.de" rel="noreferrer" target="_blank">www.kij.de</a><br>
<br>
<br>
Kommunale Immobilien Jena<br>
Eigenbetrieb der Stadt Jena<br>
Werkleiter: Karl-Hermann Kliewe<br>
<br>
<br>
__________ Information from ESET Mail Security, version of virus signature database 19176 (20190411) __________<br>
<br>
The message was checked by ESET Mail Security.<br>
<a href="http://www.eset.com" rel="noreferrer" target="_blank">http://www.eset.com</a><br>
<br>
<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-1170312422232553486gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Saber Razmjooei<br></div><div><a href="http://www.lutraconsulting.co.uk" target="_blank">www.lutraconsulting.co.uk</a><br><span>+44 (0)7568 129733</span><br></div></div></div></div></div></div></div></div></div></div>