> > > 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?
Core gets main(), but the gui runs the show once it's up. > 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? There are three functions called from main() First, and as soon as possible, you call hid_init() which just sets up the list of available hids. In theory, you could link in a number of gui hids and have them auto-detect if the right shared libraries or environment is available, and only register themselves if it's possible to use them. Then, the core chooses which hid it's going to use. There are *always* multiple hids at this point, because we'll be supporting printing and exporting this way too. Second, you call the chosen hid's parse_arguments() hook. This needs to set up all the program's attributes, such as default layer colors and font paths, along with the GUI's needs. Then, the core does its initialization, such as loading a PCB and running any user scripts. Third and last, main() calls the hid's do_export() hook. For the GUI, this brings up the main window. This function isn't expected to return. > > In theory, we can code different usage philosophies too > > Such as who is main()... We'll probably need some way of changing what the core's "main" function is for Windows too, as it uses WinMain with a different signature. I'll have to see what mingw and cygwin provide for compatibility options. wxWindows is C++ though. Since pcb isn't, I think you'll have a hard time hooking wxWindows in anyway. I suspect all this will go into a "platform portability layer" independent of the HID stuff, with wxWindows being a "platform" along with windows and unix.
