> Just add the proper "events" to your sourcecode. Your public (for the > gui) interface should go to gnet.h (callback prototypes, callback > registration, datastructure definitions). Any data returned by functions > in gnet.h is supposed be a copy of core data. Don't pass any pointers to > actual in-use core structures outside. We want to have separated data > for gui and core. > > There are several examples how you can implement the hooks for the gui. > > 1) If you add/remove entries from the table a lot a good example how gui > and core are supposed to interact is the fileinfo.[ch], > fileinfo_gui.[ch] + gnet.h or nodes.[ch] nodes_gui.[ch] and gnet.h > files. > > 2) If your data is mostly static what you are doing is probably more > like the gnet stats panel: gnet_stats.[ch] gnet_stats_gui.[ch] gnet.h > > Please don't take the upload stats or the downloads stuff as an example > of how to do it. Those still mix core and gui code. > > Third you can add code to dump the horizons data on the remote shell to > "shell.c". If possible shell.c should only have to use the stuff from > gnet.h. That might be convenient if you don't want to dig into the gui > stuff.
Thanks for the hints where to start for GUI integration. It'll be as static as the Gnet stats, so 2) applies. ;) I'll do the GUI stuff when the HSEP core code has been integrated into the source tree and when the handshaking is working. I've had a look at how glade works and it shouldn't be too much of a problem. Greetings, Thomas. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
