Quoting alex <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel: :When I updated the bitzi core code I decided on a call-back system for :updating the GUI given the async nature of Bitzi requests. However I've :noted the changes made in splitting core and GUI functionality have :added an extra layer of indirection.
The "bridge" routines in ui2c (UI to core) and c2ui (core to UI) are there to allow easy decoupling later on. For instance, if we have different processes for the core and the GUI, then the ui2c layer becomes requests sent by the GUI process to the core "server", and c2ui becomes "notifications" sent unsollicited by the core to the GUI. :Is this going to be allowable for the GUI to pass a callback function to :the core via the if/* code? Absolutely node. Everything in the bridge must be serializable.\ We pass download structures accross, but that is rather OK because one can imagine that the required entries for the GUI be serialized. :Or should the callback be "decoupled" in the if/* code? I know there are "events" between the GUI and the core that let the GUI be notified when the core changes something, and those are not yet part of the bridge. In the end, everything must go through the bridge to make separation possible and identify the interface between the two layers. :I assume the aim is eventually that the GUI and the Core may well not be :linked into the same binary? Exactly. A good guide would be: think about the GUI and the core being separate processes, with the bridge structures being your IPC mechanism. Don't share data structures, don't call routines directly, and naturally, don't supply routine callbacks as pointers! Raphael ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
