Re: gEDA-dev: PCB: external HID?

[Igor2 <igor2-at-NOSPAMinno_dot_bme_dot_hu>]

Hi, thanx for the rapid reply.

On Tue, 29 Aug 2006, DJ Delorie wrote:

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

What about addig a plugins which means the gui creates a new menu or list
or whatever where you can choose a function and not limiting functions to
manipulate existing board? At least for my external plugin-HID this would
help even more :)

>> 4. Does the order of calling hid_*_init() functions matter?
>
>No, unless you compile in multiple GUIs or multiple printers.

In which case only the first or the last is used? If the first, I can
hook as I will be the first from the .so :)

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

Good idea.

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

The idea is that the external HID doesn't necessary have a GUI. It's not
to replace all the HIDs PCB has, rather to hook any functionality and
complement them. Of course the external HID should not depend on a
specific HID, like the gtk one to have a timer. 

Is the main loop/event loop donated by the gui hid?

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

I meant support as answering questions (as you did), doing very small
modifications in the code or at least accept patches as long as they don't
really change the behaviour or the design of the code, but is required to
allow such an external HID to interact with PCB.

>> [1] see also: dependency panic :)
>
>It depends on how well it all works when the dependencies are missing.

Well, the GPMI external HID would depend on GPMI and gpmi-extensions. Of
course when the user say he wants to script in tcl, he would need
libtcl; for python, the corresponding library that has the python
interpreter; for ruby, the ruby lib, etc. So it's that you simply can't
say "we give you this stuff and it just works and it supports all
scripting languages". So for PCB, it's the worst kind of dependency hell,
optionally involving at lest 6-8 libs with all their dependencies
recursively. This why I say I don't aim to get it into the cvs, rather I
try to find a way to maintain it as a separate project so all the
dependency 'problems' are only for this project, not for PCB. 

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

Yeah, if it was GPMI at the first point, all HIDs would be a module which
could be choosed to compiled to .so so PCB can load them dynamicly or to
be static compiled to PCB so one can save the overhead of loading a
dynamic lib. For example where I often print, I would configure the
printer/exporter HIDs to be static, while on other hosts I would choose
them to be dynamic loaded :) 

<snip>

>Note that pcb already has such a socket.

Wasn't that pipe? Where can I find it in the code? A quick grep for word
socket didn't result in anything useful :)

Igor2




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