Re: [gtk-list] Re: change box orientation in runtime?
- From: "Emmanuel DELOGET" <logout free fr>
- To: <gtk-list redhat com>
- Subject: Re: [gtk-list] Re: change box orientation in runtime?
- Date: Mon, 14 Feb 2000 14:59:29 +0100
From: Antonio Campos <firstname.lastname@example.org>
> Emmanuel DELOGET wrote:
> > Ooops. Maybe I've just missed the point, but what is the interesting
> > thing in having multiple parents for a widget ?
> The interesting thing is that your code could be reduced to:
> and that you could use the same widget in many places without having to
> create/duplicate it many times. This is a feature that GTK doesn't have and
> probably will never have. Although it is not a fundamental feature, sometimes
> one misses it.
> It's like having simbolic links in the directory structure. You can reference
> the same file from many points without noticeable increase of disk space.
> In the same manner, having "simbolic links" or "pointers" to other widgets
> could be useful sometimes (and it would use less memory when one has the same
> complex widget in many different parents).
I shouldn't be a good idea to create "widget symbolic links", since
it should say that any modification of any alias will change the
behavior of all other aliases. Assuming the widget cloner would
be used in a MDI application (can't see other use of it) this will
just say that every instance of your MDI child window will contain
the same thing. Not sure it is really interesting.
And there are a couple of thing that must be change from one alias
to the other : the size of the widget may not be the same, the
GdkWindow MUST not be the same, and so on...
> (Now that I think of it, we will end with the same problems that appear with
> simbolic links, that is, dangling (is it said so?) simbolic links and circular
> references, maybe avoided by not letting to have an alias to an alias...).
> How about a:
> GtkWidget *gtk_widget_clone(GtkWidget *widget); ?
> This could behave "like" copy contructors on C++. As we have gtk_*_new and
> gtk_widget_destroy, gtk_widget_clone could clone the widget and call the clone
> function of every child of it recursively.
Well. It will just alloacate the same memory chunk as the normal _new func.
Since you probably don't want to create a "symlink widget", you'll have
to copy everything into the widget. So it's probably better to have
a copy constructor in your application code (then you'll know what you
want to copy).
> I think it could be quite easy to implement, although i don't know if it could
> be very useful. (perhaps when you have to include the same widget in many
> different parents, you just could clone it and add the clones to the
Not so easy. If you really want a gtk_widget_clone() then you
modify all the widget class structure to add a virtual copy
constructor. Than you have to implement this copy ctor (it cannot
be done with a memcpy() call).
And this will lead to some not needed complexity in the GtkWidget
structure (list of parent that are attached to a list of GdkWindow,
an alias_id member which will have to be tested each time you
want to operate on a window, and so on...)
] [Thread Prev