Re: deprecation patch


As background to see if we're on the same page, I think a feature in
GTK should generally either:

 - be potentially useful in nearly any kind of application; be
   expected to be used in a large percentage of apps, say > 20% 
   at least

 - or, alternatively, be something that isn't necessarily used so 
   often, but is extremely hard to implement as an add-on package.

Other stuff should generally go in an add-on library of some kind,
subject to good judgment of course.

The value to removing code that doesn't meet these criteria is to
reduce API bloat, which is not a matter of disk space. API bloat has
two bad impacts:

 - it makes GTK much harder to maintain, e.g. converting 
   GtkArg->GParamSpec is much harder if you have lots of extra
   widgets, converting legacy widgets to Pango, etc.

 - it makes GTK harder to learn and use; the documentation is 
   more overwhelming, there are more features than you need. 

Also, to explain deprecation: it means "this feature is discouraged
for newly-written code." Most of the deprecated widgets will likely be
moved to some kind of separate shared object from libgtk eventually,
and then removed only when/if no one is using them. Deprecated doesn't
mean the feature is immediately removed. (Only GtkText/GtkTree are
disabled by default, the others must be explicitly disabled with 

Tim Janik <timj gtk org> writes:
> ok, i first want to see rationales for marking the following things
> deprecated:
> > 	* gtk/gtklist.h: Mark deprecated

All new code should use GtkTreeView instead. I'm defining "deprecated"
as "newly-written code should not use the feature."
> > 	* gtk/gtkpacker.h: Mark deprecated

You can always use hbox/vbox to get the same effects, so this widget
is useless, and indeed no one uses it that I know of.

> > 	* gtk/gtktipsquery.h: Mark deprecated

I don't know of anyone using this either; and we should support a more
versatile help system later, so eventually it should IMHO be
replaced. Normally we wait to have a replacement before doing a
deprecation, but most people seem to be rolling their own contextual
help setup rather than using this one, so I think it should
immediately be noted that we are planning to replace it.

> > 	* gtk/gtkinputdialog.h: Mark deprecated

Far too special-purpose for GTK, basically not used.

> > 	* gtk/gtkvruler.h: Mark deprecated
> > 	* gtk/gtkhruler.h: Mark deprecated
> > 	* gtk/gtkruler.h: Mark deprecated

Too special-purpose, only say 2% of apps use it.

> > 	* gtk/gtkgamma.h: Mark deprecated
> > 	* gtk/gtkcurve.h: Mark deprecated

These were developed for the GIMP which Owen has mentioned probably
doesn't even use them anymore. Very specific to particular
applications, not general-purpose at all. Very little-used.

Special-purpose widgets would ideally be distributed as small
standalone components (a la Delphi), but since we don't have a good
system for that, they belong in libs such as GtkExtra or GAL. (Not
even libgnomeui, IMO libgnomeui should have the same requirements as
GTK, i.e. general-purpose stuff only.)


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