Re: [gtk-list] Re: GNOME widgets --> GTK+ widgets

[Havoc Pennington <rhpennin midway uchicago edu>]

On Tue, 25 Aug 1998, Shawn T . Amundson wrote:
> 
> Actually, the only real reason is that the people working on GNOME
> want GNOME to gain in name recognition and also want everyone to use
> GNOME and code for it.  Nothing wrong with it, but it's not technical.
>

This may be (I don't know), but I don't agree it's the only real reason. I
think the reasons I listed are also part of it.
 
> If truely the only reason 'GnomeCanvas' isn't 'GtkCanvas' is because
> of gdk_imlib not being integrated into the GTK+ dist, I think that could
> be resolved somewhat easily.
>

I don't know about GnomeCanvas; but how, to pick an example I wrote, would
you include GnomeDialog in Gtk? All it is is policy and config-loading.
There's really nothing there that's not Gnome-specific. Plus it isn't a
very clean or general interface, it's pure syntactic sugar - ugly,
compared to most of Gtk, but very nice to have IMO.

Or the desktop entry edit widget - it's to edit Gnome desktop entries, so
that would be dumb to have in Gtk. Plus it's a hack, but it works for the
panel/gmenu for now until someone has time to improve it. I don't
think you Gtk guys would appreciate random experimental features
(gnome-lamp, gnome-app-util) or temporary hacks in Gtk. 

Other widgets like GtkLayout are clearly meant to end up in Gtk, and it
beats me why they aren't.
 
> Widgets that do require some gnome enhancements could be derived from
> the base GTK+ widgets.  That would help generalize the widgets anyway.
> 

Sure, I think that would be cool. But it's not true in every case.

> There are lots of reasons that programmers may not want to code for
> GNOME. 

The most common one I've heard (really the only one) is "too many library
dependencies" or "bloat."

> Widgets need not be the reason why people code for GNOME, but
> instead it should be the session management, config file routines, and
> general integration into the environment. 

Sure. Also *policy* and the resulting *configurability*. You can make a
plain Gtk app look and behave in a dozen different ways; a Gnome widget
can have a single API which looks up which of the dozen ways the user
wants, from a GUI-configured config file. 

> Or, they might not want to
> just because people try to bully them into it. ;-)
> 

Oh, give me a break. ;-) Email != bully. Anyone can code for pure Gtk, I
just think they're setting themselves up for additional effort.

> Besides, above you imply that functions that should be in glib get
> put into libgnome and we all know widgets in libgnomeui which would
> be better placed in GTK+.  

I don't imply it, I say it. I agree. As far as I'm concerned those things
should be moved. 

For me deciding where to put widgets, it's been important that it's not
controversial to impose policy in Gnome; it's understood that the GUI is
supposed to be consistent. Gnome is not supposed to be a general-purpose
toolkit.  And there is a GUI-configurable config library, and most of the
stuff I've written has depended on that. 

> And eventually they might move around to where they should have been
> originally.  Well, that's the instability the people are talking about. 

Yes, they should be moved probably.

I never meant to say some things shouldn't be moved, I am just saying that
there are a lot of reasons they haven't been. Also that until they are
moved gnome-libs offers a good bit more functionality than Gtk alone,
perhaps at the expense of programmer choice about UI and larger code size
and with the benefit of user choice about UI, consistent interface,
environment integration, and more programming convenience. 

It is probably a good thing on the whole to keep them separate, because
there is a genuine tradeoff between functionality and code size. 
gnome-libs allows us to add functionality and policy without hearing
people whine about bloating Gtk and library dependencies; there is
certainly a group of people that like Gtk because it's small. Another
design goal difference is that Gtk often keeps the traditional Unix way
and this makes it hard to do certain things. I would cite gtkrc as an
example; I guess in theory you could write a graphical config utility for
it, but I sure don't want to. Yet it is the standard Right Way to do
things from a certain perspective. 

If the libraries were merged completely I bet you'd have to have a flame
war about every new feature. That said I'm 100% on your side that some of
the code could be moved to Gtk.

Havoc