Re: How to add stuff to treeviews??
On Tue, May 29, 2007 at 08:15:40AM +0800, Jason Brisbane wrote: I too am trying to use a Treeview model view, etc. I have created a list store before and that works fine. Now I am creating a new program and want to create a Treeview with a parent iter and 6 set child iter (ie you create a new row and the row auto creates the 6 children underneath) But I am having trouble doing ANYTHING with the treeview. Cut/paste the example from the gtk 2.0 API simply fails to do anything. I am left with a blank screen. inserting g_print shows that the code is being called, but nothing is being displayed. Since the gtk_tree_view is created in glade, I am simply doing a lookup_widget on the treeview and adding columns to it (ie none exist) and then populating the data. My code, very stripped down (to remove possible errors) is: Please post selfcontained (compilable) code. Anyway, you exchanged the child and parent iters in the tree store construction. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GdkImage from GdkPixbuf
I've been beating my head against the tree for this one for the last 2 days... so, is there some code out there that will gdk_pixbuf_render_image() ? I actually dont even want compositing, something like: memcpy (image-mem, pixbuf-pixels, image-bpl * image-height) would do fine (minus the alpha channel)... but I can see its going to be a little more complex (taking byte order into account, image depths etc). If I have to end up writing this myself, are there any interesting bits of lowlevel gdk that will help me ? I'm currently looking at the composite() functions in gdkdraw.c... Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GdkImage from GdkPixbuf
On Tue, May 29, 2007 at 11:04:53AM -0400, Tristan Van Berkom wrote: I've been beating my head against the tree for this one for the last 2 days... so, is there some code out there that will gdk_pixbuf_render_image() ? I actually dont even want compositing, something like: memcpy (image-mem, pixbuf-pixels, image-bpl * image-height) would do fine (minus the alpha channel)... but I can see its going to be a little more complex (taking byte order into account, image depths etc). If I have to end up writing this myself, are there any interesting bits of lowlevel gdk that will help me ? You can draw GdkPxibuf on a GdkDrawable (i.e. GdkPixmap) with gdk_draw_pixbuf() and get the contents of the GdkDrawable to a GdkImage with gdk_drawable_get_image() or gdk_drawable_copy_to_image(). On full Moon if it's even Tuesday. And it goes through the X server. Actually I think if you use GdkImage you deserve it... There are some useful bits in GdkRGB, but more in its source code than its API. And by bits I mean almost complete gdkrgb.c including the dithering matrices. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GdkImage from GdkPixbuf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Nečas (Yeti) wrote: On Tue, May 29, 2007 at 11:04:53AM -0400, Tristan Van Berkom wrote: I've been beating my head against the tree for this one for the last 2 days... so, is there some code out there that will gdk_pixbuf_render_image() ? I actually dont even want compositing, something like: memcpy (image-mem, pixbuf-pixels, image-bpl * image-height) would do fine (minus the alpha channel)... but I can see its going to be a little more complex (taking byte order into account, image depths etc). If I have to end up writing this myself, are there any interesting bits of lowlevel gdk that will help me ? Is this what you want? GtkImage *image_play; image_play = gtk_image_new_from_pixbuf(pb_play); Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7D0BD5D1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iD8DBQFGXFIz6w2kMH0L1dERAhxeAJ4/CC2oxlj3CvPqGqlKDN48phRPeACfWeC8 XgFFzkYBF6NEJb8OLiukYTE= =sQJf -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GdkImage from GdkPixbuf
On Tue, 2007-05-29 at 18:02 +0200, David Nečas (Yeti) wrote: On Tue, May 29, 2007 at 11:04:53AM -0400, Tristan Van Berkom wrote: I've been beating my head against the tree for this one for the last 2 days... so, is there some code out there that will gdk_pixbuf_render_image() ? I actually dont even want compositing, something like: memcpy (image-mem, pixbuf-pixels, image-bpl * image-height) would do fine (minus the alpha channel)... but I can see its going to be a little more complex (taking byte order into account, image depths etc). If I have to end up writing this myself, are there any interesting bits of lowlevel gdk that will help me ? You can draw GdkPxibuf on a GdkDrawable (i.e. GdkPixmap) with gdk_draw_pixbuf() and get the contents of the GdkDrawable to a GdkImage with gdk_drawable_get_image() or gdk_drawable_copy_to_image(). On full Moon if it's even Tuesday. And it goes through the X server. Actually I think if you use GdkImage you deserve it... In fact, using GdkImage is the only way you can get MIT-SHM pixmaps, the whole point is to keep the pixmap store in a shared memory segment so that when freeing ~20MB of pixmaps there's no huge portions of fragmented free memory locked down by the X server process. The pitfall is that I /should/ be loading my pixbuf directly into the shared memory segment owned by the GdkImage but instead I'm stuck with GdkDrawable routines (which result in XCopyArea which does do a local copy but involves some synchronization with the server, which I believe slows things down considerably). So thankyou very much for deciding what I deserve for me. There are some useful bits in GdkRGB, but more in its source code than its API. And by bits I mean almost complete gdkrgb.c including the dithering matrices. I've found gdkpixbuf-drawable.c to be the pain that I'm looking for, the rgbconvert() function should probably not take a GdkImage parameter and thus allow for two-way conversions, allowing the addition of a gdk_pixbuf_render_image() api. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Run Loop Memory Management
Good day, new to the list and GTK+ in general. I am formerly a Macintosh developer. Currently however I am now working on Objective C bindings for GTK+. I am currently looking at the documentation for the run loop which I have found located at http://developer.gnome.org/doc/GGAD/sec-mainloop.html . My question is, I need to implement the autorelease pool's run loop hook that basically runs once every run loop cycle and frees memory. So far guint gtk_idle_add(GtkFunction function, gpointer data); looks the most promising for this purpose. However, being new to this library I would like to get the opinions of those who are more experianced whether there is a better -- or more appropriate place for me to put this code. Thank you for your time, Dan Saul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Run Loop Memory Management
tir, 29 05 2007 kl. 18:12 -0500, skrev Dan Saul: I am formerly a Macintosh developer. Currently however I am now working on Objective C bindings for GTK+. I am currently looking at the documentation for the run loop which I have found located at http://developer.gnome.org/doc/GGAD/sec-mainloop.html . My question is, I need to implement the autorelease pool's run loop hook that basically runs once every run loop cycle and frees memory. So far guint gtk_idle_add(GtkFunction function, gpointer data); looks the most promising for this purpose. However, being new to this library I would like to get the opinions of those who are more experianced whether there is a better -- or more appropriate place for me to put this code. As far as I understand the autorelease thing, an idle handler is exactly what you want, it will be run after the loop is done with processing events and no more work remains. By returning an appropriate value you can control how many times it'll be run. Cheers, Maciej -- Being really good at C++ is like being really good at using rocks to sharpen sticks. (Thant Tessman) Maciej Katafiasz [EMAIL PROTECTED] http://mathrick.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Run Loop Memory Management
On Tue, 29 May 2007 18:12:57 -0500 Dan Saul wrote: Good day, new to the list and GTK+ in general. I am formerly a Macintosh developer. Currently however I am now working on Objective C bindings for GTK+. I am currently looking at the documentation for the run loop which I have found located at http://developer.gnome.org/doc/GGAD/sec-mainloop.html . My question is, I need to implement the autorelease pool's run loop hook that basically runs once every run loop cycle and frees memory. So far guint gtk_idle_add(GtkFunction function, gpointer data); looks the most promising for this purpose. However, being new to this library I would like to get the opinions of those who are more experianced whether there is a better -- or more appropriate place for me to put this code. You're correct, sorta. For starters, please don't use that reference for new gtk2-based code. That book (while excellent) is old and refers to gtk 1.2, which hasn't been maintained for many years. In gtk 2, gtk_idle_add() has been replaced by g_idle_add(). You can look at the glib reference documentation here: http://developer.gnome.org/doc/API/2.0/glib/ I'm not entirely certain that a function added using g_idle_add() will actually run with every main loop cycle. It may only run when there's a certain level of inactivity, and you might want to use g_idle_add_full() to raise the priority higher. However, are you sure this is the best way to do this? Using an idle function will chew through CPU cycles while the application is otherwise idle (really hurts laptop battery performance, for one thing). Another option is a timeout using g_timeout_add(), but the correct approach would be to add a custom GSource that is only invoked when it needs to be. Actually, you might want to poke around in gdk/quartz/ inside gtk+ SVN. I imagine autorelease pools are used in the MacOSX backend; maybe you can find some hints there as to what's best. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Run Loop Memory Management
Replying to myself... On Tue, 29 May 2007 16:29:12 -0700 Brian J. Tarricone wrote: Actually, you might want to poke around in gdk/quartz/ inside gtk+ SVN. I imagine autorelease pools are used in the MacOSX backend; maybe you can find some hints there as to what's best. I was curious, so I looked around. It looks like the gdk-quartz backend allocs a new pool at the top of any function that uses quartz/cocoa functions (which may or may not make use of objects that use autorelease), and then releases the pool at the end of the function. Reading up on NSAutoreleasePool, it looks like they're nestable or stackable, in that the most-recently-created pool will always get used when any object receives an 'autorelease' message. It sounds like a bit of extra work on your part, but clearly someone thought this was the right approach, and it feels much more correct to me than running a cleanup function periodically via the main loop. Are NSAutoreleasePools expensive to create and/or tear down? That's the only argument I could see against this method. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Run Loop Memory Management
On Tue, 2007-29-05 at 16:29 -0700, Brian J. Tarricone wrote:
On Tue, 29 May 2007 18:12:57 -0500 Dan Saul wrote:
Good day, new to the list and GTK+ in general.
I am formerly a Macintosh developer. Currently however I am now working
on Objective C bindings for GTK+. I am currently looking at the
documentation for the run loop which I have found located at
http://developer.gnome.org/doc/GGAD/sec-mainloop.html .
My question is, I need to implement the autorelease pool's run loop
hook that basically runs once every run loop cycle and frees memory.
So far guint gtk_idle_add(GtkFunction function, gpointer data); looks
the most promising for this purpose. However, being new to this
library I would like to get the opinions of those who are more
experianced whether there is a better -- or more appropriate place for
me to put this code.
You're correct, sorta. For starters, please don't use that reference
for new gtk2-based code. That book (while excellent) is old and refers
to gtk 1.2, which hasn't been maintained for many years.
In gtk 2, gtk_idle_add() has been replaced by g_idle_add(). You can
look at the glib reference documentation here:
http://developer.gnome.org/doc/API/2.0/glib/
I'm not entirely certain that a function added using g_idle_add() will
actually run with every main loop cycle. It may only run when there's
a certain level of inactivity, and you might want to use
g_idle_add_full() to raise the priority higher.
However, are you sure this is the best way to do this? Using an idle
function will chew through CPU cycles while the application is
otherwise idle (really hurts laptop battery performance, for one
thing). Another option is a timeout using g_timeout_add(), but the
correct approach would be to add a custom GSource that is only invoked
when it needs to be.
Actually, you might want to poke around in gdk/quartz/ inside gtk+
SVN. I imagine autorelease pools are used in the MacOSX backend; maybe
you can find some hints there as to what's best.
-brian
On Tue, 2007-29-05 at 16:37 -0700, Brian J. Tarricone wrote:
Replying to myself...
On Tue, 29 May 2007 16:29:12 -0700 Brian J. Tarricone wrote:
Actually, you might want to poke around in gdk/quartz/ inside gtk+
SVN. I imagine autorelease pools are used in the MacOSX backend; maybe
you can find some hints there as to what's best.
I was curious, so I looked around. It looks like the gdk-quartz
backend allocs a new pool at the top of any function that uses
quartz/cocoa functions (which may or may not make use of objects that
use autorelease), and then releases the pool at the end of the
function.
Reading up on NSAutoreleasePool, it looks like they're nestable or
stackable, in that the most-recently-created pool will always get
used when any object receives an 'autorelease' message. It sounds like
a bit of extra work on your part, but clearly someone thought this was
the right approach, and it feels much more correct to me than running a
cleanup function periodically via the main loop. Are
NSAutoreleasePools expensive to create and/or tear down? That's the
only argument I could see against this method.
-brian
I thank you for the new reference for me to look at.
NSAutoreleasePool is pretty much exactly what you read up on it being.
My motivation for creating the pool at the start of the event loop and
releasing it at the end is from the source of Apple's NSAutoreleasePool
documentation.
NSAutoreleasePool objects are automatically created and
destroyed in the main thread of applications based on the
Application Kit, so your code normally does not have to deal
with them. The Application Kit creates a pool at the beginning
of the event loop and releases it at the end, thereby
periodically releasing any autoreleased objects generated while
processing events.
Preferably I would be able to write these bindings so that the developer
who would be using them could essentially ignore the presence of the
pools completely as it is in Apple's implentation.
Just to be sure of what you are suggesting;
function ()
{
[create pool];
// Do work.
[destroy pool];
}
Due to the stackable nature of autorelease pools this is completely
possible should the developer need it (and I have used it the past when
I had a function that created and discarded lots of small objects
quickly).
However the event loop based pool would catch anything that was missed
so as to avoid possible memory leaks.
My interpretation may be completely wrong, feel completely free to
correct me.
-- Dan Saul
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Logo (was Re: GTK+ Website Review)
Am Dienstag, den 29.05.2007, 01:31 +0200 schrieb Felix Rabe (public): I wonder where the GTK logo proposal went? I think it would fit quite well in this design. Actually Andreas was doing some work there. I was sent a few ideas and they looked good, but nothing further so far. I might have another proposal based on the first one from Christophe ready in a short while. Those detached, glossy faces look cool, but they also make the logo look fragile. Well, and fragile that's definitly not a term I do or want associate with GTK+... Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Logo (was Re: GTK+ Website Review)
2007/5/29, Mathias Hasselmann [EMAIL PROTECTED]: Am Dienstag, den 29.05.2007, 01:31 +0200 schrieb Felix Rabe (public): I wonder where the GTK logo proposal went? I think it would fit quite well in this design. Actually Andreas was doing some work there. I was sent a few ideas and they looked good, but nothing further so far. I might have another proposal based on the first one from Christophe ready in a short while. Those detached, glossy faces look cool, but they also make the logo look fragile. Well, and fragile that's definitly not a term I do or want associate with GTK+... Perhaps a more metallic (instead of glassy) finish on the plating would be good. You know, make it look like GTK+ is that sturdy and solid, yet professionally finished outer shell to your application logic. Isn't this the way we all look at GTK+ anyway? ;) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
Martyn Russell skrev: Murray Cumming wrote: Hi, Great work Martyn! More importantly, I'd rather not have Gimp Toolkit in the page heading. For me that's a bit like having GNU Network Object Model Environment on a GNOME page. It's not relevant, it's distracting, and it's a bit tacky. It's already mentioned on the About page. This is true, and I would have gone for just GTK+ but it is awfully short for a title. Perhaps something like The GTK+ Project? The GTK+ Project sounds good and much better than GTK+, Gimp Toolkit in my opinion. Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
Le mardi 29 mai 2007, à 11:43 +0100, Martyn Russell a écrit : Jonathon Conte wrote: I'm fairly new to GTK+ development. One of the main things to hinder my adoption of GTK+ was the lack of up-to-date documentation oriented towards those not familiar with GTK+and GLib. Fortunately a very thorough book that breaks down this barrier, Foundations of GTK+ Development by Andrew Krause, was published recently. The book's website is here: http://www.gtkbook.com/ To me, documentation such as this is of the utmost importance when it comes to projects like GTK+. Hopefully you'll consider mentioning the release of this book (and others like it that are published in the future) in the news section of the new GTK+ website or at the very least include it in the documentation section. For what its worth, I have no affiliation with the author or the publisher. I'm just happy that a book to fill this gap was finally written. This is a good point. When I first started out with GTK+ I was looking for a good book, and including it on the site is a good idea. I will do. Can anyone vouch for this book, is it worth the read? Behdad took a quick look at the ebook: http://mces.blogspot.com/2007/05/foundations-of-gtk-development.html Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+/glib versions for GNOME 2.20
Le lundi 28 mai 2007, à 19:05 +0200, Murray Cumming a écrit : On Mon, 2007-05-28 at 16:12 +0200, Vincent Untz wrote: Since the release dates for GTK+ 2.12 and glib 2.14 are now post-GUADEC and it's probably not a good idea to put pressure on the GTK+ team, I believe it's better to stay with GTK+ 2.10/glib 2.12 for GNOME 2.20. If there's no objection, the release team will announce this in a few days. If this happens, I hope that GTK+ will not then be frozen before GNOME 2.21/2.22 development has really started, or else the new GTK+ API will be frozen before it is tested. Synchronization with the GNOME release schedule would be best. Well, I obviously can't speak about GTK+ plans. But here's what I believe is the current status: + GNOME: if GTK+ 2.12 is not out before the end of July, then it's not reasonable to depend on it for GNOME 2.20. While the goal of the GTK+ team seems compatible, there's currently no hard guarantee that GTK+ 2.12 will be released as planned. + GTK+: GTK+ 2.12 is already late, and waiting for the next GNOME unstable development cycle might not be reasonable either. Waiting for GNOME 2.21 means delaying 2.12 for at least 3 months. Like everybody, I can't wait to use GTK+ 2.12 in GNOME. I'd even be okay to push for this happening soon, and I'd be ready to annoy GTK+ developers to get the new GTK+ out in time :-) But I don't want the first 2.12 releases to be buggy because they were rushed. I'd love to hear what's the best option for GTK+. Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Regarding gtk
Please any one help me in getting an rpm for gtk+-2.4. Sashi ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Regarding gtk
On Tue, 2007-05-29 at 17:51 +0530, Sashi Kiran Akella wrote: Please any one help me in getting an rpm for gtk+-2.4. gtk+ 2.4 was released more than three years ago and is unmaintained. are you sure you want to use it? I don't think there's a distribution still shipping a package for that release. you might try rpmfind.net but I doubt you'll find it. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Regarding gtk
you should reply to the list, not to me. On Tue, 2007-05-29 at 18:03 +0530, Sashi Kiran Akella wrote: Emmanuele Bassi wrote: gtk+ 2.4 was released more than three years ago and is unmaintained. are you sure you want to use it? I don't think there's a distribution still shipping a package for that release. you might try rpmfind.net but I doubt you'll find it. I have to use gtk 2.4 or greater version. I want a RPM for that. if you have to use a greater version, you can download RPMs for 2.10.12 which is the latest stable release of GTK+. you can find them inside the repositories for the distribution you are using - without knowing it there isn't much anyone can tell. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Regarding gtk
again: you should reply to the list, not to me. On Tue, 2007-05-29 at 18:13 +0530, Sashi Kiran Akella wrote: Emmanuele Bassi wrote: gtk+ 2.4 was released more than three years ago and is unmaintained. are you sure you want to use it? I don't think there's a distribution still shipping a package for that release. you might try rpmfind.net but I doubt you'll find it. I have to use gtk 2.4 or greater version. I want a RPM for that. if you have to use a greater version, you can download RPMs for 2.10.12 which is the latest stable release of GTK+. you can find them inside the repositories for the distribution you are using - without knowing it there isn't much anyone can tell. can you give me the link please.. no, because I have no idea whatsoever about what kind of distribution you are using, and you cannot use RPMs from different distributions. use http://rpmfind.net to find the right RPM for *your* distribution. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
On 5/28/07, Ana [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 04:42:11PM -0300, Alexandre Moreira wrote:
On 5/28/07, Robert Pearce [EMAIL PROTECTED] wrote:
On Sun, 27 May 2007 16:57:03 +0200 Jonathan wrote:
Hi,
I need to read a large amount of data from a GIOChannel (200K, over
the internet).
So far, I use the gnet library to create the
socket, and then I use the GIOChannel to integrate the read/writing
into the program's loop (a
GTK application)
I use g_io_add_watch(_channel, G_IO_IN, (_imageDataReadyForReading),
this);
to register the callback for data reading.
How can I determine the number of bytes available for reading, so as
not to
block on reading the data?
On the applications where I've used g_io_add_watch it's on a serial port
that I've opened non-blocking. Then my callback I just does:
stat = g_io_channel_read_chars ( source,
tmpbuf, sizeof(tmpbuf), len, err );
If there are less than tmpbuf characters waiting, it fills what it can
and sets len to the actual number. Then I process len bytes. Normally my
tmpbuf is bigger than the longest message I expect, but it seems to work
even if it isn't.
Please anyone correct me if I'm wrong, but...
I guess you should loop until EAGAIN, because you can get some nasty
things if your program is being run on a system where the select (or
poll, or whatever it uses to watch the channels) call returns when the
file descriptor CHANGES its state (ready to read // not ready to
read).
That's what I typically do. something like this:
/* make sure 'source' is non-blocking before entering loop
* below is simplified */
do {
len = 0;
stat = g_io_channel_read_chars ( source,
tmpbuf, sizeof(tmpbuf), len, err );
if( len 0 )
process_data(tmpbuf, len);
} while(stat == G_IO_STATUS_NORMAL len == sizeof(tmpbuf));
Whether it's necessary or advisable to read in a loop like that, I'm not
sure. Depending on certain things, such how long the process_data()
function takes, you may wish to let the main loop run after every time
process_data() is called... in which case you wouldn't use a loop like
the above.
In that case you could create a situation where a client is expecting
for some response from you, but you didn't actually read the request
(because it is lost in the buffer) and therefore each process is
waiting for the other to act.
I think the question here is: if we don't read all available data before
returning to poll/select, will our callback be triggered again so that
we can process the remaining data? Without doing any research, I
believe the answer would have to be 'yes'. To make sure, look at some
source or create a test.
Perhaps I didn't express myself well enough. But I'll try to be clearer now.
That was pretty much what I was talking about: I don't know about
Glib's IO Channels, but there are certain facilities (epoll on linux,
for example, IIRC) which let's the programmer choose which kind of
behavior it'll have: level based (if exists data to be read it will
return with the result) or edge based (whenever it goes from not
having data to be read to having data to be read it'll return with the
result).
What I mean was, depending on what stuff glib uses on certain
architectures, it could behave in a way that the problem I mentioned
would be relevant. As such, I find safer to read stuff until it tells
me it would block (Ok, there is the possibility of a starvation there,
but I don't write this kind of code often enough to worry about it...
I should really give the subject a bit more study/thought.)
Regards,
Alexandre Moreira.
- Ana
___
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: Regarding gtk
On Tue, May 29, 2007 at 03:51:24PM +0300, Emmanuele Bassi wrote: can you give me the link please.. no, because I have no idea whatsoever about what kind of distribution you are using, and you cannot use RPMs from different distributions. use http://rpmfind.net to find the right RPM for *your* distribution. Even better idea than searching rpmfind, inevitably downloading a package the wrong distro [version] and then trying to break your system with it, is to just tell the distro package management tool to install Gtk+ (assuming devel is wanted too): RedHat/Fedora: yum install gtk2-devel SuSE: yast -i gtk2-devel Mandriva: urpmi libgtk+2.0_0-devel PCLinuxOS: apt-get install libgtk+2.0_0-devel Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
Hi,
you never know how much readable data is available until you read it, you
are only ever guaranteed to have one byte of data available for reading
anyway.
In my opinion, the channel should _always_ know how much data is available,
how can it tell that there is nothing there?... Plus, it can't not know the
amount of data it _has_ actually recieved and is buffered ready for me...
Java InputStreams for example have the available() method:
http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#available()
http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#available%28%29
[...] I read the data in 1024 byte chunks [...]
This sounds like a good workaround, which will work well in a watch
callback; I'll use that
Thanks,
Jonathan
On 5/28/07, Armin Burgmeier [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tristan Van Berkom wrote:
On Sun, 2007-05-27 at 16:57 +0200, Jonathan Winterflood wrote:
Hi,
I need to read a large amount of data from a GIOChannel (200K, over the
internet).
So far, I use the gnet library to create the
socket, and then I use the GIOChannel to integrate the read/writing
into the program's loop (a GTK application)
I use g_io_add_watch(_channel, G_IO_IN, (_imageDataReadyForReading),
this); to register the callback for data reading.
How can I determine the number of bytes available for reading, so as
not to block on reading the data?
I dont know if gnet provides anything for this, what I typically
do is:
while (select (fds, readable condition)) {
read (a single byte of data);
}
I don't think this is very efficient because it calls select and read
for a every single byte you want to receive. I normally put the socket
in non-blocking mode and as soon as glib indicates readability I read
the data in 1024 byte chunks until I get EGAIN from recv() (or,
G_IO_STATUS_AGAIN from g_io_channel_read_chars(), respectively).
Greetings,
Armin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGWtx9hOtxKlDYm6cRAg/mAKCFWyGdpMern/YeJ8TrDP1VtJ3j3QCfVEYY
eyd41u6r79MbkumRMGo/WOc=
=mZjC
-END PGP SIGNATURE-
--
Morpheus linux, c'est une question de VI ou de MORE
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
On Mon, 2007-05-28 at 17:26 +0200, Jonathan Winterflood wrote: Hi, you never know how much readable data is available until you read it, you are only ever guaranteed to have one byte of data available for reading anyway. In my opinion, the channel should _always_ know how much data is available, how can it tell that there is nothing there?... Plus, it can't not know the amount of data it _has_ actually recieved and is buffered ready for me... there is a very big difference between knowing the distinctions between: * something and nothing * specifically how much and nothing at all the process that leads to the callback is called as soon as a single byte of data arrives. there might be more data by the time it actually executes. nothing else in the system (except perhaps a device driver) is buffering data for you and then saying (post-facto) we have some stuff. your callback can do that if it wants to offer that kind of service to high level layers of your application/code. Java InputStreams for example have the available() method: http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#available() thats because Java InputStreams are heavily buffered. glib/gtk IOChannels are not, by default. in particular, when you use this callback method, your code is being notified that there is data available long before a Java InputStream would have told that it had information ready. [...] I read the data in 1024 byte chunks [...] This sounds like a good workaround, which will work well in a watch callback; I'll use that the important thing is just to use non-blocking I/O with the channel. t ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
Callbacks on a GIOChannel (as described) are re-entrant!. I know since i have hit this problem. Essentially you must read what you can. If its a socket you would have soimething like bytes_read = recv( fd, ( void * ) ( buffer[ current_byte ] ), expected_size ); current_byte += bytes_received; and then you would exit the function. If current_byte hasn't reached the expected_size, then you just gotta wait till you get called back again. But under no circunstance should you loop in this function. You will not get what you want if you do that. travis miller [EMAIL PROTECTED] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
Thanks for your precisions on where this difference comes from :) I guess g_io_channel_set_flags(_channel, G_IO_FLAG_NONBLOCK, NULL); is good for switching to non-blocking mode. A question arises, though: is it possible that the channel will recieve the last of the data between the time g_io_channel_read_chars returns G_IO_STATUS_AGAIN and the callback exits, and that the callback will not be called again? This would be a really easy way to get stuck waiting for data which is already there, so I'm thinking no, can you confirm this? Thanks a lot, Jonathan On 5/29/07, Paul Davis [EMAIL PROTECTED] wrote: On Mon, 2007-05-28 at 17:26 +0200, Jonathan Winterflood wrote: Hi, you never know how much readable data is available until you read it, you are only ever guaranteed to have one byte of data available for reading anyway. In my opinion, the channel should _always_ know how much data is available, how can it tell that there is nothing there?... Plus, it can't not know the amount of data it _has_ actually recieved and is buffered ready for me... there is a very big difference between knowing the distinctions between: * something and nothing * specifically how much and nothing at all the process that leads to the callback is called as soon as a single byte of data arrives. there might be more data by the time it actually executes. nothing else in the system (except perhaps a device driver) is buffering data for you and then saying (post-facto) we have some stuff. your callback can do that if it wants to offer that kind of service to high level layers of your application/code. Java InputStreams for example have the available() method: http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#available() thats because Java InputStreams are heavily buffered. glib/gtk IOChannels are not, by default. in particular, when you use this callback method, your code is being notified that there is data available long before a Java InputStream would have told that it had information ready. [...] I read the data in 1024 byte chunks [...] This sounds like a good workaround, which will work well in a watch callback; I'll use that the important thing is just to use non-blocking I/O with the channel. t -- Morpheus linux, c'est une question de VI ou de MORE ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
On Tue, 29 May 2007, Jonathan Winterflood [EMAIL PROTECTED] wrote : A question arises, though: is it possible that the channel will recieve the last of the data between the time g_io_channel_read_chars returns G_IO_STATUS_AGAIN and the callbac k exits, and that the callback will not be called again? I don't think so, but given that somebody posted from experience that the callback is reentrant (which I didn't think was possible) perhaps I'm wrong. On the other hand, I've written code that assumes both non-reentrant and that any extra data arriving during the callback will result in it being called again, and I've never hit a problem. My understanding was that the Glib idle task checks the IO channel status and calls the callback if it's ready. Since Glib is non-threaded, this cannot happen during a previous execution of the callback. And since it uses the channel's state rather than any edge events, no data will be lost or ignored simply because the callback was running at the time it arrived. Indeed this must be true if Glib is non-threaded, because the data may arrive at any time and some huge Gtk re-draw may be in progress when it happens. But that's only my understanding as a user so I'd advise you all to ask one of the authors. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
Looking at the glib source here:
glib/giochannel.c
glib/giochannel.h
glib/giounix.c
You can see that, at least on a *nix machine, g_io_channel_read_chars()
calls the c library read() on a file descriptor in the GIOChannel
struct. The segment:
result = read (unix_channel-fd, buf, count);
if (result 0)
{
*bytes_read = 0;
switch (errno)
{
#ifdef EINTR
case EINTR:
goto retry;
#endif
#ifdef EAGAIN
case EAGAIN:
return G_IO_STATUS_AGAIN;
#endif
So, basically, on a Linux (or presumably any *nix like OS) the semantics
of g_io_channel_read_chars() will be roughly the same as POSIX read()*.
You can see that when read() returns -1 ( 0), and the global errno is
set to EAGAIN then G_IO_STATUS_AGAIN is returned.
read() is a system call. Last I checked (a long, long time ago) EAGAIN
is set in the kernel side of the read() call when there is no data in
the buffer to read. Unless I'm mistaken, the only way, in *nix land, to
hear from the kernel again about there being more data, is to call
select(), poll(), or read() again... or to handle SIGIO while using
signal-driven IO (see O_ASYNC in the open(2) man page and*).
The g_io_channels appear to use poll() if a built-in system version is
available, and to emulate poll(), if it's not. So, I believe the
semantics, on *nix at least, more or less amount to:
while( poll() ) /* glib main loop does this */
{
read(); /* your callback does this */
}
I don't see any magic happening that might make it more complicated. If
you're using threads then it does get more complicated, but not in any
way that can't be managed by typical thread management. Also, the
functions that are actually used to do the reading are set as callbacks
in the GIOChannel struct. Default calls the standard unix read(), but
if you're working on someone else's code... you may want to double
check that.
I have never done IO on a win32 or... really on any non-*nix machine,
so my experience is a bit limited. As I understand it though, glib/gtk+
work at making the differences as small as possible. I would not expect
a significant difference in how the g_io_channel interface behaves.
- Ana
* if you haven't already read it: Advanced Programming in the UNIX
Environment, by W. Richard Stevens is a good book to keep around.
On Tue, May 29, 2007 at 10:20:20PM +0200, Jonathan Winterflood wrote:
Thanks for your precisions on where this difference comes from :)
I guess g_io_channel_set_flags(_channel, G_IO_FLAG_NONBLOCK, NULL); is
good for switching to non-blocking mode.
A question arises, though: is it possible that the channel will recieve
the last of the data between the
time g_io_channel_read_chars returns G_IO_STATUS_AGAIN and the callback
exits, and that the callback will not be called again?
This would be a really easy way to get stuck waiting for data which is
already there, so I'm thinking no, can you confirm this?
Thanks a lot,
Jonathan
On 5/29/07, Paul Davis [EMAIL PROTECTED] wrote:
On Mon, 2007-05-28 at 17:26 +0200, Jonathan Winterflood wrote:
Hi,
you never know how much readable data is available until you read
it, you are only ever guaranteed to have one byte of data available
for reading anyway.
In my opinion, the channel should _always_ know how much data is
available, how can it tell that there is nothing there?... Plus, it
can't not know the amount of data it _has_ actually recieved and is
buffered ready for me...
there is a very big difference between knowing the distinctions between:
* something and nothing
* specifically how much and nothing at all
the process that leads to the callback is called as soon as a single
byte of data arrives. there might be more data by the time it actually
executes. nothing else in the system (except perhaps a device driver) is
buffering data for you and then saying (post-facto) we have some
stuff. your callback can do that if it wants to offer that kind of
service to high level layers of your application/code.
Java InputStreams for example have the available() method:
[2]http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#available()
thats because Java InputStreams are heavily buffered. glib/gtk
IOChannels are not, by default. in particular, when you use this
callback method, your code is being notified that there is data
available long before a Java InputStream would have told that it had
information ready.
[...] I read the data in 1024 byte chunks [...]
This sounds like a good workaround, which will work well in a watch
callback; I'll use that
Installing gtk+2.10.12 issues.
Hi all, I am attempting to installing gtk+ (where I have tried 2.10.12 and 2.9.4), it configures fine with the command - # ./configure --prefix=/usr However when I attempt to 'make' the binaries I get the following at the end. config.status: executing gdk/gdkconfig.h commands config.status: gdk/gdkconfig.h is unchanged echo timestamp stamp-gc-h make all-recursive make[3]: Entering directory `/opt/gtk+-2.10.12/gdk' Making all in win32 make[4]: Entering directory `/opt/gtk+-2.10.12/gdk/win32' Making all in rc make[5]: Entering directory `/opt/gtk+-2.10.12/gdk/win32/rc' gdk.rc gdk-win32-res.o gdk.rc: line 3: GTK_ICON: command not found gdk.rc: line 5: VS_VERSION_INFO: command not found gdk.rc: line 6: FILEVERSION: command not found gdk.rc: line 7: PRODUCTVERSION: command not found gdk.rc: line 8: FILEFLAGSMASK: command not found gdk.rc: line 9: FILEFLAGS: command not found gdk.rc: line 10: FILEOS: command not found gdk.rc: line 11: FILETYPE: command not found gdk.rc: line 12: FILESUBTYPE: command not found gdk.rc: line 13: BEGIN: command not found gdk.rc: line 14: BLOCK: command not found gdk.rc: line 15: BEGIN: command not found gdk.rc: line 16: BLOCK: command not found gdk.rc: line 17: BEGIN: command not found gdk.rc: line 18: VALUE: command not found gdk.rc: line 19: VALUE: command not found gdk.rc: line 20: VALUE: command not found gdk.rc: line 21: VALUE: command not found gdk.rc: line 22: VALUE: command not found gdk.rc: line 23: VALUE: command not found gdk.rc: line 24: VALUE: command not found gdk.rc: line 25: VALUE: command not found gdk.rc: line 26: END: command not found gdk.rc: line 27: END: command not found gdk.rc: line 28: BLOCK: command not found gdk.rc: line 29: BEGIN: command not found gdk.rc: line 30: VALUE: command not found gdk.rc: line 31: END: command not found gdk.rc: line 32: END: command not found make[5]: *** [gdk-win32-res.o] Error 127 make[5]: Leaving directory `/opt/gtk+-2.10.12/gdk/win32/rc' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/opt/gtk+-2.10.12/gdk/win32' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/opt/gtk+-2.10.12/gdk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/gtk+-2.10.12/gdk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/gtk+-2.10.12' make: *** [all] Error 2 WHY is it trying to execute the gdk.rc file, rather than putting it into /usr/lib/pkgconfig ? Thank you in advance. Craig. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
