X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <51ED8A0D.20008@xs4all.nl> Date: Mon, 22 Jul 2013 21:37:49 +0200 From: Bert Timmerman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] Re: [geda-help] Toporouter and vias References: <1374248570 DOT 2458 DOT 30 DOT camel AT AMD64X2 DOT fritz DOT box> <51E97735 DOT 5010005 AT videotron DOT ca> <1374256413 DOT 2458 DOT 40 DOT camel AT AMD64X2 DOT fritz DOT box> <51EBDE4E DOT 20100 AT jump-ing DOT de> <51EBF481 DOT 7010801 AT xs4all DOT nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Reply-To: geda-user AT delorie DOT com Markus Hitter wrote: > > Am 21.07.2013 um 16:47 schrieb Bert Timmerman: > >> Markus Hitter wrote: >>> Am 19.07.2013 19:53, schrieb Stefan Salewski: >>>> Teardrops is DJ's plugin, see >>>> >>>> http://www.delorie.com/pcb/teardrops/ >>> >>> Is there a reason why this is a separate plugin and not part of the >>> official sources? >> >> A couple of months ago I had planned to get all known plug-ins into >> the pcb repository (after review by peers of course ;-) > > This is undoubly an excellent plan! > >> The plug-in mechanism of pcb itself is a strong feature, for it >> allows plug-ins to be coded in other programming languages (I have >> seen a java plug-in amongst others). > > Nothing against the plugin mechanism, but for me it's hard to see how > keeping basic features separate is helpful. In the situation now, 99% > of all users or user-wannabes consider pcb to not support teardrops. > The only options for them are to either get away without teardrops or > to search for a PCB layout package which does. Worst case they fire up > their code editor and start to reinvent the wheel. > > Those few who ask for it get back a link which requires them to > install a compiler, mess around with source code and place custom > files. Instead of having it installed by the package manager already. > And not to mention the ugly face of bitrotting. > > > That said, I just tried to include that, too, but it wasn't obvious > for me where to place them. Did you find that out already? > > > Cheers, > Markus > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. (FH) Markus Hitter > http://www.jump-ing.de/ > > > > > > Hi Markus, I was planning to put the plug-ins into a separate directory "src/plugins". The top-level Makefile in "src/plugins" would have to pick up any single source file plugins in there and compile those straight away, including header files as invoked with the "#include" directive. For multi source file plug-ins it would be better to give those a separate directory. Again the top-level Makefile in "src/plugins" should be able to figure out which sub directories exist and let make do it's jobs in there. This would allow the "power users" to just dump the sources for yet another plug-in in there and not need to hassle with the top-level Makefile in "src/plugins". I don't know when I have some free cycles to pick up this issue. Kind regards, Bert Timmerman.