Re: [gtk-list] Re: change box orientation in runtime?



From: Antonio Campos <acampos@ceronet.com>
> 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:
> 
> alias_widget=gtk_widget_alias(widget);
> gtk_container_add(GTK_CONTAINER(newparent),alias_widget);
> 
> 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
> parents...)

    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...)

    Yours,

    Emmanuel





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]