Hi Olivier,
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.
Best,
Angelos
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 ...)
and
- 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
useless.
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
C++.
Well that was it !
Regards,
Olivier
PS:
@Saber Razmjooei:
I didn't find auto-trace (guess it's not approved yet?)
@Leyan
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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
