Hi Bob and all, The way I see things: the (G)UI has an event driven concept, therefore based on a certain event a certain (G)UI callback calls one or more functions in the pcb core (I don't know if this block main() until this function in the pcb core is finished).
Even a CLI should be possible (for instance BOM/netlist/drill/CNC file generation --> just like gnetlist and gschem). This looks like a multiple client vs. single server configuration to me. The other way around would be that the pcb core knows which (G)UI (CLI/Athena/GTK/MS Windows/macOS/.../etc.) it is dealing with ... and code for all these instances in the pcb core. Just my EUR 0.02 Kind regards, Bert Timmerman. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bob Paddock Sent: dinsdag 1 november 2005 10:54 To: [email protected] Subject: Re: gEDA: PCB HID status > > which I'm not sure all GUI widget kits support, > > That's why I think HID wins here - each GUI kit does what it can, Something I am not clear on is who is running main(), the GUI or the pcb core? For example in the wxPCB version I'm trying to put together for Windows the wxWidget tool kit assumes that it is running main(). Each user action is an event that causes a subroutine to be called. If the core is running main() I'm not sure how to handle that? > In theory, we can code different usage philosophies too Such as who is main()...
