[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: How to deal with single/dual parts?
On Nov 18, 2009, at 9:17 AM, Peter Clifton wrote:
> On Wed, 2009-11-18 at 09:23 +0100, Stephan Boettcher wrote:
>> Peter Clifton <pcjc2@xxxxxxxxx> writes:
>>
>>> On Tue, 2009-11-17 at 17:10 -0500, DJ Delorie wrote:
>>>>
>>>> What you want is a four-slot-slotted gate symbol, and a separate
>>>> power
>>>> symbol. The slots permute across {gate 1, gate2} x {A-B inputs,
>>>> B-A
>>>> inputs}. I.e. you can use the slotting to switch gates *or*
>>>> swap the
>>>> pins. It's worth the effort to get this working smoothly.
>>>
>>> ARGH!! Sounds like a real misuse of the slotting feature to me.
>>> It makes
>>> any potential DRC checks for "did the user use all the slots" near
>>> impossible to implement as well.
>>
>> To me this sounds like a very good use of a flexible sloting
>> mechanism.
>> With some extra attributes to steer the DRC this should be all
>> fine and
>> transparent.
>
> It is a perfect example of why gEDA can never grow more "friendly"
> interfaces to these problems. _Because_ the existing interface can be
> abused - and people think it is a good idea to encourage such
> "flexibility", we end up with designs out there relying on the
> behaviour.
The job of the tool is to do what the user tells it to, not to try to
outsmart the user. Just keep the behavior clean and simple: slot
selects slotdef which overrides pinnummber. How that is used is up to
the user. *I* wouldn't use DJ's approach, but the tool should not
inflict my prejudices on him. His processes are different from mine.
A sure way to dumb gEDA down to the point where it's only good for
hobbyist projects is for the developers to focus on what the
attributes mean. Attributes only acquire concrete meaning in the
context of some specific flow.
>
> The exponential increase of special-cases / "what if the user
> abused the
> feature by doing .....", stops us from wrapping any of these
> features in
> nicer interfaces.
DJ isn't abusing the feature: slot selects slotdef which overrides
pinnumber. Period. The tool should have no more knowledge than that
built in. I could argue that even that is too much. If you want to
use the scripting to customize for a particular flow, that's a good
thing, but the tool should not try to outsmart the user.
> It prevents decent attribute validation / design rule
> checks, and any hope of wrapping a GUI around the problem (should that
> be desired).
Attributes should have as little meaning to the core tools as
possible, with "attribute validation" left to scripts specific to a
particular flow. Design rule checks are also necessarily flow-specific.
>
> If you propose adding extra attributes to steer the DRC system around
> the hack, you might as well propose an expressive attribute based
> scheme
> for pin / gate swapping instead.
As long as it's implemented as an option in the scripting layers of
gschem/gnetlist, or as a separate tool, it's a good thing. Then it
can be modified or overridden to serve the user's flow, whatever that
is.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user