> 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).
Yes, HID uses the event driven model. Once the HID has control, it keeps control, and calls back to the core to do things. The design rule is: the core doesn't know ANYTHING about the hid except what's documented in hid.h, but the hid can do whatever it wants with anything in the core. That does mean that if you change the core data you may have to fix all the hids. The advantage is that I don't have to define a generic pcb core API. Most of the information is hid->core anyway. > Even a CLI should be possible (for instance BOM/netlist/drill/CNC file > generation --> just like gnetlist and gschem). That would be an exporter, me thinks. A non-interactive conversion of a .pcb file to some other file format (ps, png, autocad, gerber, bom) is an export; the interface to the system printing layer (windows or lpr) is the printing hid, and any interactive hid is a "gui". You could have a GUI hid and a TUI (text) hid in the same binary though. I hadn't thought about a standard way to choose one over the other. I suppose the TUI could declare itself to be an exporter, and use the export option. > This looks like a multiple client vs. single server configuration to me. Yes. > 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. That's what I'm trying to avoid ;-)
