Re: Announcing: Project Ridley


I think this is a great plan, and will do much to benefit GNOME's ISV
story.  I notice that the Project Ridley page doesn't make any mention
of a11y.  Obviously moving/renaming widgets from libraries like libegg
and libgnome* will affect libgail, which I think should be considered part
of Project Ridley.  Are there plans to merge libgail with libgtk+ as
a part of this project?

Even with Project Ridley, there will still likely be some other libraries
that are needed to write a GNOME application.  GConf, gnome-vfs,
gnome-mime-data, and at-spi.  To make a truly solid ISV story, beefing
up these modules so that the same care towards interface stability
and quality interface documentation as glib/GTK+ is also important.
This might not be a part of Project Ridley, but should be done in
parallel with it.

Also, I worry that Project Ridley might send mixed messages to ISV's.
Although people have been clear to say that ABI won't be broken,
so the old libraries will be supported, you also point out that libraries
like libgnome* are undermaintained, buggy (and lack quality
documentation I would add).  Does this mean that ISV's should wait
until Project Ridley is out before they should consider writing a
"GNOME" application, or that using the soon-to-be-deprecated
interfaces will also supported by the GNOME community?

If ISV's writing to the deprecated libraries will continue to
be supported, then Project Ridely does not really resolve the ISV
problem by itself.  Simply deprecating interfaces should not mean
that deprecated functions are no longer supported.  If the GNOME
community intends to have a solid ISV story and to continue
supporting the deprecated interfaces, then it should also be
important to ensure that interfaces are stable and well
documented, even if they are deprecated.

On the other hand, the GNOME community might feel that this is
too much work, and that ISV's really shouldn't be using
interfaces in the buggy and undermaintained modules.  This
would mean that ISV's would currently be restricted to using
only the currently solid libraries (perhaps glib/gtk/pango/
atk) until Project Ridley is released.

Regardless of which way the GNOME community is going, it
would be good if the intention is communicated more clearly
to ISV's.  There should be a website somewhere at letting ISV's know what they should
be using and how Project Ridley will impact them.

I think renaming GTK to 3.0 doesn't make sense if ABI is not
broken.  It doesn't really make sense to bump the number to
3.0 unless the plan is also to remove all deprecated functions
from the library.  Bumping the minor number should be sufficient
if ABI compatibility is maintained.  Bumping the major number
should be a signal that the library is ABI incompatible, not
just that the library has a "big change".


Now that GTK+-2.8.0 is out, the GTK+ team would like to announce Project


The primary goal of Project Ridley is to cut down on the number of
problem libraries that are part of the GNOME platform.  We propose to do
this by moving functionality into GTK+, wherever it makes sense.  These
libraries are generally small, undermaintained, and buggy.  They have an
unclear purpose (such as libgnome and libgnomeui), are copied-and-pasted
around (such as libegg) or would benefit by being in GTK+ (libgnomeprint
and libgnomeprintui.)

We have been sending confusing messages to ISVs, free software and
otherwise, as to what they should be using to develop applications.  By
cleaning up these widgets and deprecating the libraries, we can make it
much simpler for developers.  To emphasize the 'consolidated platform'
message, we are considering to call the GTK+ version incorporating the
results of Project Ridley GTK+-3.0.

The secondary goal is to bring people currently working on the platform
together in a coordinated effort.  We would love to bring more people
into the GTK+ team and get people working on the platform again.


Anyone who's currently writing code for platform tasks.  As we're
targeting GTK+ for this work, it has to be written in C.


We put up a a wiki page detailing the tasks we'd like to accomplish at:

A few of the widgets have people actively looking at them, though all
could use help.  There are tasks of all sizes, ranging from simple
cleanup and renaming of an existing widget to designing a cross-platform
printing api to writing a kick-ass, fully-functioning cairo-based

We don't want to create a new list for this effort, and would like
followup mail to be sent to gtk-devel-list gnome org
desktop-devel-list mailing list
desktop-devel-list gnome org

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