Re: [gtk-list] Re: Lack of gtk_menu_delete function




I still don't understand what reason there is -NOT- to have a
gtk_menu_remove function.  I'll drop it, though, that's fine.

Jeremy Weatherford
xidus@xidus.net
http://xidus.net/

On 27 Jan 2000, Owen Taylor wrote:

> 
> Jeremy Weatherford <xidus@xidus.net> writes:
> 
> > I think you're missing the point... even if there is a way to do that
> > (which still isn't useful in my case since I don't want to keep up with
> > the GtkMenuItem pointers), why shouldn't there be a gtk_menu_remove
> > function, similar to gtk_clist_remove?  And what about gtk_menu_get_item?
> > It seems to me like breaking encapsulation to go in and remove/destroy the
> > menu item yourself when it's supposed to be owned by the GtkMenu.
> 
>  GList *list = gtk_container_children (menu);
>  GtkWidget *menuitem = g_list_nth (list)->data;
>  g_list_free (list);
>  gtk_widget_destroy (menuitem);
> 
> If you want... but usually is just is easy to keep up with
> the GtkWIdget * pointers for the children as is it is to
> keep up with the numerical indices. Almost all of GTK+
> works this way, gtk_clist_remove() is pretty much an
> exception.
> 
> A lot of widgets don't even have a real natural order for
> their children. Think about GtkTable.
> 
> And no, it doesn't break the encapsulation to destroy the menu
> item - you aren't just randomly freeing the memory -
> gtk_widget_destroy() is a call that says "remove me from my
> parent, and ask everybody else to drop references to me."
> 
> Regards,
>                                         Owen
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 



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