Re: GNOME Namespace Management - ARC & GNOME
- From: Mike Hearn <mike navi cx>
- To: Brian Cameron Sun COM
- Cc: sun-sac-foss-ext Sun COM, desktop-devel-list gnome org
- Subject: Re: GNOME Namespace Management - ARC & GNOME
- Date: Tue, 14 Dec 2004 09:52:09 +0000
Brian Cameron wrote:
One thing that makes GNOME a little easier to deal with is that
most Sun customers do not build their own applications using the
GTK+/GNOME stack. Further, Sun discourages customers from
depending on (linking against, for example) the GTK+/GNOME stack
since the GNOME community doesn't provide strong enough stability
That's a shame but understandable. What do you recommend your customers
use? Presumably not Java, as that has a similarly spotty record of
Since Sun itself provides most of the core GNOME
applications with Solaris, most breakages that have occurred to
date have not been noticed by customers. Still, there is the
risk that a customer will start depending on them and will want
Sun to fix bugs that cause their applications to break when
they upgrade to a newer version of GNOME. Therefore, Sun is
wanting to work more closely with the community to try and
better ensure that such breakages are identified, fixed, and
Great! Obviously that's good not only for Sun but for everyone in the
Linux/BSD world building on GNOME as well.
This is something that ARC is currently struggling with. The GNOME
stack is perhaps the most significant aspect of Solaris that is not
developed internally at Sun. Other exceptions include projects like
Mozilla and the Xserver. However, most of these projects take
stability more seriously than the GNOME project and make more of an
effort to follow standards/specifications that are well developed by
organizations like w3c and X.org.
It used to be the case that X was very stable, but that was primarily
because as a project it was stagnant. Since the fork and move to Xorg,
development has picked up and some breaking changes have been made. For
instance I think old X libs have been dropped (libXaw?) and the new ARGB
visuals are known to break some apps. You may wish to keep an eye on that.
For Mozilla I guess you're not counting the XPCOM APIs Mozilla exposes
which historically haven't been stable at all (see the Adobe SVG Viewer
fiasco). In Gecko itself compliance with W3C specs is good, or at least
always has been for me. Serious rendering regressions happen but seem rare.
Perhaps freedesktop.org will
become a standards body with the same sort of clout as w3c or X.org,
but that will probably take time, and more community dedication towards
Let's hope so. Right now it's more of a collaboration forum than a
formal standards body. Specs can and do change, sometimes old versions
actually disappear from the website entirely, for instance the old
vFolder text file spec.
Although the file system interfaces that GNOME depends on are somewhat
stable, they are poorly defined and are not well organized. Sun feels
that proper definition and good organization are part of what makes
interfaces stable. So Sun would like to see improvements in these
areas before Sun would agree that they are generally stable.
OK, that seems to make sense.
> /etc/gimp, External: how is this directory which is internal to an image
> editor considered a stable interface?
The gimp system-wide rc files are stored here. Changes that a system
administrator makes to such files to affect the behavior of gimp
shouldn't break from release-to-release. Or do you disagree?
No I don't disagree, I just didn't realise that upgrading without
changing file formats was classed as an external interface.
What happens if the config system changes but migration code is in place
so that the old config is moved to the new config on first run. Is that
classed as a breaking change or not for such interfaces?
User applications should be able to integrate their gconf data to these
file locations and expect them to work from release to release.
OK, I don't know enough about gconf to comment here. I thought it was
internal but I can see the schema files in there, so I guess not.
It is the directory on Solaris where we let users know that they can
install gtk-doc's that they wish to generate.
OK. It'd be nice to have that formalised somewhere.
Sun considers glib, pango, gtk and libglade to be the GNOME modules that it
supports with the highest level of guarantee against breakage. Since this
is a GTK+ interface, we have to support it more than we support other
parts of GNOME.
Yes, I was referring to the GTK+ developers. Is the gtkrc file
considered as stable as the library API itself? I don't know. It almost
certainly is but I never saw an explicit guarantee ..
] [Thread Prev