Re: GNOME Namespace Management - ARC & GNOME

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 backwards compatibility.

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
proactively prevented.

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

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 will
become a standards body with the same sort of clout as w3c or,
but that will probably take time, and more community dedication towards
defining/following standards.

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 ..

thanks -mike

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