Paul Davis wrote:
> On Thu, Jan 7, 2010 at 4:10 PM, Erik de Castro Lopo
> wrote:
> > Simon McVittie wrote:
> >
> >> Debian's GLib packages compile GLib twice; the normal copy with
> >> the recommended hidden-visibility settings ends up in /usr/lib in the
> >> normal
> >> libglib2.0-0 binary pack
On Thu, Jan 7, 2010 at 4:10 PM, Erik de Castro Lopo
wrote:
> Simon McVittie wrote:
>
>> Debian's GLib packages compile GLib twice; the normal copy with
>> the recommended hidden-visibility settings ends up in /usr/lib in the normal
>> libglib2.0-0 binary package (which other packages depend on), b
Simon McVittie wrote:
> Debian's GLib packages compile GLib twice; the normal copy with
> the recommended hidden-visibility settings ends up in /usr/lib in the normal
> libglib2.0-0 binary package (which other packages depend on), but the package
> also builds extra copy that is refdbg'able, and i
On Thu, 07 Jan 2010 at 08:59:38 +1100, Erik de Castro Lopo wrote:
> Does that mean I have to recompile glib in order to use this tool?
Debian's GLib packages compile GLib twice; the normal copy with
the recommended hidden-visibility settings ends up in /usr/lib in the normal
libglib2.0-0 binary pa
Tomeu Vizoso wrote:
> While I agree that would be good to have something with a lower
> barrier,
Indeed.
Currently, to debug memory leaks in code that uses GTK+ we have the
widely known and used tool Valgrind which throws up many thousands of
false positives or a GTK+ specific tool like RefDbg,
On Wed, Jan 6, 2010 at 22:59, Erik de Castro Lopo wrote:
> Tomeu Vizoso wrote:
>
>> RefDbg is useful in these cases.
>
> I've had a look at RefDbg. On configure I get:
>
> ***
> * WARNING: glib >= 2.6 found. refdbg will not work *
>
Tomeu Vizoso wrote:
> RefDbg is useful in these cases.
I've had a look at RefDbg. On configure I get:
***
* WARNING: glib >= 2.6 found. refdbg will not work *
* WARNING: unless you use it with glib compiled with *
* WARN
On Jan 5, 2010, at 4:45 PM, Erik de Castro Lopo wrote:
> Tomeu Vizoso wrote:
>
>> RefDbg is useful in these cases.
>
> Where can I get some more info on that?
Google knows all:
http://www.google.com/search?q=refdbg
first hit:
http://refdbg.sourceforge.net/
--
Doing a good job around here
Tomeu Vizoso wrote:
> RefDbg is useful in these cases.
Where can I get some more info on that?
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
gtk-devel-list mailing list
Sven Herzberg wrote:
> Can you please post this program, so people can proofread/reproduce what
> you post?
I now have two separate small programs which display this behaviour.
The code can be retrieved use the Bzr revision control tool using:
bzr get http://www.mega-nerd.com/Bzr/gtk-leak-
On Tue, 2010-01-05 at 09:57 -0500, Paul Davis wrote:
> On Tue, Jan 5, 2010 at 8:51 AM, Morten Welinder wrote:
> > You probably need to end with something like this
>
> useful, but that doesn't explain the dependency on the number of
> GtkWindows created, does it?
Generally, GdkWindow objects won
Hi Erik,
Am Dienstag, den 05.01.2010, 23:32 +1100 schrieb Erik de Castro Lopo:
> I have written a small test program that can create independent toplevel
> windows based on a command line parameter. Currently these top level
> windows contain nothing more than a GtkLabel widget and destroy
> thems
On Tue, Jan 5, 2010 at 8:51 AM, Morten Welinder wrote:
> You probably need to end with something like this
useful, but that doesn't explain the dependency on the number of
GtkWindows created, does it?
___
gtk-devel-list mailing list
gtk-devel-list@gnome
On Tue, Jan 5, 2010 at 13:32, Erik de Castro Lopo wrote:
> Hi all,
>
> I have written a small test program that can create independent toplevel
> windows based on a command line parameter. Currently these top level
> windows contain nothing more than a GtkLabel widget and destroy
> themselves usin
You probably need to end with something like this
(from Gnumeric):
{
GSList *displays;
gdk_flush();
while (g_main_context_iteration (NULL, FALSE))
;/* nothing */
displays = gdk_display_manager_list_di
15 matches
Mail list logo
