[GIO] Using GBufferedOutputStream
Hello,
I am a bit at a loss as to how GBufferedOutputStream is supposed to be
used. My aim is to have a simple high-level non-blocking
send_message() function that buffers a new message and flushes the
data on the background. A naive method of doing so could be the
following (partially-pseudo) code (assuming I understood the docs
right):
GOutputStream *out;
void on_connect() {
out =
g_buffered_output_stream_new(g_io_stream_get_output_stream(G_IO_STREAM(connection)));
g_buffered_output_stream_set_auto_grow(G_BUFFERED_OUTPUT_STREAM(out), TRUE);
}
void handle_flush(..) {
// close connection on error
}
void send_message(char *msg) {
// this write should neither block nor fail, since we should be
writing to a buffer and auto-grow is true
g_output_stream_write(out, msg, ..);
g_output_stream_flush_async(out, .., handle_flush, ..);
}
The above method assumes that send_message() is not called before the
message of a previous call has been flushed. Otherwise the later flush
would, I assume, fail because there is a pending operation on the
stream. Now suppose I would want to handle this situation and allow
send_message() to be called at any time:
void handle_flush(..) {
if(error)
report_error_and_close_connection()
else if(buffer_is_not_empty())
g_output_stream_flush_async(out, .., handle_flush, ..);
}
void send_message(char *msg) {
// this write should neither block nor fail, since we should be
writing to a buffer and auto-grow is true
g_output_stream_write(out, msg, ..);
if(!g_output_stream_has_pending(out))
g_output_stream_flush_async(out, .., handle_flush, ..);
}
However, there are two issues with the above solution:
- GBufferedOutputStream does not provide any method to check whether
the buffer is empty, or whether there are any outstanding bytes that
need to be flushed. This is required in handle_flush() to determine
whether a new flush is required.
- Will GBufferedOutputStream correctly handle the situation where new
data is added to the buffer while it is performing a flush operation
on the background? I've skimmed a bit through the code, but get the
impression it is not supposed to be used like this.
I also just encountered a problem with g_output_stream_write(): in
some situations, it reports to have written less bytes than I asked it
to. I had assumed this to be impossible when writing to an
auto-growing buffer. I have not investigated this problem any furher
yet, though, and have no idea whether it is related to the above
problem.
Anyway, I have the impression that I'm trying to use
GBufferedOutputStream in a way it is not supposed to be used, yet I
don't think I'm trying to do anything obscure. I could have
send_message() queue messages in a separate queue and write() them in
the background from handle_flush(), but that is rather inefficient
(many of the messages are pretty small and could be combined in a
single write()) and would probably require more code than simply
implementing my own buffer.
I keep wondering if there is no better solution to do this, and how
GBufferedOutputStream *is* supposed to be used...
Ayo.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
edit gtktreestore/gtkliststore structure at runtime
is there a way to edit a gtktreestore/gtkliststore at runtime after it was loaded from a gtkbuilder xml file (made with glade)? in particular i want to append/insert/remove columns i could create these columns initially and after show/hide their, but i have a variable number of these columns otherwise i'll create the entire gtk*store at runtime thanks in advance ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [GIO] Using GBufferedOutputStream
(Replying to myself) On 7 April 2011 12:24, Ayo a...@blicky.net wrote: [snip] - Will GBufferedOutputStream correctly handle the situation where new data is added to the buffer while it is performing a flush operation on the background? I've skimmed a bit through the code, but get the impression it is not supposed to be used like this. Learned what happens after some experimentation: the g_output_stream_write() will fail with Stream has outstanding operation, thus not even allowing new writes to the buffer while it is flushing. This confirms that I'm using it in a way it is not supposed to be used. I also just encountered a problem with g_output_stream_write(): in some situations, it reports to have written less bytes than I asked it to. I had assumed this to be impossible when writing to an auto-growing buffer. I have not investigated this problem any furher yet, though, and have no idea whether it is related to the above problem. Also solved this mistery. This was caused by a bug in my code and _write() was called with an already unref()'ed GOutputStream. [snip] I keep wondering if there is no better solution to do this, and how GBufferedOutputStream *is* supposed to be used... While I'm still wondering how (or more importantly: when) GBufferedOutputStream is supposed to be used, it apparently isn't what I was looking for. Implementing my own buffer seems like the best option... On a related note: why are all these high-level I/O modules using threads for async operations, rather than using the main loop for polling the underlying filehandles (where possible). That would be both more efficient and allows better cancellation. I'm inclined to fall back to plain old socket programming with all these levels of indirection, added complexity and inefficiencies. :-( Ayo ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glib: a Win32 discussion
i think that this message was too long and contained too many issues. i believe you'll get more traction if you: (a) divide the issues I wanted to do that but they are all pretty inter-related. I guess the discussion on gstdio could be separate. (c) attach fixes where applicable Before I spend time making changes I want to get permission from the people that are ultimately going to be responsible for committing the fixes. I've wasted too many hours of my life in the past working my ass off on a patch set only to have it rejected by the maintainers because it disagreed with some underlying philosophy. Since I am new to this list and don't know you guys that well I figured I would wait for the maintainers to give me a go/no go before I started doing real work. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gobject introspection in runtime possible?
Hello list, Just a flash question about introspection (I'm a newbye). Is it possible to get introspection data from a GObject in runtime? I was wondering if it would be convenient to create a special introspectable parent object to declare d-bus interfaces of derived, simply listing properties and class initialized methods. As I see gobject-introspection do it offline reading .c file thanks in advance, Andrea ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Tor Lillqvist just mentionned recently on his blog (http://tml-blog.blogspot.com/2011/03/gtk-on-windows-i-am-not-really-doing-it.html) that he was moving on to new things (this is bad news for us if you consider all the high-quality work he did for many years.) So, at the moment, it's unclear who will be in charge next. On 04/07/2011 09:29 AM, Kean Johnston wrote: i think that this message was too long and contained too many issues. i believe you'll get more traction if you: (a) divide the issues I wanted to do that but they are all pretty inter-related. I guess the discussion on gstdio could be separate. (c) attach fixes where applicable Before I spend time making changes I want to get permission from the people that are ultimately going to be responsible for committing the fixes. I've wasted too many hours of my life in the past working my ass off on a patch set only to have it rejected by the maintainers because it disagreed with some underlying philosophy. Since I am new to this list and don't know you guys that well I figured I would wait for the maintainers to give me a go/no go before I started doing real work. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Emmanuel Thomas-Maurin manutm...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
I've never used GLib on windows really myself, just commenting from the perspective of GNOME: On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston kean.johns...@gmail.com wrote: By avoiding the CRT altogether and using native Windows functions that use handles, and using a memory allocator other than malloc, all of these problems go away. This sounds reasonable. Memory allocation is the easy bit. HeapAlloc maps nicely onto malloc. There are other bits that are more problematic. The next easiest to solve is stat(). Gio already makes a token gesture at wrapping stat() but its wrapping is a bit TOO thin. On the subject of this, along with gstdio; we should be pushing people towards Gio's very extensive and nice I/O API rather than reinventing it in GLib. So for the limitations and weirdness of the random I/O wrappers in GLib on different platforms - document and move on. Wrapping stat can also fix the problem of having the uid_t / gid_t types differ not only from system to system, but also change on the SAME system depending on defines. We can force these to always be 32-bit. Similarly, ino_t. If your application deals with uids, I think you're going to end up with platform-specific code; the complexities around identity are just too high. That goes doubly for inode numbers, which - why would you care unless you're a backup app, and then you're *definitely* going to get into platform specific stuff. Last, but by no means least, is the reliance on compiled files, like compiled schemas (or in the case of Gtk, icon caches). On UNIX systems where things are installed in a universally-accessible location, this isn't a problem, but on Win32, where multiple applications could all include their own private copies of the DLL's, this is a problem. Fixing this is a bit tricky but very doable. Windows does provide two places that are predictable and universally accessible: the registry, and %ProgramData%. So you're suggesting making them private to the app? It's not clear to me because I don't know the semantics of %ProgramData%. I think it would be a good goal to make deploying these things per-app work more easily. One last thing, since it has proven to be a source of considerable incompatibility, and that's the reliance on D-Bus. I think it should remain possible to use dbus if you want it, if your application really needs it, but to have relatively (from my position of ignorance) unrelated things like gapplication absolutely rely on it is a mistake, as far as I can see. I only intended DBus to be used on GNOME; yes, GApplication needs a Windows backend. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Thu, Apr 7, 2011 at 1:50 PM, Ben Pfaff b...@cs.stanford.edu wrote: (Maybe GIO provides a portable way to find that out. In a quick look I could not find one.) http://developer.gnome.org/gio/stable/GFileInfo.html#G-FILE-ATTRIBUTE-UNIX-INODE:CAPS ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
clipboard_get_timestamp
Once code starts looking like an #ifdef soup it might be time to introduce
a method on, say, the window object.
IMHO, of course.
Morten
#ifdef GDK_WINDOWING_X11
if (GDK_IS_X11_WINDOW (window))
{
timestamp = gdk_x11_get_server_time (gtk_widget_get_window
(clipboard_widget));
}
else
#endif
#if defined GDK_WINDOWING_WIN32
if (GDK_IS_WIN32_WINDOW (window))
{
timestamp = GetMessageTime ();
}
else
#endif
#if defined GDK_WINDOWING_BROADWAY
if (GDK_IS_BROADWAY_WINDOW (window))
{
timestamp = gdk_broadway_get_last_seen_time (window);
}
else
#endif
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Hi, For the record, except for GApplication, nothing cross-platoform in GLib/GTK+ is using the GIO D-Bus routines (except for the GIO D-Bus routines themselves). I do agree that we should try avoiding using D-Bus except for Linux/Unix backends in the GLib/GTK+ stack itself. Btw, I wrote about GDBus and Win32 a couple of months back, see http://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00123.html The take-away here is that D-Bus on Win32 can be made to work just fine. On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston kean.johns...@gmail.com wrote: One last thing, since it has proven to be a source of considerable incompatibility, and that's the reliance on D-Bus. I think it should remain possible to use dbus if you want it, if your application really needs it, but to have relatively (from my position of ignorance) unrelated things like gapplication absolutely rely on it is a mistake, as far as I can see. dbus is really not appropriate for, or required for, many applications that would otherwise want to use Glib/Gtk. Should my Windows MP3 editor really need dbus daemons running just because it uses GtkApplication (which in turn uses gio/glib and thus the dbus coupling)? First of all, should your MP3 editor spawn dbus-daemon.exe _just_ because it is using GtkAppication? Absolutely not. But if your MP3 editor wants to provide an easy to use interface for automation, remote control or whatever... then, yes, D-Bus is an excellent choice. Even on Win32. So is COM, CORBA, Java Remoting etc. or any other technology but these are not really as cross-platform as D-Bus is (or can be) (Besides, dbus-daemon.exe is just one extra process which should be nowhere as big as your gtk+-using application. Neither in file size or memory/resource usage.) Seems like a good bit of gio could use some re-thinking and this again is maybe more appropriate for a 3.0 release where we may be able to get away with slightly more disruptive changes. Well, GApplication should grow a Win32 backend. I don't quite think that's rethinking or a good bit .. it's just filling in the missing bits... David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Well, GApplication should grow a Win32 backend. I don't quite think that's rethinking or a good bit .. it's just filling in the missing bits... Yeah I did perhaps over-state it :) But in other good news further examination of glib showed me that it already wraps, or provides if the system one's are deficient, the problematic stdio functions. About the only bit that's missing is wrapping the actual FILE structure so that, on silly platforms like Win32 where we want to avoid the system stdio, we can. If only Microsoft knew what a terrible can of worms they created with their uncharacteristically badly implemented CRT. Instead of dealing with all of these multiple CRT runtimes they could have kept one, always accessible version with versioned symbols. Sigh. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
2011/4/7 Krzysztof Kosiński tweenk...@gmail.com: 2011/4/6 Kean Johnston kean.johns...@gmail.com: Everyone, WARNING: long, detailed message. If you don't care about Win32, move on. Other annoying Windows issues specific to glib: snip 3. GSettings using the registry. This means portable apps (in the sense of apps that you can carry with you on an USB stick: http://portableapps.com/) cannot use it, because they have to store the settings somewhere on the USB stick, not in the registry. It should be possible to use dconf on Windows. GSettings has switchable backends. An app, or a user, can choose between the registry backend or the keyfile backend at runtime. Sam ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
patch sugestion for packagers
hi, if you are maintaining a gtk-doc package, please pick this patch until I release 1.18: https://bugzilla.gnome.org/show_bug.cgi?id=646870 Stefan ___ gtk-doc-list mailing list gtk-doc-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-doc-list
Re: Question about GTK+ and timers
Hi Igor,
On Wed, 6 Apr 2011 22:38:43 -0700 you wrote:
Just one question: AFAIU this pair is polling the port for data and
when they become available I need to
drop them in the GUI.
It's going to be something like MT, right?
MT?
It's not a threaded approach, if that's what you mean.
Open the serial port and attach it to a g_io_channel:
fd = open ( /dev/ttyS0, O_RDWR|O_NONBLOCK );
hFile = g_io_channel_unix_new ( fd );
g_io_channel_set_encoding ( hFile, NULL, tErrPtr );
Now you can hook up a call-back:
RxEventSrc = g_io_add_watch ( hFile, G_IO_IN, HandleAsyncRx,
(gpointer)Instance );
Then in the call-back you read the incoming data and pass it to the GUI:
gboolean HandleAsyncRx ( GIOChannel *source, GIOCondition condition,
gpointer data)
{
GIOStatus stat;
gsize len;
GError * err = NULL;
unsigned char tmpbuf[32];
stat = g_io_channel_read_chars ( source,
(gchar*)tmpbuf, sizeof(tmpbuf), len, err
);
// etc
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
Hi, Robert,
On Thu, Apr 7, 2011 at 12:59 AM, Robert Pearce r...@bdt-home.demon.co.uk
wrote:
Hi Igor,
On Wed, 6 Apr 2011 22:38:43 -0700 you wrote:
Just one question: AFAIU this pair is polling the port for data and
when they become available I need to
drop them in the GUI.
It's going to be something like MT, right?
MT?
It's not a threaded approach, if that's what you mean.
Open the serial port and attach it to a g_io_channel:
fd = open ( /dev/ttyS0, O_RDWR|O_NONBLOCK );
hFile = g_io_channel_unix_new ( fd );
g_io_channel_set_encoding ( hFile, NULL, tErrPtr );
Now you can hook up a call-back:
RxEventSrc = g_io_add_watch ( hFile, G_IO_IN, HandleAsyncRx,
(gpointer)Instance );
But isn't it the same as registering the timer?
Then in the call-back you read the incoming data and pass it to the GUI:
gboolean HandleAsyncRx ( GIOChannel *source, GIOCondition condition,
gpointer data)
{
GIOStatus stat;
gsize len;
GError * err = NULL;
unsigned char tmpbuf[32];
stat = g_io_channel_read_chars ( source,
(gchar*)tmpbuf, sizeof(tmpbuf), len,
err );
// etc
And this is done the same way as the timer: it creates thread and
performs this function in it, right?
Thank you.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
On Thu, Apr 7, 2011 at 2:07 PM, Igor Korot ikoro...@gmail.com wrote: Now you can hook up a call-back: RxEventSrc = g_io_add_watch ( hFile, G_IO_IN, HandleAsyncRx, (gpointer)Instance ); But isn't it the same as registering the timer? not at all. And this is done the same way as the timer: it creates thread and performs this function in it, right? not at all. your callback is executed in the thread running the event loop but not based on a timer - based on when actual data arrives from the serial port. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
Hi, On Thu, Apr 7, 2011 at 11:15 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Thu, Apr 7, 2011 at 2:07 PM, Igor Korot ikoro...@gmail.com wrote: Now you can hook up a call-back: RxEventSrc = g_io_add_watch ( hFile, G_IO_IN, HandleAsyncRx, (gpointer)Instance ); But isn't it the same as registering the timer? not at all. And this is done the same way as the timer: it creates thread and performs this function in it, right? not at all. your callback is executed in the thread running the event loop but not based on a timer - based on when actual data arrives from the serial port. So is there one thread or two? ;-) Thank you. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
On Thu, Apr 7, 2011 at 2:24 PM, Igor Korot ikoro...@gmail.com wrote: So is there one thread or two? ;-) one thread. this has the same problem that anything using a (G)UI event loop for I/O does - the callback may be delayed by other event handling. in the real world, this is rarely a problem, especially with such intermittent bursts of data. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
OK, thanx. On Thu, Apr 7, 2011 at 11:47 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Thu, Apr 7, 2011 at 2:24 PM, Igor Korot ikoro...@gmail.com wrote: So is there one thread or two? ;-) one thread. this has the same problem that anything using a (G)UI event loop for I/O does - the callback may be delayed by other event handling. in the real world, this is rarely a problem, especially with such intermittent bursts of data. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Using a gtknotebook in a main window to display a child window
François Rappaz francois.rap...@unifr.ch writes: Gtk2::Widget::reparent($vbox, $sfctrl); Would that be better as a method $vbox-reparent($sfctrl) ? ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
