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