Re: gEDA-user: outline layer by default [was: outline layer not exported]

[DJ Delorie <dj@xxxxxxxxxxx>]

> There are a few things which need thought through..

Most of these can be solved with suitable actions and/or command line
options.

> We may loose flexibility in specifying custom gsch2pcb search paths, and
> whether to use M4 / non M4 libraries. These then become implicit by
> PCB's configuration. Will this break many workflows, or do we need
> actions to modify PCB's library settings on the fly (perhaps
> temporarily, during the run-time of the action script)?

If it breaks workflows, it's because you have two tools with two
different views of reality.  Think of it as an opportunity to fix that
:-)

> gsch2pcb currently deletes elements in some circumstances. Can we
> formalise what those are, and how we tell PCB to do the same?

Another option is to define an "element list" file format specifically
for this purpose, but still...

SelectAll()
UnselectElementByName("U3")
...
DeleteSelected()

> For example, how will gsch2pcb's action script tell PCB to remove
> component "X" without having parsed the PCB file? (And if we did it
> at runtime, how do we identify component "X" if its being removed
> because it had no refdes etc..?)

Now we're talking about feedback from pcb, which would require running
it as a script ("pcb --action-string 'DumpBoardElements()'") or using
DBUS.

It might make sense to pass it a "list of desired elements" file and
let pcb decide what to delete/replace/add.  It might be able to do so
more intelligently than gsch2pcb anyway.

> I guess we could still let gsch2pcb manually do the deleting part,
> but it would be nice to avoid the necessity to modify files on disk
> and grok PCB's file-format.

Esp if we want to add to pcb's format.

> What might work is having a way to enumerate all components on the
> board (perhaps select each in turn), and to query enough information
> about each to decide delete / don't delete. This requires a far more
> full implementation for actions, including return codes (at the
> least, but this is desirable anyway), and possibly more complex
> data-types.

DBUS.


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