[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: merge multi symbol components



DJ Delorie wrote:
>> I don't really care whether scripting functionality is built in the
>> tool or is not, as long as it seamlessly integrates with it. When the
>> script modifies a design file the tool should update any views of it
>> (I guess that's what you meant by "operate on the live data").
> 
> I agree - I don't care how it's implemented, I care how it *acts*.
> 
> In PCB, for example, you can call out to a separate program to fiddle
> with your design, but to get it "live" you end up reloading the file,
> which resets some of the GUI as if you had loaded a separate design.
> 
>> Another issue is what we consider "scripting". For me, scripting is
>> only good for automating the flow, glueing existing functions
>> together so that the user's productivity increases. This is in
>> opposition to plumbing, adding features to the tool, which should be
>> there in first place, because it decreases productivity.
> 
> Scripting, to me, means having some way of automating repetitive tasks
> within an environment.  For gschem/pcb, this means (to me) being able
> to, for example, iterate over the design and make repetitive changes
> to chosen parts.  "Find all 13 mil holes and make their pads at least
> 40 mil diameter."  "Rename all D?? parts to CR??."  The core
> functionality is there (changing pad sizes, renaming parts) it's the
> user-specific automation that's lacking.
> 
>> On the gschem side I really like the idea of libgeda. IMHO everything
>> that touches user's data should go there and be wrapped with a clean
>> API. Tools like gschem, netlisters, importers etc should only issue
>> commands/listen to libgeda.
> 
> Right, but there still needs to be something that the *user* interacts
> with to automate repetitive tasks.  That "something" can certainly use
> libgeda, but let's not expect people to have to write C programs with
> libgeda that run outside of gschem, and let's not delude ourselves
> into thinking that's "scripting".  That's *programming*.
> 

Not only to you. What you described is pretty much exactly how most 
design engineers see it. They do not want to become programmers. Some of 
them wouldn't mind so much but most would just move on.

One CAD system where scripting has been implemented quite nicely is 
Cadsoft Eagle. If anyone wants to check it out there is a free hobbyist 
version. AFAIK it has the same scripting capabilities as the commercial 
version. But even the full commercial package lacks a hierarchy which is 
what keeps Eagle from making serious inroads in the industry  :-(

-- 
Regards, Joerg

http://www.analogconsultants.com/



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user