Re: [gtkmm] On Glib::IOChannel wrappers

[Murray Cumming <murrayc usa net>]

On Thu, 2002-09-12 at 22:27, Tassos Bassoukos wrote:
> 
> 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.

If glibmm needs to be improved, then please try to improve it.

> 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?

Doesn't glibmm/gtkmm wrap GErrors as exceptions? Surely you can find
something similar in glibmm.

>  * 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!

The only thing that ever really makes sense sometime is patches. Patches
can be criticised and improved.

-- 
Murray Cumming
murrayc usa net
www.murrayc.com