Re: Abstract string properties with getter/setter functions
On Fri, 2007-09-28 at 16:24 -0500, Federico Mena Quintero wrote: By the way, this is a *TERRIBLE* idea. I don't remember why I wrote the code that way. Please don't follow that broken pattern. if I may guess, it's because otherwise you'd have to unref the returned widget, which would be a bit odd in the gtk+ context. it also happens in the ::get_filter() method of GtkFileChooser (and GtkRecentChooser), for the same reason: the implementation owns the filter and it's just returning a pointer to it. when you call gtk_tree_view_get_model() you don't unref the returned GtkTreeModel because the tree view widget holds a reference on the model itself, as it happens in this case: [In the file chooser it works because the GtkFileChooser implementation always holds a reference to the preview widget.] yep. it's like returning a private string as a const-gchar*. in these cases work because it has been documented and it's more or less consistent with the rest of the gtk+ API. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On 9/28/07, Federico Mena Quintero [EMAIL PROTECTED] wrote:
On Thu, 2007-09-20 at 08:34 +0200, Raffaele Sandrini wrote:
Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack
done there is somehow possible with objects it is not with strings.
GtkWidget *
gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser)
{
GtkWidget *preview_widget;
g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL);
g_object_get (chooser, preview-widget, preview_widget, NULL);
/* Horrid hack; g_object_get() refs returned objects but
* that contradicts the memory management conventions
* for accessors.
*/
if (preview_widget)
g_object_unref (preview_widget);
return preview_widget;
}
By the way, this is a *TERRIBLE* idea. I don't remember why I wrote the
code that way. Please don't follow that broken pattern.
[In the file chooser it works because the GtkFileChooser implementation
always holds a reference to the preview widget.]
I'm pretty sure that it's my code (or, at least, the first usage; it's
been cut-and-pasted a couple of times within that file). It's pretty
much forced by:
- The way GtkFileChooser is set up internally using properties to
forward between the different implementations of GtkFileChooser -
Widget, Window, and the default implementation - without writing lots
of per-property manual chaining code.
- The desire to have the public GtkFileChooser wrappers look like
most of GTK+ interface where a getter for a constituent widget
doesn't ref (think gtk_widget_get_child(), even)
And it is pretty safe considering the semantics of the particular
situation; if an application sets a preview widget, the file chooser
has to hold onto it, and return exactly that preview back out later.
But that's only by consideration of the particular situation. It isn't
generalizable across all object properties, and definitely not all
properties, and even more so not across all getters.
It's much easier to write things if you always get a new reference from
accessors.
It's the only universal pattern. It's not the convenient pattern for
using code from C, unfortunately. You see this a lot ... when you take
an automatically generated interface (COM, CORBA, etc), and use it
from C, you have a lot of tedious dereferencing. But there's no way
around that.
- Owen
[ And yes, I was completely horrified to to see anybody referring to
that code as an example to generalize ]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Thu, 2007-09-20 at 08:34 +0200, Raffaele Sandrini wrote:
Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack
done there is somehow possible with objects it is not with strings.
GtkWidget *
gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser)
{
GtkWidget *preview_widget;
g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL);
g_object_get (chooser, preview-widget, preview_widget, NULL);
/* Horrid hack; g_object_get() refs returned objects but
* that contradicts the memory management conventions
* for accessors.
*/
if (preview_widget)
g_object_unref (preview_widget);
return preview_widget;
}
By the way, this is a *TERRIBLE* idea. I don't remember why I wrote the
code that way. Please don't follow that broken pattern.
[In the file chooser it works because the GtkFileChooser implementation
always holds a reference to the preview widget.]
It's much easier to write things if you always get a new reference from
accessors.
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, 2007-09-19 at 19:20 +0200, David Nečas (Yeti) wrote: On Wed, Sep 19, 2007 at 06:48:25PM +0200, Raffaele Sandrini wrote: Since we do not see a way around this (yet) and we could not find an example with strings in another project. I'm asking here if there is a nice way around this. i'm really not sure i understand your problem here... We need a way to steal the string from the property i.e. to make sure its not a copy of the original. The property does not need to be actually backed by a string. It just has to accept a string in the setter and produce a string -- a new string -- in the getter. For instance GtkCellRendererText has properties background wich is a string (write-only though) and background-gdk which is a GdkColor. They are views of same thing and what is this actual internal representation is none of your business. To sum it up, you cannot steal something that is owned by you from the begining. Properties generating things are a complete different story. We have to treat them separately. Properties transferring ownership will need to be specially marked in Vala. Raffaele ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, 2007-09-19 at 19:17 +0200, Tim Janik wrote:
BTW: There are equal issues with properties returning objects only there
you can add a hack into the getter unrefing the object before returning
it. This is not applicable with strings.
this is not applicable with objects. as soon as you called unref(obj),
the object will be destructed and gone, you can't hand it on any further,
obj will point to freed memory.
in some rare cases and if you're lucky, the object might stay around
a little longer because someone else could coincidentally hold another
reference. but this can't be relied upon.
a well formed getter implementation might do:
return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL));
once you g_object_unref() this return value, it'll be instantly vaporized
with
a crushing noise (if you hooked up pulseaudio via destruction emission
hooks ;)
You can check the ref count first.
erm, no. that's at least not a clean solution, ref counts may increase and
decrease at any point in time for random reasons (caches, garbage collection
algorithms, etc...), even from concurrently running threads without holding
the GDK lock.
Take a look at the GtkFileChooser interface
there this hack is used several times. (and annotated as such)
hm, not here:
$ fgrep ref_count gtk/gtkfilechooser*.c
$
Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack
done there is somehow possible with objects it is not with strings.
GtkWidget *
gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser)
{
GtkWidget *preview_widget;
g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL);
g_object_get (chooser, preview-widget, preview_widget, NULL);
/* Horrid hack; g_object_get() refs returned objects but
* that contradicts the memory management conventions
* for accessors.
*/
if (preview_widget)
g_object_unref (preview_widget);
return preview_widget;
}
All we need from you is either a solution or the statement that this is
not possible with gobject properties ;).
i don't quite get what you're trying to achive.
but if efficiency is your only concern, i do think that you
can spare a string copy by using g_object_get_property()
instead of g_object_get(). it just still will be internally
copied when it's passed around as a GValue (g_object_get
just does two copies alltogether, the second of which needs
to be freed by tha caller).
That might be true but does not help here. We use getters/setters all
through Vala for several reasons including the ability to embed a
getter/setter in any kind of C expression and due to speed concerns with
GValue. The memory convention of getters/setters is to return weak
references.
Therefore we think, using virtual setter/getter for virtual/abstract
properties would be a solution, but I'd hoped you have a more simple
one ;).
cheers,
Raffaele
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Thu, 20 Sep 2007, Raffaele Sandrini wrote:
On Wed, 2007-09-19 at 19:17 +0200, Tim Janik wrote:
erm, no. that's at least not a clean solution, ref counts may increase and
decrease at any point in time for random reasons (caches, garbage collection
algorithms, etc...), even from concurrently running threads without holding
the GDK lock.
Take a look at the GtkFileChooser interface
there this hack is used several times. (and annotated as such)
hm, not here:
$ fgrep ref_count gtk/gtkfilechooser*.c
$
Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack
done there is somehow possible with objects it is not with strings.
GtkWidget *
gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser)
{
GtkWidget *preview_widget;
g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL);
g_object_get (chooser, preview-widget, preview_widget, NULL);
/* Horrid hack; g_object_get() refs returned objects but
* that contradicts the memory management conventions
* for accessors.
*/
if (preview_widget)
g_object_unref (preview_widget);
this code is not peeking at preview_widget-ref_count, it
just always unrefs because by getting it always owns a returned reference.
return preview_widget;
}
All we need from you is either a solution or the statement that this is
not possible with gobject properties ;).
i don't quite get what you're trying to achive.
but if efficiency is your only concern, i do think that you
can spare a string copy by using g_object_get_property()
instead of g_object_get(). it just still will be internally
copied when it's passed around as a GValue (g_object_get
just does two copies alltogether, the second of which needs
to be freed by tha caller).
That might be true but does not help here.
well, you still fail to say *why* this does not help
or poses a problem for you.
We use getters/setters all
through Vala for several reasons including the ability to embed a
getter/setter in any kind of C expression and due to speed concerns with
GValue. The memory convention of getters/setters is to return weak
references.
this is *not* a convention of getters in glib/gtk programs.
like i said in my first email, some getters return peeked contents,
some return duped/referenced contents.
technically, it is *not* possible to implement all getters as peeking
functions because return values may be constructed on the fly.
so any convention that demanded only peeking getters would be in error
because it'd be technically impossible to implement thoroughly.
(maybe what you're saying is that this is a convention for vala
getters... but then, that's something you'd very badly have to fix,
because it is *not* implementable for all C programs, even beyond
glib/gtk programs.)
cheers,
Raffaele
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Abstract string properties with getter/setter functions
Hi there,
While implementing abstract properties in Vala we encountered a problem
regarding string properties with getter and setter functions:
public interface Test.MyIface {
public abstract string text { get; }
}
A getter function of an abstract string property looks like:
char* test_my_iface_get_text (TestMyIface* self) {
char* value;
g_object_get (G_OBJECT (self), text, value, NULL);
return value;
}
Property accessors in Vala always return weak references. This leads to
a memory leak in the calling function of the getter.
We want property accessors to return weak references so just redefine
the accessors to return a strong reference is only a last-resort-option.
Since we do not see a way around this (yet) and we could not find an
example with strings in another project. I'm asking here if there is a
nice way around this.
BTW: There are equal issues with properties returning objects only there
you can add a hack into the getter unrefing the object before returning
it. This is not applicable with strings.
cheers,
Raffaele
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On 9/19/07, Raffaele Sandrini [EMAIL PROTECTED] wrote:
Ok i see there is need to clarify things.
On Wed, 2007-09-19 at 17:53 +0200, Tim Janik wrote:
On Wed, 19 Sep 2007, Raffaele Sandrini wrote:
Hi there,
While implementing abstract properties in Vala we encountered a
problem
regarding string properties with getter and setter functions:
public interface Test.MyIface {
public abstract string text { get; }
}
A getter function of an abstract string property looks like:
char* test_my_iface_get_text (TestMyIface* self) {
char* value;
g_object_get (G_OBJECT (self), text, value, NULL);
return value;
}
Property accessors in Vala always return weak references. This leads
to
a memory leak in the calling function of the getter.
i'm not sure what you mean with weak/strong references when it
comes to strings. in C, pointers can be handed out which point to
0-terminated char arrays that represent strings. there's on reference
counting for strings in C as there is in C++. per convention,
for glib/gtk programs, some such string pointers must be g_free()-ed
once.
With strong/weak references is talk about ownership. If some code needs
ownership over a string it will dup the string.
callers of getters have to free the returned string in C.
for glib/gtk programs, if the caller doesn't need to free the string,
the return value should be G_CONST_RETURN gchar*.
That's right since the getters do not claim ownership they do not need
to free the strings. The problem is the caller assumes a weak reference
and will dup it if it needs ownership.
The point here is that we are talking about *abstract* properties i.e. i
do not know whether the implementation uses a static string or not. I
have to call g_object_get whether i want to or not.
We want property accessors to return weak references so just redefine
the accessors to return a strong reference is only a
last-resort-option.
requesting that all string return types should be const char* is
technically
not possible, because some strings need to be constructed in getters.
people who don't want to deal with these memory allocation issues (const
strings vs. caller-needs-to-free strings) should stay away from C, maybe
even C++, and use python, java, scheme, other-garbage-collected
languages.
Vala needs to deal with this issues to enable users who do not want to
deal with it an easy life.
Since we do not see a way around this (yet) and we could not find an
example with strings in another project. I'm asking here if there is a
nice way around this.
i'm really not sure i understand your problem here...
We need a way to steal the string from the property i.e. to make sure
its not a copy of the original.
It's difficult to imagine how one would enforce this, given that the
implementation has complete freedom to copy the string. The GOB string
getters always returned an allocated string. I'm afraid you may have to
resort to that in general.
BTW: There are equal issues with properties returning objects only
there
you can add a hack into the getter unrefing the object before
returning
it. This is not applicable with strings.
this is not applicable with objects. as soon as you called unref(obj),
the object will be destructed and gone, you can't hand it on any
further,
obj will point to freed memory.
in some rare cases and if you're lucky, the object might stay around
a little longer because someone else could coincidentally hold another
reference. but this can't be relied upon.
a well formed getter implementation might do:
return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL));
once you g_object_unref() this return value, it'll be instantly
vaporized with
a crushing noise (if you hooked up pulseaudio via destruction emission
hooks ;)
You can check the ref count first. Take a look at the GtkFileChooser
interface
there this hack is used several times. (and annotated as such)
All we need from you is either a solution or the statement that this is
not possible with gobject properties ;).
Forgot to post the bug against Vala:
http://bugzilla.gnome.org/show_bug.cgi?id=472904
Hope things are more clear now.
cheers,
Raffaele
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, Sep 19, 2007 at 06:48:25PM +0200, Raffaele Sandrini wrote: Since we do not see a way around this (yet) and we could not find an example with strings in another project. I'm asking here if there is a nice way around this. i'm really not sure i understand your problem here... We need a way to steal the string from the property i.e. to make sure its not a copy of the original. The property does not need to be actually backed by a string. It just has to accept a string in the setter and produce a string -- a new string -- in the getter. For instance GtkCellRendererText has properties background wich is a string (write-only though) and background-gdk which is a GdkColor. They are views of same thing and what is this actual internal representation is none of your business. To sum it up, you cannot steal something that is owned by you from the begining. Yeti -- http://gwyddion.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
