Re: [gtk-list] Re: Freeing data connected to a widget via signals...

[Antonio Campos <acampos ceronet com>]

Owen Taylor wrote:

> Matthew D Allen <s2mdalle@titan.vcu.edu> writes:
>
> > >take a look at
> > >
> > >  guint       gtk_signal_connect_full         (GtkObject *object,
> > >                                               const gchar *name,
> > >                                               GtkSignalFunc func,
> > >                                               GtkCallbackMarshal marshal,
> > >                                               gpointer data,
> > >                                               GtkDestroyNotify
> > >destroy_func,
> > >                                               gint object_signal,
> > >                                               gint after);
> > >
> > >where GtkDestroyNotify is
> > >
> > >  void        (*GtkDestroyNotify)             (gpointer data);
> >
> > Worked like a charm, thanks.  (Well, after a bit of experimenting, anyway)
> > It's always nice to locate and fix those 400KB memory leaks.  :)  (aaaah!)
> >
> > Now pretty much the only other memory issue I have with GTK+ is how and
> > when it chooses to allocate new memory for the purpose of returning a
> > value.  I.e. if you do gtk_editable_get_chars() it returns dynamically
> > allocated memory, which you have to g_free() after you use, but with some
> > other widgets, you really shouldn't free the result of functions that
> > return the widget's "contents" because instead of newly allocated memory,
> > it's just returning one of the widgets fields.  I tend to think of it
> > conceptually, as in, "this function returns malloc'd memory when you ask
> > for the contents of the widget, and here's a similar function (different
> > widget) that doesn't return malloc'd memory (or at least not memory you
> > should free)".  Conceptually, they're both functions that "return
> > something that's 'in' the widget".
> >
> > Any chance of those types of things ending up in the RDP?  (generally,
> > when I free the return value of a GTK+ call when I'm done with it, I only
> > did it because I checked out the gtk+ source and saw that it was
> > g_strdup'ing a value on return.  Something like
> > return(g_strdup(widget->field));
>
> Look at the GTK+ RDP entries for gtk_editable_get_chars() and
> gtk_entry_get_text(). If this information isn't in the RDP for
> a (documented) xfunction where it is relevant, than please let us know.
>

Now there's a "bad" function in gtklabel.c:

void
gtk_label_get (GtkLabel *label,
               gchar   **str)

that doesn't malloc the memory for *str.

But that's easy to resolve.
We have gtk_label_set_text and gtk_label_get.
Well, simply add:

gchar *gtk_label_get_text (GtkLabel *label)

(returning a malloced (gchar *) of the internal label that the widget
has)

in gtklabel.c, and you get 4 improvements in 1 change:

1) Better naming consistency: You have: gtk_label_set_text and
gtk_label_get_text (Better IMHO).
2) You return malloced strings which is better (see below).
3) Better naming consistency with gtk_entry_get_text (that also returns
the text
as a malloced string).
4) You still are backwards-compatible with the old gtk_label_get.

Of course, the use of gtk_label_get should be discouraged in every
Tutorial,
Book, (GGAD has this), about GTK+.

I'm going to post a bug about this.

>
> The basica policy is that all new GTK+ functions added will duplicate
> strings on return, but there are still old legacy functions we can't
> change.
>

Indeed this recommendation should form part of the GTK Tutorial about
creating
new widgets.
When I issue a gtk_whateverwidget_get_whateverwidgetproperty, the widget
should
allways return malloced memory, because if not I can change directly a
property
of the widget (throught a pointer for example). And widget properties
should be
handled only internally by it. (Imagine a user freeing the pointer to
the label
that the gtk_label_get functions gives him. That's a sure SIGSEGV).

>
> Regards,
>                                         Oewn
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null