Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

2010-09-29 Thread Kristian Rietveld
On Sep 23, 2010, at 10:56 AM, Tristan Van Berkom wrote: > So to help stay on track without straying too too much, these > are (my perceived) reasons for the said refactoring work: > > - Code sharing: A good refactoring of cell layouting logic >into some classes that can be (more) easily reus

Replacement of gdk_window_clear{_area}

2010-09-29 Thread Guillaume Desmottes
Hi guys, gdk_window_clear{_area}() have been removed in GTK+3. I understand from http://git.gnome.org/browse/gtk +/commit/?id=6c971ac47948c8e2b85d710b8496d442cd572840 that I should use Cairo directly instead but didn't find any example code. I think it's worth adding an example in the migration d

Re: [PATCH] [RFC] Add g_*_deinit() API

2010-09-29 Thread Ole André Vadla Ravnås
On Wed, Sep 29, 2010 at 3:49 PM, Matthias Clasen wrote: > On Wed, Sep 29, 2010 at 9:46 AM, Ole André Vadla Ravnås > wrote: >> I'm currently working on adding API to GLib/GObject/GIO for explicitly >> cleaning up statically allocated resources, like TLS keys, threads, >> handles, heap blocks, etc.

Re: [PATCH] [RFC] Add g_*_deinit() API

2010-09-29 Thread Matthias Clasen
On Wed, Sep 29, 2010 at 9:46 AM, Ole André Vadla Ravnås wrote: > I'm currently working on adding API to GLib/GObject/GIO for explicitly > cleaning up statically allocated resources, like TLS keys, threads, > handles, heap blocks, etc. > > This is clearly not useful to regular GLib-based applicatio

[PATCH] [RFC] Add g_*_deinit() API

2010-09-29 Thread Ole André Vadla Ravnås
I'm currently working on adding API to GLib/GObject/GIO for explicitly cleaning up statically allocated resources, like TLS keys, threads, handles, heap blocks, etc. This is clearly not useful to regular GLib-based applications where GLib has the same life-time as the host process itself, so such