Re: [gtkmm] On Glib::IOChannel wrappers
- From: Tassos Bassoukos <abas aix meng auth gr>
- To: Martin Schulze <MHL Schulze t-online de>
- Cc: gtkmm-list <gtkmm-list gnome org>
- Subject: Re: [gtkmm] On Glib::IOChannel wrappers
- Date: Fri, 13 Sep 2002 23:21:13 +0300 (EEST)
On Fri, 13 Sep 2002, Martin Schulze wrote:
> Am 12.09.2002 23:27 schrieb(en) Tassos Bassoukos:
[snip]
> > * Glib::Source (as currently implemented) cannot wrap non-glibmm
> > generated GSource's, ergo Glib::IOChannel cannot generte watches,
>
> I agree with Murray: A patch adding Glib::Source::Source(GSource* source)
> would be welcome (but probably non-trivial)! :-)
... with the emphasis on *non*trivial :-) Anyway, I don't yet feel
comfortable enough with gtkmm internals to tackle such an issue.
> > 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 :-)
>
> 1. Just to make clear: You are talking about sockets and not about pipes
> or something similar that is represented by an int ("HANDLE") in Win32 ?!
> I do hope that the latter is supported by Glib::IOSource. Since there was
> no feedback so far regarding that matter and I'm not using Win32 I don't
> really know, however! Does GIOChannel support Win32 sockets anyway and how?
Yes, gnet supports networking for Unices (therefore also Mac OSX) and
Win32 with the same API.
> 2. What do you mean by "ugly"? Can you think of a more elegant API?
I meant "ugly" as in "exposes representation to the class user", where the
representation is an int.
> 3. Talking about portability: In the very first lines of your patch I
> notice a call to g_io_channel_unix_new(). Are you sure this is a
> portable function? I remember that I avoided it in the implementation
> of Glib::IOSource. Also are you sure that g_io_channel_new_file() is
> portable?
You have a valid point there - the current version is relatively
win32-unfriendly - for now :). g_io_channel_new_file() is portable, as it
will just open a local file. (at least the source code was clean)
> 4. I don't want to be ignorant, but why do you need GIOChannel at all?
> What functionality does it provide that ANSI C++ streaming classes don't?
> Support for Win32 sockets??
Asynchronous notification. Integration with the main event loop. Not
relying on threads for I/O.
Yes, I too find it strange that i'm the first to experience such a raw
need ;-) for these wrappers. It is possible that i'm missing something...
> Regards,
>
> Martin
Cheers,
Tassos
--
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]