[gtkmm] On Glib::IOChannel wrappers

[Tassos Bassoukos <abas aix meng auth gr>]

Hi all,
lately i've felt the need to wrap libgnet, a socket library intended for
use by Gtk+ programs. The major problem I've stumbled upon is that gnet is
returning GIOChannel's (not int's), which are not wrapped in glibmm.

I've now written some preliminary wrappers, but they need some polishing
first; most importantly, I need enlightenment on some items so that they
will fit well with the rest of Glib:

 * IOChannels have the potential for lots of errors, as evidenced by the
ever-present GError**. Should these be thrown as C++ exceptions by the
wrappers, or should I use a trailing Glib::Error*& parameter?

 * Glib::Source (as currently implemented) cannot wrap non-glibmm
generated GSource's, ergo Glib::IOChannel cannot generte watches, removing
one of IOCHannels more useful features. One could use SignalIO.connect(int
fd,IOCondition cond), but that is non-portable as Win32 sockets are not
represented as ints, and are not regular file descriptors. Also, it looks
ugly :-)

 * I'm trying to use Glib::ustring's everywhere, but there are some
efficiency considerations for bulk read and write operations which would
benefit from a more low-level approach; these are the only two methods
taking char*'s.

 * Glib::IOChannel is currently non-derivable, as a vfunc returns a
GSource*. Should derivability be required, two implementations must be
written, one for the wrapped GIOChannels and one for the C++ classes,
implementing the vfuncs.

Hope this makes sense!

Thanks all!

-- 
Bassoukos Tassos   +30 31 996011 / +30 93 7109954       IT Generalist

Unix:        Your gun, Your bullet, Your foot, Your choice.
M$-CE/ME/NT: Same as Unix, BUT: No choice, and We Aim Higher.
                         -- From the Linux S/390 mailing list