Re: Ann: GtkCanvas 0.1

[Andy Tai <atai ece ucsd edu>]

Simply, this canvas offers the GnomeCanvas on a more stand alone basis, making
the functionalities available to gtk+ programs which do not use GNOME.

There were people requesting this from time to time.

It can also serve as a stepping stone to facilitate moving the canvas into gtk+,
although this is up to the gtk+ maintainers.

It does not offer any more than what GnomeCanvas already has, but since
the Gnome Canvas offers a rich set of services useful for generic GUI programs,
making them available to plain gtk+ is a good thing.  Thus I want to make clear
I do not want to fork development but to follow GNOME closely.

Ideally, commonly desired GUI features  should be in gtk+. Gtk+ will get fatter,
but there will be less number of libraries to worry about, and a richer system 
"toolbox" means more code reuse. More of GNOME's UI services should go into gtk+
(my 2 cents). It may be hard to define what are desirable features, but the 
canvas is definitely one.

GNOME is competing with KDE/Qt.  GNOME is not competing with gtk+. Even if
there are gtk+ applications that do not use GNOME features, the more GNOME 
gives to gtk+, the more compatible these gtk+ applications are with GNOME.
That is a win-win situation.

> One thing that your announcement doesn't make clear, and which I'm
> curious about, is what motivated this.  You say that this is intended
> to "behaves identically to the GnomeCanvas widget, with the same APIs,
> except the API names are changed from gnome_canvas to gtk_canvas".
> However, you never explain why this would be desirable.  Surely
> there's more to this than 's/gnome_/gtk_/g', but you don't say what
> more this port offers.
> 
> Care to explain?
> 
> -- John Kodis.
> 

-- 
Li-Cheng Tai (Andy Tai)                       e-mail: atai@atai.org

Free Software:  the software by the people, of the people and for the people.
Develop! Share! Enhance! Enjoy!