Re: [gtk-list] Re: gtk_args_collect & gnome--

[Tim Janik <timj gtk org>]

On Sun, 23 Aug 1998, Federico Mena Quintero wrote:

> >  Actually, Federico, what about renaming the GnomeCanvas to GtkCanvas,
> >  putting it into the Gtk+ distro, making gtk_object_new/set fit to
> >  stand in for gnome_canvas_item_new/set and then do away with the
> >  latter?
> 
> I don't have an opinion regarding moving the GnomeCanvas to Gtk.
> However, note that it requires Gdk_Imlib, which Gtk doesn't.
> 
> I am not using plain gtk_object_set() because gnome_canvas_item_set()
> does a little bit of additional work -- it queues proper redraws of
> the canvas.  Maybe this should go into the set_arg method for canvas
> items, I'm not sure.

the redraw queueing should definitively go into the item specific
set_arg functions as well as item->canvas->need_repick = TRUE;.
then you can use the normal gtk_object_set() functions for items as well.
getting gtk_object_new(,...) to work for the canvas items is a little bit
trickier. you'd basically need to reimplement the parent<->child mechanism
for canvas groups, i.e. you need to
have public gnome_canvas_group_add and gnome_canvas_group_remove functions
that can be overridden just as it works for GtkContainer, then support a 
::parent (or ::group) arg for the items and a ::child (or ::item) arg for
the groups. the stuff that item_post_create_setup() does would then go into
gnome_canvas_group_add(), which is used to implement either of the ::parent
or::child argument.

regarding the GnomeCanvas->GtkCanvas move, we can (probably _will_ in the
future) have seperate subdirs in the Gtk distribution for additional,
not-so-standard widgets, that may even require additional libraries to
be installed, in order to get properly built. candidates for this are the
gtktty/gtkterm widgets and also the canvas.

if people really want to move the canvas into Gtk, this should probably
be done asap, since the namespace trade s/gnome/gtk/ will soon introduce
a big a hurdle, once the canvas is widely used.
another option would be to have a true gnome-widgets module, which could
hold widgets that do not really rely on gnome-specific stuff, like e.g.
the the gnome_config_* API or somesuch. but then again, the question "why
weren't these implemented for Gtk in the first place?" would always remain...

> 
>   Federico
> 

---
ciaoTJ