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