[Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools
Denis Rouzaud
denis.rouzaud at gmail.com
Sun Sep 28 22:36:43 PDT 2014
On 26.09.2014 16:35, Olivier Dalang wrote:
>
> Hello,
>
> Thanks Denis for the initiative ;)
>
> 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.
>
> 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 ;)
>
> 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.
>
>
> While on the topic of map tools, I was thinking of the following
> improvements to the QgsMapTool class:
>
> *1. Implement snapping directly in the QgsMapTool class rather than in
> each subclass*
> 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.
>
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.
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 ?
This sounds like a good idea for me to add these methods maybe at the
QgsMapToolEdit level.
*2. Implement pre-click highlighting of features/nodes/edges/rings/...
(depending on what the current tool accepts)*
>
> 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..
>
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.
>
> 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 ?
>
Yes, this sounds like a nice goal. It might take some time though ;)
>
>
> Best regards,
>
> Olivier
>
>
>
> On Sep 25, 2014 8:49 AM, "Andreas Neumann" <a.neumann at carto.net
> <mailto:a.neumann at carto.net>> wrote:
>
> Hi,
>
> I think we should be open-minded towards Denis ideas and not
> categorically reject any changes in curent behaviour. Enabling the CAD
> mode enables a lot of possibilities compared to the current mode.
>
> I am not a CAD expert either, but I am often impressed about how
> efficiently my Autocad colleagues can edit/construct data.
>
> Therefore I would support the option to switch between Graphics/CAD
> mode. There could even be a button in the editing toolbar switching
> between the two modes, though I would expect that people would like to
> stay in one mode most of the time, once they get used to either mode.
>
> From Denis proposals listed below I would prefer option 3 (Provide
> both
> behaviours and choose which one to use in options). The above
> suggested
> switch mode button or a modifier key could be added as well, though I
> see it as convenience and not absolutely necessary at the start.
>
> Andreas
>
> Am 25.09.2014 05:46, schrieb Denis Rouzaud:
> > Hi all,
> >
> > I'll try to summarize.
> >
> > *QEP*: I don't mind doing one, but I think it's a bit early
> since we are
> > still discussing.
> >
> > *Problematic*: Drag'n'drop map tools prevent from enhancing CAD
> tools in
> > QGIS. For this, it is *required *to add click-click to all map
> tools.
> >
> > *Other softwares:*
> > CAD softwares use click-click actions while design and GIS (Mapinfo,
> > what about ESRI?) use drag'n'drop.
> > New users or even current users might be afraid of such a change.
> >
> > *Pros of methods:*
> > Advantages of click-clik:
> > * allow other actions to be done in the movement
> > * allow cancelling the action (this was not pointed out yet)
> > Advantages of drag'n'drop
> > * More intuitive (for non-CAD users, which I believe is the
> majority)
> >
> > I see *3 (and a half) solutions* (thanks to Matthias for
> pointing some):
> >
> > 1.*Replace current* drag'n'drop to click-click
> > + simplest solution to maintain
> > - need time for new users to get used to this
> >
> > 2.*Enable both* click-clik and drag'n'drop: a short click will
> free the
> > node/feature while a long click (*) will allow drag'n'drop.
> > + both solutions are here
> > - might be confusing for a "standard" user to make a short click and
> > have a node moving without knowing what to do (although escape would
> > cancel the thing)
> >
> > 3. Provide both behaviours and *choose which one to use in options*
> > (e.g. enable CAD behaviour for map tools).
> > + both solutions are here
> > - behaviour not coherent along the different installations
> >
> > half solution: click-click in map tools, allow drag'n'drop in
> the main
> > identify tool. Like *Microstation*.
> > - this works only for move features (i.e. not feasible for
> rotate and
> > node tools)
> >
> > Please comment these solutions, to see if there's a consensus.
> > I'll start and vote for 1. ;)
> >
> >
> > Cheers,
> > Denis
> >
> >
> > * The determination of what should be done is made on the
> distance in
> > pixels from the press position to the release position. If it's
> small it
> > is considered as a short. Time might also get into
> consideration: if you
> > long-click but don't move it could be considered as cancel.
> >
> >
> >
> >
> >
> >
> > On 24.09.2014 10:56, Denis Rouzaud wrote:
> >> Hi all,
> >>
> >> There is somehow an inconsistency in the behaviour of the current
> >> editing map tools.
> >>
> >> Some, like add features, uses the left click to trigger the action.
> >> Others, like the node tool or move feature use
> press-pan-release mouse
> >> events:
> >> * mouse press to select the node/feature
> >> * mouse mouse to move it
> >> * mouse release sets the position.
> >>
> >> I would propose to standardise this and for the latter tools
> propose
> >> the following work flow:
> >> * left click enables the move
> >> * left click again to validate at position
> >> * or right click to cancel
> >>
> >> Why changing this?
> >>
> >> If you look at CAD software, they also use the proposed
> approach. And
> >> there's a reason for doing so, which is valid for QGIS too.
> >>
> >> We are looking at improving the CAD tools in QGIS. In this area, I
> >> recommend trying the fantastic CADinput plugin made by Olivier
> Dalang.
> >> The plugin works on top of any map tool and enables CAD tools
> for each
> >> of them.
> >>
> >> The problem with the press-pan-release map tools is that you can't
> >> truly interact while you are actually in the action of the map tool
> >> (holding the click):
> >> * you can't click anymore and this prevents from using intermediate
> >> points (you have to use the tool several times and repeat the
> >> operation as many times as intermediate points you need)
> >> * it is not really user friendly to have to press keys while holing
> >> the click
> >>
> >> This is why, changing the map tools behaviour is requested if
> we want
> >> to go further with CAD tools in QGIS.
> >>
> >> Regarding the future of CAD tools in QGIS, I am quite sure the
> plugin
> >> proposed by Olivier would be a good way to go for QGIS, but it
> still
> >> might be a bit early to integrate it in core. The idea is
> rather first
> >> to extend the API and propose ready to use methods, so it will
> be easy
> >> to implement your preferred solution in a plugin.
> >>
> >> But first, we need to standardise the map tools.
> >>
> >> So, the bottom line, any objection to changing the behaviour of:
> >> * edit node tool
> >> * move feature
> >> * rotate feature
> >> * move label
> >> * rotate label
> >> * any other press-pan-release map tool that I am not aware of
> >> ???
> >>
> >> Best wishes,
> >>
> >> Denis
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> <mailto:Qgis-developer at lists.osgeo.org>
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140929/80f3c9a3/attachment.html>
More information about the Qgis-developer
mailing list