Re: Abstract string properties with getter/setter functions

2007-09-29 Thread Emmanuele Bassi
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

2007-09-29 Thread Owen Taylor
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

2007-09-28 Thread Federico Mena Quintero
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

2007-09-20 Thread Raffaele Sandrini

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

2007-09-20 Thread Raffaele Sandrini
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

2007-09-20 Thread Tim Janik
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

2007-09-19 Thread Raffaele Sandrini
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

2007-09-19 Thread Michael Lawrence
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

2007-09-19 Thread Yeti
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