Re: [gtk-list] Gnome/GtkCanvas (was Re: gtk_args_collect & gnome--)

Owen Taylor writes:
 > Federico Mena Quintero <> writes:
 > > >  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.
 > GnomeCanvas should be moved to GTK+ because it is an extremely
 > neat and useful widget that can be useful in any GTK+ program
 > and doesn't have any relation to a desktop environment.
 > The image item type (as I understand it the only one that
 > depends on gdk_imlib) can be left in GNOME for now. Perhaps
 > in the future GTK+ will come with something like gdk_imlib -
 > at that point it can be moved into GTK+ as well.

I am all for moving GnomeCavas to to GtkCanvas (that is, if I get a
vote <grin>), but I think it may be a bad idea to break it up with
part in Gnome and part in Gtk+.  Especially since it seems (to me)
that for most uses the image item type is the most important (most
used) one in GnomeCanvas.

As for the problem of gdk_imlib dependency: How about merging
gdk_imlib into gdk *BUT* include a ``--with-gdk-imlib'' flag in the
config (which would be on be default)?  Then if someone doesn't want
the added code size of gdk_imlib (and all widgets which depend on it,
like GtkCanvas would) they don't have to have it.

I am no expert with GTK+'s documentation, err, source code, so I don't
know if this compile time switch would be feasible or not, but it
seems that it should work.


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