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
