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

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Fri, 2010-01-29 at 14:04 -0500, DJ Delorie wrote:

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

Many implementations nest, emitting the notify when the count gets to
zero. I don't imagine it would be too hard to make the implementation
nest though. I can't (at the moment), think of a real use-case for it
though. 

> > 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.

If we had an "ElementList" which was kept internal to PCB, as well as
the "NetList", the interface could / should be similar to the one for
the netlist.

> ElementListStart
> ElementNeed
> ElementListDone  ?

I was probably being over picky, but I wondered about something like:

ElementList(freeze)
ElementList(clear)
ElementList(add,....)
ElementList(add,....)
ElementList(add,....)
ElementList(add,....)
ElementList(thaw)

SelectElementsNotInElementList()
OrSomeOtherHorridActionName(;-)


> > 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

Personally, I'd prefer to see the "project management" smarts external
to the various apps. (Or in a library / module linked to gschem, gattrib
and PCB, so all the apps are all "project" aware).

Keeping the elementlist as state doesn't hurt either of the above
work-flows. Perhaps we could have a variant of the actions which doesn't
touch the user's selection though.

> > 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.

Adding the elementlist wouldn't necessarily require the above niceties
to be implemented though.. it would just form a more stateful version of
the list constructed when the actions describing the board are given.

> 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.

Caught me out.. I didn't read the whole patch.. only skimmed it, and
searched for things which interested me.

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

I seem to recall an issue with xgsch2pcb on that front though - perhaps
it was that my dumb implementation in dbus.c doesn't bother to return
it!

Another idea I had some while back about adding more verbose error
output from the actions. Integers don't really cut it in some cases -
unless we add a definition of various error codes to the action
interface. IE..

"Load(...)" can return "1 - File not found" "2 - Permission denied", ...


In dbus world though - just wrapping an "exec()" command - as I did for
xgsch2pcb, is not considered good form / good API design. I should
really be exporting all registered actions as explicit DBus methods.

The only other API I exposed was to retrieve the PCB file-name a
particular instance of PCB has open:

"  <interface name=\"org.seul.geda.pcb\">"
"    <method name=\"GetFilename\">"
"      <arg direction=\"out\" type=\"s\" />"
"    </method>"
"  </interface>"
"  <interface name=\"org.seul.geda.pcb.actions\">"
"    <method name=\"ExecAction\">"
"      <arg direction=\"in\" type=\"s\" name=\"action\" />"
"      <arg direction=\"in\" type=\"as\" name=\"args\" />"
"      <arg direction=\"out\" type=\"u\" />"
"    </method>"


NB: The org.seul.geda.pcb is an annoying, but it is not that important
that it doesn't match the gpleda.org domain. More incompatability
headaches would be caused by changing it than it probably warrants.





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