[Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools

Bob and Deb bobdebm at gmail.com
Fri Sep 26 11:35:09 PDT 2014


Hi All,

I like the idea of a switch between Graphic and CAD mode.  How about
putting a toggle button near the Render checkbox.  Then all users will know
which mode they are in.

-Bob (aka cgs_bob)
On Sep 24, 2014 11:49 PM, "Andreas Neumann" <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
> > 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/20140926/75fb11a0/attachment-0001.html>


More information about the Qgis-developer mailing list