Agreed that's the problem with warnings... as you say it's the same with the compiler errors some systems generate. I must admit that once or twice I've given up on some software due to it generating so many warnings that I simply could not be bother to sift through the error file to find the real problem.
The visual indication of a user pin is a good idea, I suppose the obvious choice would be colour and / or shape. Colour is not over used in eeschema so I think I would lean more to than than shape. Andy On Fri, 3 Jul 2009 08:51:34 -0700 Werner Almesberger <wer...@almesberger.net> wrote: > Andy Eskelson wrote: > > Warnings are just that, a warning it's up to the user to heed or ignore. > > What I mean is that it's easy to miss warnings if your system always > generates some. You're much less likely to miss a warning if your > system normally doesn't complain. This applies also to compilation, > Web browsing, etc. > > Likewise, if you disable an entire class of diagostics, you may > easily miss new problems. > > > Exception lists... sorry to say this but that's clumsy, long winded, > > and not obvious to the untrained eye. > > It tells you if it has hidden any exceptions. > > > projects and I can see it's use (I do hope you have suggested that the > > error output of the ERC is usable as an input) . > > The current ERC format would be very hard to use for this, since it > doesn't include the full information. Also, you probably don't want > to just make all problems disappear too often, but instead examine > every one of them carefully. Those warnings are there to help you, > not to add more bureaucracy to your life ;-)) > > > For most uses I think > > that the addition of some "user" pin types would solve many of these > > problems. Assigned on a per-project basis, and you simply tag an existing > > pin with a user type and then specify what it connects to. a user pin > > connection would over-rule the standard ERC > > Yes, pin type overrides could be used to solve this problem as well, > and they could help with some other issues as well - including making > the constraints even tighter. > > If someone implements pin type overrides, I think there should also > be some visual indication that such an override is in effect, or it > will get very hard to review such schematics. > > - Werner > > > ------------------------------------ > > Please read the Kicad FAQ in the group files section before posting your > question. > Please post your bug reports here. They will be picked up by the creator of > Kicad. > Please visit http://www.kicadlib.org for details of how to contribute your > symbols/modules to the kicad library. > For building Kicad from source and other development questions visit the > kicad-devel group at http://groups.yahoo.com/group/kicad-develYahoo! Groups > Links > > >
