<div dir="ltr">Hi !<div><br></div><div><br></div><div>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 ?</div>

<div><br></div><div><br></div><div><b>INPUT vs TOOLS</b></div><div><br></div><div>I understand one of the main concern is avoiding to have a CAD-plugins proliferation, and I totally agree.</div><div><br></div><div>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.</div>

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

<div><br></div><div>In my opinion, mixing both in a unique plugin is a bad idea :</div><div>- 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).</div>

<div>- 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.</div><div>- it's a conceptual soup </div><div>
<br>
</div><div>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.</div>

<div>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.</div><div>

<br></div><div><br></div><div><b>TOOLS plugin ideas</b></div><div><br></div><div>So I'd say packaging different CAD-tools in an unique and consistent plugin is another (urgent) task. A key point may be classification.</div>

<div>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.</div>

<div>Native tools could be integrated in this classification as well.</div><div><br></div><div>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.</div>

<div>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++.</div>

<div><br></div><div><br></div><div>Well that was it !</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Olivier</div><div><br></div><div><br></div><div>PS:</div><div><br></div><div>@Saber Razmjooei:<br>

</div>I didn't find auto-trace (guess it's not approved yet?)<br><br>@Leyan <br>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...<div>

<span style="font-family:arial,sans-serif;font-size:13px;font-weight:bold;white-space:nowrap"><br></span></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>