[Qgis-developer] Cad-Input for QGIS prototype

Olivier Dalang olivier.dalang at gmail.com
Tue Jan 28 20:27:07 PST 2014

Hi !

Thanks for all the replies !! I updated the plugin which should work on
mac/linux now, please give it a try ! Do you think it's too soon to put it
in the plugin repo as experimental at this stage ?


I understand one of the main concern is avoiding to have a CAD-plugins
proliferation, and I totally agree.

It's quite hard to draw the line on what can be packaged in one plugin and
what should rather be kept in another one.

I'd say we can distinguish between what really is about
- INPUT (coordinates, snapping, constraints, mouse, units ...)
- TOOLS (extend, trim, offset, rotate, create shapes ...)

In my opinion, mixing both in a unique plugin is a bad idea :
- at long term, we may want to integrate the INPUT part in QGIS's core, as
keeping TOOLS part as plugins may seem more relevant (easier to extend).
- TOOLS are feature specific. Some of them will operate only on polygons,
some other only on points, whereas INPUT should aim to be generally
available as possible.
- it's a conceptual soup

Of course, INPUT would allow to do some things that could also be
implemented as a specific TOOL. In Autocad, for instance, you can
extend/trim a line either with the extend/trim tool, or by moving a vertex
and taking advantage of the snapping system. That doesn't make one of them
INPUT can also enhance the way you use TOOLs. Take the rectangle-oval
digitizing plugin : thanks to CadInput, you can (well, you could, if it
worked better with drag-type tools) enter precise numeric input.

*TOOLS plugin ideas*

So I'd say packaging different CAD-tools in an unique and consistent plugin
is another (urgent) task. A key point may be classification.
IMO, a good start would be a toolbar by layer type (point, line, polygon)
in which all tools would be ordered/separated by funtion type (create,
reshape, merge/split, modify, delete...). The available toolbar would only
show when editing the corresponding layer type.
Native tools could be integrated in this classification as well.

To get a polished and consistent user experience, I think we need some
solid abstract tool classes, which takes care of how input is organised in
terms of UI (common interface for point/segment/object/numeric input) and
logic (operands then operation, or operation then operands). The QGIS C++
tool class leaves (too) much freedom to subclasses.
A great work towards such a plugin would be to try to implement that base
classe(s) in python. It would then be much easier for contributors to
extend the tool set. And in the end, the base class could be implemented in

Well that was it !




@Saber Razmjooei:
I didn't find auto-trace (guess it's not approved yet?)

Yes it's a good idea. There is already a construction mode which allows to
enter points without creating features. It could be made available even
when not using an editTool...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140129/284c4676/attachment.html>

More information about the Qgis-developer mailing list