Re: Are Out-of-Tree Widgets Second-Class Citizens?

On Mon, 28 Sep 2009, Morten Welinder wrote:

> A long time ago GTK+ was a collection of widgets.  If you did
> not like what you had, you could grab the source of one of the
> widgets and change it to do whatever you needed it to do.
> This is increasing no longer the case -- in-tree Gtk+ are now
> special and programmed using a different API than out-of-tree
> widgets.  This is wrong!

Morten may have stated his point a bit abrasively, but I share his

Simple GTK apps can do all they need to do using the standard GTK
widgets.  But more complex apps (Gnumeric, in Morten's case;
gretl, in mine) find need for some widgets that are fairly close
in design space to standard ones but that require inflections that
are not supported by the standard API (and that are probably too
application-specific to be worth supporting in the standard API).

Up till now we have been able, as Morten says, to copy gtkfoo.c
and gtkfoo.h out of the GTK tree, change the indentifiers, make
our modifications, and be happy.  But with GSEAL as it stands,
we're screwed.  Our custom-modified widget code won't compile any

I'm not sure if the solution Morten advocates -- namely, applying
the GSEAL principle internally -- is the best one, although maybe
it is.  But anyway, I think this is something the GTK developers
need to consider seriously.  Extensibility on the app-developer
side is a substantial desideratum of a GUI toolkit, to be weighed
against (or possibly reconciled with) the desire of the toolkit
developers to seal everything off and no longer be bothered by us
pesky app developers.

Allin Cottrell

Allin Cottrell
Department of Economics
Wake Forest University

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