[Qgis-developer] Cad-Input for QGIS prototype
gcpp.kalxas at gmail.com
Wed Jan 29 01:03:15 PST 2014
This is excellent work, thank you.
+1 on uploading it as experimental.
As already stated, I also believe that we would all benefit from a
common framework for digitizing/CAD plugins.
If we could merge them all into one plugin, it would be awesome, plus
this could be merged into core easier.
On 01/29/2014 06:27 AM, Olivier Dalang wrote:
> 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 ?
> *INPUT vs TOOLS*
> 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...
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
Remote Sensing Laboratory
National Technical University of Athens
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer