[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