Re: gEDA-user: Multiple pages
On Wednesday 18 August 2010, John Doty wrote: > Then go ahead and explain it in a single breath. And how does > this force you to hack the netlist? I don't want an argument. I want help making it better. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Aug 18, 2010, at 8:44 PM, al davis wrote: > On Wednesday 18 August 2010, John Doty wrote: >> Exactly what is the problem you experience? You left out the quote from your earlier post: >> >> What >> gets me most is that the translation is incomplete. It seems I >> always need to hack the netlist. > So, I repeat: what problems force you to hack the netlist? > > 1. There are many components that do not netlist properly. > Every symbol must netlist correctly, no exceptions. There is > more to simulation than simple spice circuits. > That requires simulator expertise. Many contributors of components have no knowledge of simulation, and are intending the components for other purposes. Your demand would prevent many, perhaps most, contributions. But the correct fix is to fix the symbol, not hack the netlist. > 2. There are others that netlist properly to spice only because > of hacks specific to the symbol. It is not acceptable for the > netlister to have any knowledge of any specific symbol or any > specific parameter, ever. If I had written the SPICE netlisting back ends I would have avoided this. But the writers had other ideas, and I'm grateful for their hard work. This has never been a problem for me. How does this force you to hack the netlist? > > 3. There is no reverse translation. And that somehow forces you to hack the netlist? Reverse translation from a non-graphical to a graphical format is an AI problem, beyond the present state of the art. > > 4. In most cases, the user enters a value string, in whatever > syntax the simulator wants, which means it could be different > for different simulators. Easy and transparent. If it's not right, the easy fix is to the symbol or schematic. One parameterization does not fit all simulation tasks. And you shouldn't need to hack the netlist. > > 5. It seems to be necessary to have a different schematic for > layout and simulation. Yep. The commercial tools I've used suffer from the same problem. Requirements are different in the different domains. But how does this force you to hack the netlist? > > 6. Probes are not supported. "netname=foo" in schem, then "plot foo" or equivalent in the simulator. Trivial. And how does this force you to hack the netlist? > > 7. Nets are collapsed out, even if the simulator doesn't want it > that way. Not sure what you mean. Example? > > 8. I'm tired of hearing about how perfect it is, when I know it > isn't. It isn't perfect, but the alternatives have serious limitations. And how does this force you to hack the netlist? > > 9. We need to support modern simulators, not just 30 year old > antiques like Spice, and we need to support them fully, not just > the compatibility subset. The most important thing you could do here for your simulator is improve your documentation. And how does this force you to hack the netlist? > > 10. geda seems to insist that everyone who wants to play here > must adopt its way of doing things, which is in many ways like a > proprietary system. We don't outreach to formats that the > leaders consider to be standard. Huh? We have people doing hydraulic design with gEDA. I do *symbolic* circuit analysis by feeding data from gschem to Mathematica. gEDA is an insanely flexible toolkit. And how does this force you to hack the netlist? > > 11. That "two stage amplifier" example should be simple enough > to explain in a single breath, but it's .. how long Then go ahead and explain it in a single breath. And how does this force you to hack the netlist? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Wednesday 18 August 2010, John Doty wrote: > Exactly what is the problem you experience? 1. There are many components that do not netlist properly. Every symbol must netlist correctly, no exceptions. There is more to simulation than simple spice circuits. 2. There are others that netlist properly to spice only because of hacks specific to the symbol. It is not acceptable for the netlister to have any knowledge of any specific symbol or any specific parameter, ever. 3. There is no reverse translation. 4. In most cases, the user enters a value string, in whatever syntax the simulator wants, which means it could be different for different simulators. 5. It seems to be necessary to have a different schematic for layout and simulation. 6. Probes are not supported. 7. Nets are collapsed out, even if the simulator doesn't want it that way. 8. I'm tired of hearing about how perfect it is, when I know it isn't. 9. We need to support modern simulators, not just 30 year old antiques like Spice, and we need to support them fully, not just the compatibility subset. 10. geda seems to insist that everyone who wants to play here must adopt its way of doing things, which is in many ways like a proprietary system. We don't outreach to formats that the leaders consider to be standard. 11. That "two stage amplifier" example should be simple enough to explain in a single breath, but it's .. how long I could probably come up with another dozen, but this should be enough. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Aug 18, 2010, at 6:41 PM, al davis wrote: > What > gets me most is that the translation is incomplete. It seems I > always need to hack the netlist. Exactly what is the problem you experience? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Wednesday 18 August 2010, kai-martin knaak wrote: > > You have said many times how much you love LTspice, > > No I did not. I said, that I use it because using gnucap or > ngspice with gschem is such a hassle. When I last looked into > it, it took me much more time to get results with > gschem/gnucap than with ltspice. And this is while schematic > capture with ltspice is a bitch by itself. "Much more time" > in this case translated to days rather than hours. I agree that it is a hassle. I have said it a few times. What gets me most is that the translation is incomplete. It seems I always need to hack the netlist. The Verilog format (which the development branch of Gnucap ordinarily prefers) really doesn't work. It doesn't do attributes at all. Without attributes, you can't (for example) set the value of a resistor. It has other problems too. Since Gnucap has its own translator system, I would like to see a plugin for it to read the gschem format directly. (and also one to read the PCB format). That would have the side effect of being able to import date to gschem. The same plugin could be used with gnucap's standalone translator, to provide file translations that could be used by other programs. > This is the minimum set of features I feel necessary to > actually use and recommend gnucap with gschem: > > 1) a way to define a permanent group of symbols that shall > participate in simulation. check. > > 2) predefined signal and probe symbols me too. > 3) a fairly complete set of models for basic analog > components yes yes > 4) a "simulate!" button to trigger the simulation and > yield output. and how about the ability to augment the schematic by showing the DC voltages at the nets? > The last two requirements are essential. Lack of immediately > available models is a show stopper for newbies. The models > don't have to be elaborated and can be idealized. But they > have to work with gnucap right away without manual tweaking. Before we can consider that, we need to have a flawless translation of the netlist. Those buttons are a waste if I need to manually edit the netlist. > The simulate-button requirement stands for a short round-trip > time. For me, simulation is all about tweaking the circuit > and watch out for the effect. It doesn't have to be an > actual button. Some kind of script or makefile run on the > *.sch file might do, too. It is for me too. I usually save the netlist, then run gnucap interactively, usually doing stuff that spice won't let me do. Then when the circuit is finally tweeked, how do I propagate the changes back to the schematic? (manually?) > > Most gnucap users are not geda users. The most active > > Gnucap users look at it as an alternative to high priced > > simulators like Spectre, Nanosim, BDA and Saber. Not > > (what they consider to be toys) like LTspice. > > Well, I am talking about usability not accuracy, speed, or > whatever the other simulators excel at. This might be a > different metric. I know. That is one of the reasons Qucs seems to be successful. The simulator engine is somewhat of a lightweight, and for big circuits it can be very slow, but people love it because it is easy for a beginner to use. What we should have here is an upgrade path, so when they outgrow Qucs, we provide what they need. > Do you you have some kind of vision on how gschem should > interact with gnucap? Take a look at Qucs. That's one way. The manual way of getting a netlist and running it manually must be available too. It seems you have a vision too. Let's make it happen. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stephan Boettcher wrote: > I do not like the part about removing footprints on copy. Maybe you like it better, if I call it "move existing footprints to the location indicated by the buffer" ;-) ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
Bert Timmerman wrote: > However, for designs with a large number of layers, having a non-modal > "layers management" dialog could be a possibility te keep more screen > space available for the drawing area. No dialog should be modal, anyway :-) > Parts of the contents for this "layers management" dialog already existst > in the "Files/Preference..." pull down menu, in a dialog with two tabs > (and another one for information). Seems we are talking about three different needs here: 1) Layer switching during manual routing 2) Management of the properties of a single layer 3) Management of the layer stack. Number one calls for a permanently visible interface which should be frugal with screen estate. I think, this need is served pretty good by the current GTK-HID layer switcher. Much better than the other two EDA packages I know (eagle and protel). The preference dialog tries to serve number two and number three. I think, it would be better to but all the single layer stuff in a dedicated dialog. A dialog that can be called with a single click on the layer chooser. ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
al davis wrote: > On Tuesday 17 August 2010, kai-martin knaak wrote: >> I tend to do simulation with ltspice. > > You have said many times how much you love LTspice, No I did not. I said, that I use it because using gnucap or ngspice with gschem is such a hassle. When I last looked into it, it took me much more time to get results with gschem/gnucap than with ltspice. And this is while schematic capture with ltspice is a bitch by itself. "Much more time" in this case translated to days rather than hours. This is the minimum set of features I feel necessary to actually use and recommend gnucap with gschem: 1) a way to define a permanent group of symbols that shall participate in simulation. 2) predefined signal and probe symbols 3) a fairly complete set of models for basic analog components 4) a "simulate!" button to trigger the simulation and yield output. The last two requirements are essential. Lack of immediately available models is a show stopper for newbies. The models don't have to be elaborated and can be idealized. But they have to work with gnucap right away without manual tweaking. The simulate-button requirement stands for a short round-trip time. For me, simulation is all about tweaking the circuit and watch out for the effect. It doesn't have to be an actual button. Some kind of script or makefile run on the *.sch file might do, too. > Most gnucap users are not geda users. The most active Gnucap > users look at it as an alternative to high priced simulators > like Spectre, Nanosim, BDA and Saber. Not (what they consider > to be toys) like LTspice. Well, I am talking about usability not accuracy, speed, or whatever the other simulators excel at. This might be a different metric. Do you you have some kind of vision on how gschem should interact with gnucap? ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: disabling gEDA-wide log files
Stefan Salewski wrote: >>(logging "enabled") >>;(logging "disabled") I put a note on that in the wiki. ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Wednesday 18 August 2010, Oliver King-Smith wrote: > I am under the probably incorrect impression that LtSpice is > actually a better than ngspice and gnucap. What do you > think the benefits are gnucap vs Ltspice? Better for what? You got that impression because somebody is promoting it and you believe the ads. The biggest benefit of LTspice is that people like the user interface. Also, it comes with a library of stuff that some users like. The biggest drawback of the geda/gnucap combo is that the interface between gschem and gnucap works very badly, hence my request for help. Another issue with gnucap now is that there is a big difference between the stable branch and the development branch. Some of the most important features are only in the development branch, which is not the one you get with most Linux distros. For the benchmarks I have run, Gnucap outperforms LTspice and NGspice for medium to large circuits, sometimes by a huge amount. I recall one where Gnucap completed a transient analysis in a few minutes, NGspice took about 8 hours, and I gave up waiting for LTspice, which had produced no output after running it overnight. Also, Gnucap produces output along the way, so even with a slow run you get to see something soon, but either Spice doesn't show the user anything until it is all done. This is not a random difference. I fully understand the reasons for it. Another benchmark, run a long time ago, comparing a predecessor of Gnucap to an expensive commercial simulator that specializes in power grid analysis, the predecessor of gnucap outperformed the commercial package for power grid analysis. Gnucap is a lot more flexible that any spice. It has plugins for lots of stuff, including models, measurements, simulation languages. You can add new (lots of stuff) without recompiling or reinstalling. It takes several simulation languages, including spice, spectre and Verilog. Gnucap has more flexibility in how you run it, for example, you can do an AC analysis at an instant in time, such as a snapshot from a transient analysis. Spice only lets you do AC at quiescent. To see an example of where this matters, try doing an AC analysis of a class B amplifier. Gnucap's step control works better. One example of where this shows is in simulating oscillators. Gnucap is accurate enough to make distortion measurements on a sine wave oscillator. Spice isn't. Gnucap is accurate enough to properly simulate a negative resistance oscillator with a switch, and gives a correct waveform and correct oscillation frequency. Either spice gives nonsense on this circuit. Gnucap is not Spice. (in the same sense that Gnu's not Unix, or that C++ is not Fortran) Gnucap development is more focused on moving forward than bug-for-bug compatibility with legacy programs. That's just a little. But really, in free/open-source, or anywhere, you should expect tradeoffs. One will be better in some ways, another better in other ways. The question should not be which is better, but how do we make ours better. That's both better than it is, and better than others. And remember, things get better when you and we work to make them better, and worse when you see a perceived deficiency and run the other way, and worse when we deny the deficiencies and keep the status quo. The Gnucap development team is working on features for advanced users, with the intent of eventually fully supporting Verilog- AMS, through partnerships with some other GPL'd projects. What seems to be missing is the partnership with schematic and layout. It is in this area that help is most desperately needed. Gnucap/gEDA can be made to be better that LTspice (and others too) in every way, if we choose to do so. Let's do it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
Al, I am under the probably incorrect impression that LtSpice is actually a better than ngspice and gnucap. What do you think the benefits are gnucap vs Ltspice? Oliver ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Tuesday 17 August 2010, kai-martin knaak wrote: > I tend to do simulation with ltspice. You have said many times how much you love LTspice, and how much you dislike the gEDA environment for simulation. How about stepping forward to do something about it? I have asked many times over many years for help with gnucap, especially with the gnucap/geda interface. Most gnucap users are not geda users. The most active Gnucap users look at it as an alternative to high priced simulators like Spectre, Nanosim, BDA and Saber. Not (what they consider to be toys) like LTspice. Therefore the development focus has been in areas that appeal to high end users, and not on the "low hanging fruit" that seems to be needed here. You can be a hero by applying your knowledge, bringing what you like about LTspice here, and helping to solve that problem you are well aware of. This is really an open invitation to anyone who wants to help, but Kai has been rather vocal about it, hence the personal invitation. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: New release of gerbmerge (was: tiling/panelizing multiple .pcbs)
hellas! gerbmerge 1.6 had a few limitations, which made it unable to process current pcb's output as described earlier. the original author has not responded yet, but i have solved the problems on my own and added a few little features. i present you - *drumroll* - gerbmerge 1.7a: http://www.gedasymbols.org/user/stefan_tauner/tools/gerbmerge/gerbmerge-1.7a.tar.gz a changelog can be found at: http://www.gedasymbols.org/user/stefan_tauner/tools/gerbmerge/doc/index.html after setting up the config file once for a set of pcbs, one can create panels of different sizes and different counts of the pcbs very fast and even fully automatic. i really like this thing, although the code is... less object oriented, than i am used to. :) -- Kind regards, Stefan Tauner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reflective optical sensors
It's supposed to do everything triggered off the commit, but that doesn't mean it's *instant*. Stuff still has to be migrated to the second server, that takes time. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reflective optical sensors
whenever i checked my uploaded symbols in the last weeks, they were not created/updated instantly. also the _files_ did not show up in realtime after a cvs commit on the webserver in autoindex listings (but directories did(?!)) -- Kind regards, Stefan Tauner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reflective optical sensors
> no worry, they are not generated instantly, but only once a day or > so. They *should* be generated instantly. There's a cache. I already have a bug report for these symbols, though ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: disabling gEDA-wide log files
On Wed, 18 Aug 2010 13:04:24 +0200 Stefan Salewski wrote: > Tried? > > grep -C3 logging /usr/share/gEDA/system-gschemrc the config files are in /etc/gEDA on my system, but thanks! i forgot to look in the most obvious place (again). someone needs to upload those config files where the googlebot indexes them, so that i can lazily find things not documented elsewhere ;) > Sorry, can not help repairing your SHIFT key... yey they are BOTH broken ever since i got them. ;) -- Kind regards, Stefan Tauner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reflective optical sensors
On Wed, 18 Aug 2010 12:54:37 +0200 Stefan Salewski wrote: > Thanks. There is no preview picture available -- maybe your gschem > version is newer than DJ's previev generator? No big problem. > > http://www.gedasymbols.org/user/david_griffith/symbols/ir_reflect-1.sym no worry, they are not generated instantly, but only once a day or so. -- Kind regards, Stefan Tauner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: disabling gEDA-wide log files
On Wed, 2010-08-18 at 11:58 +0200, Stefan Tauner wrote: > hi > > last year the creation of log files was changed to happen in > ~/.gEDA/logs by default. mine has 11MB "du -sh"-size after a few > weeks and i have not looked at it once. since i installed a SSD, im a > bit picky about such things again :) maybe they should not be created > by default (or better be cleaned up/overwritten each time)? > > i read that one can disable them, but could not find out how. please > help. > Tried? grep -C3 logging /usr/share/gEDA/system-gschemrc >; >(logging "enabled") >;(logging "disabled") Sorry, can not help repairing your SHIFT key... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reflective optical sensors
On Wed, 2010-08-18 at 00:41 -0700, David Griffith wrote: > In case anyone is interested in playing with reflective optical sensors, > I've added some symbols and footprints for a couple of the cheapest ones I > could find: Honeywell HLC1395 series and Vishay TCRT1000. As always, the > goodies are at http://www.gedasymbols.org/user/david_griffith/. Please > let me know what you think. > Thanks. There is no preview picture available -- maybe your gschem version is newer than DJ's previev generator? No big problem. http://www.gedasymbols.org/user/david_griffith/symbols/ir_reflect-1.sym ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: disabling gEDA-wide log files
hi last year the creation of log files was changed to happen in ~/.gEDA/logs by default. mine has 11MB "du -sh"-size after a few weeks and i have not looked at it once. since i installed a SSD, im a bit picky about such things again :) maybe they should not be created by default (or better be cleaned up/overwritten each time)? i read that one can disable them, but could not find out how. please help. -- Kind regards, Stefan Tauner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
kai-martin knaak writes: > Larry Doolittle wrote: > >>> All the cutting, sed-ing and pasting of the subcircuits to multiple >>> instances, with replication of later changes on all copies is pretty >>> unflexible. >> >> Agree 100%. > > +1 > > Cloning, referencing, or whatever we may call it, would need > a fair amount of programming. Given that nobody has stepped > up yet to implement it, this may be pie in the sky. For now I ask to just keep this use-case in mind for the future, while new concepts are developed that partition a PCB layout now. > In the meantime, a more powerful copy procedure could reduce > the effort: > Imagine, the copy-buffer action would accept a string parameter > that it adds to the refdes property of every footprint before > actually pasting to the layout. If this string matches the > string gnetlist attaches to subsheet symbols, the copied block > of layout would fit the netlist. On copy, other footprints with > the same refdes should be automatically removed. This solves the part of making the replication, which has been solved in various ways before, more or less conveniently. The maintanance part is not addressed, where existing solutions require the pcb-scripting cpapabilities of a DJ. I do not like the part about removing footprints on copy. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: reflective optical sensors
In case anyone is interested in playing with reflective optical sensors, I've added some symbols and footprints for a couple of the cheapest ones I could find: Honeywell HLC1395 series and Vishay TCRT1000. As always, the goodies are at http://www.gedasymbols.org/user/david_griffith/. Please let me know what you think. -- David Griffith dgri...@cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
Hi, > -Original Message- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of > kai-martin knaak > Sent: Wednesday, August 18, 2010 12:20 AM > To: geda-u...@seul.org > Subject: Re: gEDA-user: pcb keyboard shortcuts (and usability > in general) > > Bert Timmerman wrote: > > > Maybe a single button would do to open a popup dialog to > alter layer > > settings. > > > > Maybe something like this screenshot from AutoCAD: > > > > > http://www.xs4all.nl/~ljh4timm/downloads/Layer_properties_manager.jpg > > There is no much benefit in presenting all the properties of > all layers at the same time, squeezed in the available screen space. > IMHO, it would be better to open a properties dialog for just > one layer at a time. For example triggered by right-click on > the corresponding layer button. > > ---<)kaimartin(>--- > -- > Kai-Martin Knaak > Öffentlicher PGP-Schlüssel: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 > > > It's just to give "food for thought" and insight of how other CAD apps have solved this issue, the pcb-devs are very able to steer their own course. However, for designs with a large number of layers, having a non-modal "layers management" dialog could be a possibility te keep more screen space available for the drawing area. Not everybody has one (or more) wide flat screen(s) with a resolution >> 1680 x 1050 and a bazzillion colours. Parts of the contents for this "layers management" dialog already existst in the "Files/Preference..." pull down menu, in a dialog with two tabs (and another one for information). Just my EUR 0.02 Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
