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

[Marius Vollmer <mvo zagadka ping de>]

Miguel de Icaza <miguel@nuclecu.unam.mx> writes:

> You have to understand that one of our goals (speaking for the GNOME
> project) is to make a consistent desktop.

The canvas widget should not (and does not as far as I now) set the
policies that lead to a consistent desktop.  There might be some
things that need to be defined uniformly about the way a program uses
a canvas, but these things should not be hard-wired in the lower level
canvas code itself.  That is, GNOME might want to provide a
GnomeCanvasClock canvas item that interacts with user preferences and
thus displays the time in a GNOME conformant manner.  But the basic
display list management and event dispatching clearly belongs in the
toolkit.
 
> Now, if we keep the Canvas in the GNOME libraries, people will install
> the GNOME libraries because it has got a cool canvas.  They will
> eventually figure out that the gnome libraries include other candies
> hiding there that facilitates their life.  Then, programmers will
> slowly start using those utility functions in the gnome-libraries in
> their own applications: and thus help make their programs consistent
> with the rest of the GNOME desktop.

That's a very weak argument.  If GNOME has that low of a profile than
much more serious things have gone wrong.  I don't think that GNOME
gets too little press or that the people who matter are too confused
about what it is or what it can do.

> Now, independently of that fact (the fact that we want to increase the
> user base of the gnome-libraries), the Gnome Canvas has some features
> that depend on Gdk_Imlib, which is not part of Gtk yet.

Gdk_Imlib exists to solve the problem of loading and displaying
images.  Gtk can make good use of that, too.  Besides, why is it
called Gdk_Imlib and not Gnome_Imlib?
 
> Yes, the code can be splitted: one part of the Canvas goes in Gtk, the
> other goes in Gnome.  But I do not want to see the code splited.

The canvas is designed to be modular.  Anyone can write its own
specialized canvas items.  That is a great and winning feature of it.
So the split does not need to be artificial.  Splitting widgets among
several packages is well supported by the Gtk object system.  We
should make good use of this for modularizing this great evolving mass
of software.

Now, sticking most of the basic canvas items in Gtk and leaving only
the image and font stuff in libgnomeui would certainly be artificial
and not a good modularization.  The reason is that low-level image and
text/font support belong to the domain of the toolkit.

You say that X11 font rendering sucks and you want to solve that.  So,
I infer from this that Gtk is already at too *high* a level for the
kind of code you want to write.  This stuff ought to get fixed at the
XServer/xlib level.

So, in my opinion, the abstraction that the canvas widget provides
belongs into the toolkit.  It is on the same level as the abstractions
provided by GtkTree, GtkList, GtkText, etc.  Fixing the deficiencies
of X11 image and font support belong to an even lower level.

> Federico and I discussed this before the canvas was implemented: we
> choose to call it a Gnome widget, because none of his previous
> widgets for the GNOME project gave the Gnome libraries a larger user
> base (the handle box and the toolbar).  People did not see any
> reason to use the Gnome libraries at all.  So, we decided to make
> the new widgets, Gnome widget that would stay on the gnome-libraries
> and thus encourage people to look at more things they could use.

Sorry, Miguel, this is marketing bs.

I know, I haven't been of any help lately and the only thing I'm doing
now is making a lot of waves about minor things (much more so on the
gtk lists).  But I want this recent and exciting movement towards the
desktop to be as strong as possible.  I want us to `win' for the right
reasons.  The stuff we do now should be able to outlive X11, Linux,
Unix, C, electron-computers, carbon-based lifeforms, Star-Trek re-runs
and 2 digit year fields.

Sorry, got a little excited there.  Anyway, I think that attention to
details is no wasted effort.  It is very tempting to pile feature atop
of feature, but the hard wood grows slow.

> On top of that, I want to add some form of font rendering and
> postscript printing to the Canvas.  Of course, this will include some
> default font setup and some default font policies, and those will be
> part of the Gnome framework.  

The policies would be enforced by the style mechanism of Gtk.