Re: weird gtk_timeout_add ...

[Havoc Pennington <hp redhat com>]

Peter Rottengatter <peter rottengatter de> writes: 
> Ah, I didn't know that. The docs do not mention that. So it's because
> precision isn't there, only accuracy is.

Well, the issue isn't really glib/gtk, it's just an issue with poll()
or the kernel or non-realtime systems or something.
 
> > Normally if you call foo_new() to create something, you later need to
> > call the corresponding foo_unref() or foo_destroy().
>
> Hmmm. What I wondered: I have an optionmenu that has some menu attached.
> I need to change a lot of the menu, so I build a new one, and attach it 
> with gtk_option_menu_set_menu. I'd guessed that would create a leak, so I 
> looked for some way to get rid of the old menu properly. I think, calling
> gtk_option_menu_remove_menu prior to attaching the new one does the job.
> But I'm still not sure if something needs to be freed. Do I need to
> foo_destroy the thing ?

Ah. I left out the important detail of the "floating" flag for
GtkObject. GtkObject memory management is documented in both 1.2 and
2.0 docs, differently each time, so maybe one is clearer:

  http://developer.gnome.org/doc/API/gtk/gtkobject.html 
  http://developer.gnome.org/doc/API/2.0/gtk/gtkobject.html

The 2.0 stuff should apply to 1.2, just ignore the existence of
GObject and s/g_object_ref/gtk_object_ref/
 
> I haven't found a single point in the GTK 1.2 docs where it's pointed
> out that the result of some function needs to be freed after use.

2.0 docs are a lot more comprehensive, and in many cases document
functions that exist in 1.2. For functions that exist in both the
behavior won't have changed between versions.

> > , in GTK 2.0 the ones that
> > should not be freed are given as "const char*" instead of "char*"
>
> That could be a helpful rule. With the only flaw of not being applicable
> to GTK 1.2 ;-)

We don't promise not to make mistakes, but we do attempt to fix them,
at least some of them. ;-)

Havoc