Re: gEDA-user: PCB LF patch: single "foward annotate" sch->pcb button

[DJ Delorie <dj@xxxxxxxxxxx>]

> Minor nit - "pcblf" is not a great name for the backend. Outside our
> circle, "lf" is probably not something many will understand, and might
> end up being one of those FAQ's like "Ben mode".

Yup.  Suggestions?  pcbfa?  pcbfwd?  pcbimport?  pcbmigrate?  sch2pcb?

> Netlist(Add,name,pin,defer)
>         Adds the given pin to the given name.  If defer, don't tell
>         the GUI about it - must then call NetlistChanged() manually.
> 
> Rather than defer, I'd have probably gone with the pattern:
> 
> Netlist(freeze)
> Netlist(..updates in here..)
> Netlist(..updates in here..)
> ...
> Netlist(thaw)
> 
> It saves a lot of "implementation detail" being repeated each line with
> the "defer" argument)

Good idea.  Should freeze/thaw nest, or be a simple flag?

> ElementAddIf() could be named a little clearer.

Suggestions?  What it does is add the element if it doesn't exist,
else update the element with the new values.  The problem is, the
netlister doesn't know what elements are already on the pcb.

> "Attributes"
> "ElementAddStart"
> "ElementAddIf"
> "ElementAddDone" <-- Name relating to "Add" doesn't really reflect its function

ElementListStart
ElementNeed
ElementListDone  ?

> I don't like the suggested behaviour of selecting errant elements
> from the board. I think that should be a separate action, one which
> can be called at any time (e.g. from a menu).

That's the only time when we know what the errant elements *are*.  I
agree it would be nice to have more state, but we don't, and the whole
point of this task is to simplify the sch->pcb flow so I wanted to get
as much activity into that one menu button as possible.  The flow is now:

* working on the layout
* gschem: update schematics
* gschem: save all schematics
* pcb: File->Import
* maybe hit "delete"
* keep working on the layout

> This does require the concept of an "elements list" to persist within
> the PCB design. That provides other possible workflows too - such as
> allowing the GUI to provide a "tetris mode" for elements which _aren't_
> yet in the design, rather than plonking them down automatically.

I originally wanted to list those elements in a sidebar or something,
but with only partial funding this is what we get.  It needed PCB to
understand that there might be more than one "board" in play at any
given time, you'd then drag elements from the "unplaced" board to the
"working" board.

> "ElementSetAttr"
> "ExecCommand" <--- these are the ones which give me most concern
> "Import"      <--- these are the ones which give me most concern
> 
> The "ExecCommand", especially - gives PCB ".cmd" files some rather
> dangerous powers. We could perhaps keep execution within the
> "Import" command an implementation detail?

Import doesn't call ExecCommand.  The notes were just for
clarification, not implementation.  What it *does* is run either
gnetlist or make, using exec*() (no shell), nothing else.  The concern
about "executable content in pcb files" was raised a while ago, so I
addressed it.  The *.pcb files have nothing more than a list of
schematics, and a gnetlist/make flag.

But I left it in there because it's handy to have for the user to use
when customizing menus.

> I like that the new actions appear to have non-zero return codes for
> failure status. This means (when dbus.c is fixed!), we can use those
> to get some direct feedback for programs such as xgsch2pcb which
> might want to respond to these things interactively.

Er, all actions should have nonzero failure codes...  pcb's scripting
engine already uses those to abort a script if an action fails.


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