Re: gEDA-dev: PCB: external HID?

[DJ Delorie <dj@xxxxxxxxxxx>]

> 1. gui/printer/exporter; the .h says the HID needs to choose exactly
> one of these. Is it possible to have an external HID that registers
> 3 different HID structures so it may have gui, printer and exporter
> parts?

Yes.

> 2. The .h mentions that there can be only one printer HID at a
> time. What about the gui HID? Comment above hid_find_gui() suggests
> there can be only one. If so, is there a plan to change this? (It's
> not necessary for my project, I think (^2))

In theory, you can have multiple GUIs compiled in to PCB, and choose
one at runtime.  In practice, we don't do that yet.  It would be nice
to at least choose between, say, Gtk and batch.

Also, I've been thinking about adding more types of hids.  We support
exporters; why not importers?  And what about "wizards" which just act
on the existing board?  The advantage to compartmentalizing them that
way, is you can make them shared libraries you load at runtime, rather
than actually compiling them in like we do for, say, the autorouter.

> 3. HID initialization: main() calls hid_init() which then runs
> hid_*_init(). These HID-specific init routines do all the
> registration. Do I get it right, is it this simple or are there any
> tricks I missed?

That's it.  That just makes up for the fact that we don't have
reliable pre-main initializers, like C++ would offer.  It's designed
to work with C++ hooks, or gcc's "init function" attribute, so it
should be safe for pre-main calls too.  It just makes a list of HIDs;
the actual processing happens later.

> 4. Does the order of calling hid_*_init() functions matter?

No, unless you compile in multiple GUIs or multiple printers.

> 5. Are there special requirements for a HID, like for blocking the
> process for arbitrary time, using the IO or anything? In other
> words, are there some thumb rules set up to avoid HIDs to interfere?

No.  HIDs do their thing in their own time, and return when they're
done.  I was thinking about adding a hook for non-GUI hids to call the
gui HID to say "still working" and give a progress dialog, but we have
nothing like that at the moment.

> 6. Is there a periodoc entry point that PCB calls from time to time?

No.  If you need a timer, ask the gui to give you a timer.

> 7. And of course, the administrative part: would gEDA developers like
> and/or support the project? 

If it (1) seems generally useful, and (2) is written to be
maintainable, it has a chance of getting accepted.  As for support,
we'd expect that from you :-)

> [1] see also: dependency panic :)

It depends on how well it all works when the dependencies are missing.

> [3] If the answer is yes for question 3 and 4 above, the external
> HID can be a simple .so which has a special 'constructor' part that
> runs before main().

Neat trick.  Hopefully, at some point in the future we'll use .so's
ourself, then it won't be so hacky.

> [4] It would be nice to do the panelize and other automated things
> *inside* PCB, would save some time.

Hence the "wizards" I mentioned earlier.

> Also I could easily add some sort of socket-communication so other
> processes could drive PCB

Note that pcb already has such a socket.


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