Re: g_object_copy()

[Russell Shaw <rjshaw iprimus com au>]

Murray Cumming Comneon com wrote:
> > If deep-copy is not implemented in Gtk/Gdk, shouldn't it be 
> > added? It would make bindings to python which has deep-copy 
> > ability more transparent.
>
> What would happen when you deep-copied a GtkWidget? If the source was shown,
> would the copy immediately be shown? If the source was in a container, would
> the copy be in the same container? What if that container could only have
> one child widget? Should it get all the signal handler connections too? It
> gets silly.

Well, the source could be a dialog window containing a whole bunch of widgets
like buttons and drawing-areas in various v/hboxes. I assume Gtk only gets to
know it when you do something like:

  GtkWidget *dialog=gtk_dialog_new(void);
...
<construct>
...
  gtk_widget_show_all(dialog);

Now, i should be able to do a deep copy like so:

  GtkWidget *dialog2=g_object_copy(GTK_WIDGET(dialog));

Now i could show this independent widget in a visual widget editor,
modify various sub-widgets contained in dialog2, then:

  gtk_widget_destroy(dialog);

  dialog=dialog2;

  gtk_widget_showall(dialog);

and repeat the cycle, modifying the widgets with the editor.

The deep copy consists of generating a new instance struct of a GtkWidget and
copying over any data fields. Data fields that are themselves pointers to
other objects, are generated by calling the deep copy() method for those
objects. Also, the deep copy() function of the GtkWidgets parent (GtkObject)
is called. GtkObject then does a similar copying of its instance data fields
and calls its parent (GObject) copy() function.

The above is for the instance structs of the objects. The class structs
can just be copied with g_memdup() if they're just full of method pointers.

This means the duplicate widget would have the same callbacks. However, in
the hypothetical visual widget editor, these pointers could be edited to
point to other new callbacks.

> For Gdk GObjects, most of them are shared resources so there isn't much
> point in copying them instead of refcounting them - that would just be less
> efficient.
>
> It doesn't make sense for many things, and that's why there is no deep-copy.
> Some types do have copy functions, but the meaning is very specific to the
> type.

Maybe it doesn't make sense for things that are limited to one or two
things on the PC hardware, but anything that is suitable for interactive
editing by the developer should be deep-copyable.

There are many visual and non-visual widgets that are interactively/visually
editable in something like the borland c++ builder gui.

To me, no deep-copy seems like the missing half of the implementation.