GNOME Interface Review
- From: Brian Cameron <Brian Cameron Sun COM>
- To: gnome-hackers gnome org
- Subject: GNOME Interface Review
- Date: Fri, 07 Apr 2006 15:11:32 -0700
GNOMEies:
Over the past few months, the Sun GNOME team has been working with the
Sun ARC (Architectural Review Committee). Our goal in this process is
to better define the set of GNOME interfaces that can be recommended
for use to integrate with the GNOME desktop. It explains which
interfaces Sun is recommended to its users, and why. It also discusses
the ARC committee's overall opinion of the stability of the GNOME
stack. Hopefully this is interesting to people, and this mail list
seems an appropriate forum for GNOME interface discussion.
With this case, we have tried to define a reasonable subset of
interfaces which allow users to realistically integrate with the
desktop without exposing interfaces that are not well documented or
clearly Stable (e.g. following Platform API/ABI rules). The approach
follows what many current ISV's (Adobe, Real, GIMP, etc.) are using.
In other words, depend only on GNOME Platform Interfaces GTK+ and
below and specific FreeDesktop specs required for reasonable desktop
integration. Read the interface table in the attached opinion for
more detail. It would be interesting to hear if others have differing
perspectives on this.
I have also attached the Functional Specification that we are currently
working on to explain differences between 2.12 and 2.14. This second
document is still a work-in-progress and will likely take a month or
two to be finalized into another Opinion, which I can share when the
process completes. Our goal is to go through this process for each
GNOME stable release, to better capture and document the specific
differences to intefaces recommended for use.
It would be especially useful if anyone had any information to share.
Do these documents reasonably cover a minimal set of interfaces needed
to integrate with the GNOME desktop? Are there additional interfaces
that should be considered Stable integration points? The opinions
expressed in these documents are Sun's, so it would be useful to hear
if there are any inaccuracies you notice.
There has been some past discussion about the general need to better
clarify what subset of GNOME interfaces should be recommended for use
outside of the GNOME consolidation. If this sort of documentation is
generally useful to the GNOME community, I would be happy to integrate
it however appropriate with general GNOME documentation.
Thanks,
Brian
Sun Microsystems Systems Architecture Committee
Subject: GNOME For Nevada
Submitted by: Brian Cameron
File: LSARC/2005/734/GNOME-Nevada-Opinion.txt
Date: March 27nd, 2006
Committee: John Fischer (written by Brian Cameron), TBD
Product Approval Committee: Solaris PAC
1. Summary
This case updates Solaris Nevada to include an updated and more modern
GNOME desktop, helping Sun to remain competitive with other desktop
platforms.
This project updates the next Minor release of Solaris to GNOME 2.12.
This release includes updates to components such as Evolution, Gaim.
Some new components have been added to the release, such as cairo, evince,
and D-BUS. Full details of new features can be found in the GNOME
Release Notes [19].
This project also announces a few components as being Obsolete in a Patch
release of Solaris and removes them in a Minor release of Solaris. These
components are Obsolete because the GNOME community no longer ships them
or suitable replacements have been established.
2. Decision & Precedence Information
The project is approved as specified in reference [1], but as modified by
the required technical changes listed in Appendix A below. The project
may be delivered in a Minor release of Solaris.
The GNOME project is an example of where Solaris has an increasing
dependency on external projects. Based on past experience with GNOME,
this case intends to set precedents on how external projects are reviewed
and managed. The goal being to improve the relationship between Sun and
the open software communities Sun depends upon.
Precedent includes:
1) This case intends to provide an example of how external project
documentation can be used to navigate the ARC process.
2) An opinion crafted to include issues that need to be communicated
back to the external community. This includes removal of the "Sun
Proprietary/Need to Know" labels in the ARC documentation, so that
information can be more easily shared with the external community.
To make it easier for people in the Free and Open Source community
to parse this document, sections not relevant to the external
community are identified as follows:
#ifndef OPEN_SOURCE_COMMUNITY
[...]
#endif /* OPEN_SOURCE_COMMUNITY */
3) An expectation that the project team will work with the external
community to resolve issues highlighted in the opinion and report back
progress in a future review.
4) This case shows how one project has mapped external community stability
claims to Sun claims
5) Closer integration with the OpenSolaris ARC process.
3. Interfaces
This interface table was compiled with the assistance and approval of
Joe Kowalski.
Interfaces Exported
Interface Name Classification Comment
---------------------- ----------------------- -------------------------
Stable GNOME Platform interfaces. Refer to GNOME-Nevada-interfaces.txt
for more detail on specific interface additions
-----------------------------------------------
ATK 1.10.3 Stable [ref 4, sec 3] Was 1.7.3
(LSARC 2001/650)
glib 2.8.4 Stable [ref 4, sec 3] Was 2.4.1
(LSARC 2001/384)
GTK+ 2.8.8 Stable [ref 4, sec 3] Was 2.4.1
("")
pango 1.10.1 Stable [ref 4, sec 3] Was 1.4.1
("")
at-spi 1.6.6 Stable [ref 4, sec 3] Was 1.6.2
(except include/libspi/Accessibility.h) (LSARC 2001/650 - listed
incorrectly as "External"
in LSARC 2004/713)
Other Stable GNOME Interfaces
-----------------------------
GDM 2.8.0.7
Configuration Stable Updated stability
[ref 4, sec 2] [11]
GNOME package names Stable As defined in
LSARC 2004/713
/usr/sfw/share/applications
Stable Location for .desktop files
for /usr/sfw components.
/usr/share/gnome Stable GNOME 2.0 directory for
external applications
supported for backwards
compatibility.
/usr/bin/update-desktop-database
Stable Utility for updating the
desktop menu database.
Refer to 4.14.
/usr/bin/gtk-update-icon-cache
Stable Utility for updating the
icon cache. Refer to 4.14.
GNOME Platform interfaces that have API documentation
-----------------------------------------------------
libglade 2.5.1 Contracted External [ref 4, sec 3] Was 2.3.6
Downgraded from Evolving
due to expected
Deprecation.
(LSARC 2001/384)
GConf 2.12.1 Contracted External Was 2.6.1 (LSARC 2004/713)
ORBIT2 2.12.4 Contracted External Was 2.10.1 (LSARC 2004/713)
gnome-vfs 2.12.2 Contracted External Was 2.6.0 (LSARC 2004/713)
gtk-doc 1.4 Contracted External Updated stability.
libIDL 0.8.6 Contracted External Updated stability.
libbonobo 2.10.1 Contracted External Was 2.6.0 (LSARC 2004/713).
Includes bonobo-activation.
libbonoboui 2.10.1 Contracted External Was 2.6.0 (LSARC 2004/713)
libgail-gnome 1.1.2 Contracted External Was 1.1.0 (LSARC 2004/713)
libgnome 2.12.0.1 Contracted External Was 2.6.0 (LSARC 2004/713)
libgnomecanvas 2.12.0 Contracted External Was 2.6.0 (LSARC 2004/713)
libgnomeui 2.12.0 Contracted External Was 2.6.1.1 (LSARC 2004/713)
FreeDesktop specifications used by GNOME
----------------------------------------
Base Directory
Specification Stable New [ref 4, sec 1]
Icon Theme
Specification Stable New [ref 4, sec 1]
Desktop Menu
Specification Stable New [ref 4, sec 1]
Shared MIME Info
Specification Contracted External New [ref 4, sec 1]
/usr/bin/update-mime-database
Contracted External Utility for updating MIME
database. Refer to 4.14.
Other Interfaces
----------------
at-spi include/libspi/Accessibility.h interface
Contracted External The auto-generated CORBA
bindings in at-spi are not
Stable.
GNOME Desktop Libraries Contracted External All non-Platform
library interfaces.
GNOME Platform Libraries
Missing API Docs Contracted External audiofile, esound,
libart_lgpl, intltool
GNOME Desktop Apps Contracted External All GNOME applications.
pkg-config 0.16.0 Contracted External (LSARC 2002/747)
The following GNOME Desktop applications are listed to reference their
previous ARC case
-----------------
GAIM 1.5.0 Contracted External (LSARC 2005/489)
gnome-pilot 2.0.13 Contracted External (LSARC 2005/414)
gnome-panel 2.12.2 Contracted External (LSARC 2001/384)
Evolution 2.4 Contracted External See separate interface
table below.
The following GNOME Desktop interfaces are Obsolete
---------------------------------------------------
nautilus-media Obsolete Removed from GNOME in
the community codebase.
ggv Obsolete Replaced by evince in
the community codebase.
gpdf Obsolete Replaced by evince in
the community codebase.
/usr/bin/ggv Obsolete Symlink to evince, or
appropriate viewer. For
backwards compatibility
/usr/bin/gpdf Obsolete Symlink to evince, or
appropriate viewer. For
backwards compatibility
Evolution Interfaces Exported
Interface Name Classification Comment
---------------------- ----------------------- -------------------------
Evolution GUI Contracted External LSARC/2003/298
Evolution CLI Contracted External LSARC/2003/298
Evolution Data Server Project Private Evolution backend process
for managing contacts and
calendars.
Exchange Connector Project Private Evolution exchange
connector for communicating
with MS Exchange servers.
Sun ONE Connector Project Private Evolution Sun One
Connector.
Evolution alarm Project Private Evolution Alarm Daemon.
notify A Program for giving users
alarms according to
Evolution calendar.
Evolution alarm notify
will stay alive after the
termination of Evolution
main process.
Evolution-address Project Private Evolution addressbook
book-export export tool
Ximian-connector-setup Contracted External A traditional tool for
setting up Exchange
accounts
gconf keys Contracted External LSARC/2003/298. How
Evolution stores its
configurations.
Camel Messaging Project Private LSARC/2003/298. The
foundation Library of the
mail component. Loosely
based on the design of
Sun's JavaMail? API. It
provides an abstraction
layer through which mail
messages are accessed.
Shell Contracted External LSARC/2003/298, A container
component to manage various
components of Evolution.
Mailer Contracted External LSARC/2003/298, A full
feature e-mail client. To
view mail messages in
various style. Provide
filter and vfolder,
encryption. Embedded html
mail composer.
Addressbook Contracted External LSARC/2003/298. The
addressbook backend (PAS)
in the Wombat includes
support for both LDAP
servers and local contact
databases.
Calendar Contracted External LSARC/2003/298. Allows the
user to manage his to-do
lists and appointments on
calendar servers or locally
Importing tools Contracted External LSARC/2003/298. To
facilitate migration from
other applications.
LDAP schemas Project Private LDAP Contact configurations
and attributes.
PALM Sync conduit Contracted External GNOME-pilot conduit
definitions, files for
syncing data between
Evolution and Palm Devices
PALM Sync conduit Contracted External Exported APIs for
GNOME-pilot, libraries
for syncing data between
Evolution and Palm Devices
Package Names Stable LSARC/2003/298. Package
names for Evolution.
Key installed files Contracted External LSARC/2003/298. All the
files installed and created
by Evolution
Key Navigation map Contracted External Keyboard shortcuts for
Evolution
libsoup Project Private LSARC/2003/298. An HTTP
library implementation in C
libgtkhtml Project Private LSARC/2003/298. A light-
weight HTML rendering,
printing, and editing
engine
gnuTLS Project Private LSARC/2003/298. A library
which provides a secure
layer, over a reliable
transport layer. Currently
the gnuTLS library
implements the proposed
standards by the IETF's TLS
working group
aspell Project Private LSARC/2003/298. GNU spell
checker
aspell-en Project Private LSARC/2003/298. The
dictionary for GNU aspell
Interfaces Imported
Interface Name Classification Comment
---------------------- ----------------------- -------------------------
libxml2 Codebase Standard PSARC 2001/175 libxml.
Used by many dependencies.
Bug filed with ON to update
to newer version.
libxml2 directory
layout Evolving PSARC 2001/175 libxml.
libxslt Evolving PSARC 2002/244 Using XSLT
and libxslt in Solaris.
Used by many dependencies.
Bug filed with ON to update
to newer version.
FreeType Contracted External LSARC 2002/291 FreeType.
Used by GTK+. [6]
Solaris Printing Contracted External/
Stable LSARC 2002/447 GNOME 2.6
postscript viewer. Used by
GNOME's postscript viewer
(ggv). ggv is replaced by
evince in this release, so
this dependency no longer
exists. [7]
mediaLib Stable LSARC 2002/669 GNOME 2.x
use of mediaLib. Used by
GTK+.
libtiff, libjpeg,
and libpng API Evolving LSARC 2003/085 libtiff,
libjpeg, and libpng. Used
by many dependencies,
including gtk-pixbuf and
GIMP. Bug filed with ON to
update to newer version.
libtiff, libjpeg,
and libpng file
locations Stable LSARC 2003/085 libtiff,
libjpeg, and libpng.
Xscreensaver Contracted External LSARC 2001/121 Xscreensaver
Used by gnome-session.
Perl Script Interface Evolving PSARC 1999/192 Including
Perl 5 with Solaris and
PSARC 2003/661 Update Perl
to version 5.8.x. Various
GNOME scripts such as
bonobo-slay use Perl.
X11R6 Standard
PSARC 1998/299 X11R6. Used
by many GNOME modules
Standard X11
Xorg Interfaces Contracted External PSARC 2004/187 Xorg Server
For Solaris. GNOME depends
on the Xserver. Standard
X11 interfaces are
Contracted External.
Solaris Audit Contracted Project
Private PSARC 2003/397 Contracted
audit interfaces for open
source. Used by GDM. [8]
libdevinfo Contracted PSARC 2003/612 Interface
Consolidation Private for enforcing
etc/logindevperm. Used by
GDM. [9]
X core, Xvfb, XKB Standard PSARC 1998/299 X11R6.4:
Update/upgrade of X Server.
Xvfb is used by a11y
(gnome-mag). XKB used by
accessibility (libxklavier,
gnome-keyboard-preferences,
GOK).
fontconfig Contracted External LSARC 2003/273 fontconfig
library. Fontconfig is
used by GTK+ and pango.
Bug filed with Xserver
team to update to newer
version.
Xft2 Contracted External LSARC 2003/274 Xft2 library
Xft2 is used by GTK+ and
pango. Bug filed with
Xserver team to update to
newer version.
XEvIE X server
Extension Contracted External LSARC 2002/312 XEvIE.
XEvIE is used by
accessibility (GOK).
XFixes And X
Notification of Screen
and Cursor Changes
(aka Damage Extension) Contracted External LSARC 2003/506 X
Notification of Screen and
Cursor Changes aka Damage
Extension. XFixes and
Damage is used by
accessibility (gnome-mag).
XFixes X server
Extension Contracted External PSARC 2004/318 XFixes
Xserver Extension. XFixes
is used by accessibility
(gnome-mag).
XInput X server
Extension Standard PSARC 1992/172 XInput
Extension. XInput is used
by accessibility (GOK,
Gnopernicus and GDM).
XKB private headers Contracted External LSARC 2004/576 libxkbfile
update for GNOME 2.6. Used
by libxklavier.
Xrender Contracted External LSARC 2001/125 Xserver
Render Extension and LSARC
2004/414 X Render Extension
0.8. Xrender is used by
GTK+.
Xrnr Stable PSARC 2004/187 Xorg Server
For Solaris. Xrnr is used
by Nautilus and set desktop
preferences for changing
screen resolution).
gtar Contracted External In /usr/sfw consolidation.
Used by file-roller since
GNOME 2.6.
libexpat Contracted External In /usr/sfw consolidation.
Used by python,
perl-xml-parser, dasher,
D-BUS, and musicbrainz.
libusb Contracted External PSARC 2003/721 libusb.
Used by Evolution. [10]
Xvideo Contracted External PSARC 2004/187 Xorg Server
For Solaris. Xvideo is
used by the xvimagesink
GStreamer plugin.
Firefox NSS Contracted External LSARC/2004/840,
LSARC/2003/298. A set of
libraries designed to
support cross-platform
development of security-
enabled server applications
Firefox NSPR Contracted External LSARC/2004/840,
LSARC/2003/298. NSPR
provides a platform-neutral
API for system level and
libc like functions.
Sun Kerberos Contracted External PSARC/2006/027. Sun's
implementation of kerberos
libraries. Contract
pending.
Sun LDAP Evolving PSARC/2000/362,
PSARC/2000/363,
LSARC/2003/298. Sun's
implementation of the
Lightweight Directory
Access Protocol.
ldapssl_install_routines
ldapssl_client_init Contracted
Consolidation Private PSARC/2000/362, Contract
pending.
Samba External PSARC/2000/488. Used by
gnome-vfs.
Please note that Firefox NSS, NSPR, Sun Kerberos and Sun LDAP are imported
by Evolution.
4. Opinion
This project is a positive step in the evolution of GNOME at Sun, and
shows that Sun is taking a more proactive role in working with internal
process and the external GNOME community. Sun has long promoted open
development and this is demonstrated by Sun's commitment towards the GNOME
product.
It is necessary for the minimal set of GNOME interfaces required for
integrating an application into the desktop to be considered Stable. Many
existing applications that integrate with the GNOME desktop (GIMP, Adobe
Acrobat, Real Player, Thunderbird, Firefox, etc.) depend only upon the
Stable interfaces mentioned in this case, which is a reasonable indication
that this case does meet this minimal requirement.
Of second importance is ensuring the stability of interfaces used
internally within Sun by other projects. In other words, our internal
usage is a good indication for general usage. If we depend on interfaces
internally we should consider working to make them Stable externally.
Beyond these interfaces, their stability should be "market driven". For
example, a customer requesting an interface be made Stable would be an
appropriate time to expand the list of Stable GNOME interfaces.
The committee recognizes that the GNOME community has a mature process for
keeping its core interfaces stable, as documented at the GNOME Release
Planning website [13]. The committee is pleased to see that the GNOME
community continues to take additional steps to improve interface
stability, such as by adding ABI requirements that any new API must be
properly documented.
However, the committee feels that Sun could do more to create an
atmosphere where common goals are better established and shared with
external partners. For example, Sun would likely find external partners
more willing to prioritize Sun's interests in supporting highly scaled
desktop environments if Sun were more effective at contributing our work
back to those external communities. Documentation and localization work
are examples.
Furthermore, Sun should do more to evangelize OpenSolaris as a development
platform with its rich set of integrated and open development, debugging,
probing, and analysis tools.
4.1 GNOME Interface Stability/GNOME Platform
For Sun to have a healthy relationship with an external software
community, it is necessary to establish a relationship based on trust.
For Sun to be able to tell its customers what interfaces are appropriate
for use, the external community must clearly communicate how its
interfaces should be used. Sun wants external software providers to
describe the stability level of their interfaces so that Sun can inform
its customers what interfaces can be considered stable. The Sun project
team is expected to work with the external community to establish and
document interface stability and recommended usage. The more that
interface stability claims can "pass through" the better, but this does
suggest a "blind pass through". The project team must demonstrate to
ARC that these external stability claims are, in fact, meaninful.
Therefore, this is an ongoing task and at each ARC review the project team
must explain how the external community process is evolving, detail any
interface stability issues discussed in external community forums, and
explain how Sun is playing an active role in the process.
The three FreeDesktop specifications listed in the Exported Interface
table are required in order to integrate an application with the
desktop. Although they are unlikely to change, the FreeDesktop
community does not make a clear stability claim about them [17] [20].
The Icon Theme and Desktop Menu Integration interfaces must be considered
Stable by Sun, since these are required for minimal integration with the
desktop. The project team must work with the GNOME community to ensure
these are treated as Stable interfaces with appropriate backwards
compatibility if they change.
This project shows proper GNOME community references that indicate GNOME
Platform library interfaces follow interface stability guidelines
consistent with the "Stable" taxonomy used by Sun. GNOME Platform
interfaces have a stability guarantee from the GNOME community. The GNOME
release team is the body which determines the official GNOME Platform.
However, not all GNOME Platform libraries should be marked as "Stable".
Libraries such as libgnome and libgnomeui should not be marked as Stable
because these libraries are used as "holding areas" for interfaces which
eventually evolve into glib, GTK+, etc. and therefore seem intended to be
used in a "Consolidation Private" fashion within the GNOME consolidation.
Other Platform interfaces are not clearly intended for public use (those
missing API documentation, for example).
The GNOME Platform API/ABI policy does not clearly extend to non-library
interfaces. This includes FreeDesktop specifications [4] (and their
implementation in Desktop modules), GConf file formats/schemas, gnome-vfs
URI, etc. It also is not clear if stability claims cover interfaces
imported by the GNOME Platform, such as audio device and printer
interfaces.
The list of GNOME Platform interfaces [18] include:
GNOME Platform Interfaces Sun Considers "Stable":
atk
glib
gtk+
pango
at-spi (except include/libspi/Accessibility.h)
GNOME Platform Interfaces Sun Considers "External and appropriate for
Contracts":
GConf
ORBit2
at-spi (the include/libspi/Accessibility.h interface)
gail
gnome-mime-data
gnome-vfs
gtk-doc
libIDL
libbonobo
libbonoboui
libglade
libgnome
libgnomecanvas
libgnomeui
libxml2
libxslt
GNOME Platform Interfaces missing API docs ("Private"):
audiofile
esound
intltool
libart_lgpl
The project team is Advised to work with the GNOME and FreeDesktop
communities to further stabilize interfaces which Sun considers Stable or
sees a need to be Stable, but do not have a clear stability indication
from the external community (e.g. FreeDesktop specifications). The
project team is strongly advised to mark the Shared MIME Info interface as
Stable before Nevada ships.
It is important for Sun to consider those non-Stable GNOME interfaces
which are used internally by other Sun teams. Examples include GConf
(used by APOC) and pkg-config (used by Xorg, etc.). The project team is
Advised to consider how such interfaces should evolve to a more Stable
classification.
Likewise it is important for the project team to be involved with ensuring
the GNOME Platform is Stable. Reviewing ABI, proposing additional
interfaces that should be considered for including in the Platform
(perhaps pkg-config), being involved with Project Ridley [15] are
examples. Also working with the community to evolve the GNOME API/ABI
rules so that they include a more full set of interfaces (such as
non-library interfaces, configuration files, etc.) is desired. The
project team is Advised to work with the GNOME community to ensure
community Platform stability is meaningful.
A minor issue is that the pkg-config command interface is not used by some
GNOME dependencies. Some GNOME modules seem to ship their own *-config
script rather than using the pkg-config standard. The project team is
Advised to work with the module maintainers to ensure that pkg-config is
used more consistently.
4.2 Accessibility
Sun has invested a great deal of effort enhancing GNOME to support
accessibility, yet the GNOME community seems divided about long-term
support for Bonobo/ORBit2 interfaces exposed by at-spi.
The original idea behind Bonobo components is that people would write
shared components to do common tasks (view images, preview soundfiles,
etc.) that would be shared by multiple applications. In GNOME 2.0 Bonobo
components were used by Nautilus, Evolution, gnome-panel, and other
applications. Starting with GNOME 2.6 AT programs started using Bonobo
components via the at-spi interfaces.
Bonobo has had limited acceptance in the GNOME community, possibly due
to maintenance complexity and the fact that many components were not
being shared across applications as intended. Therefore, Bonobo started
to fall out of favor and most GNOME applications have moved away from
Bonobo or are in the process. However Accessibility Technology (AT)
applications using at-spi are one area in the GNOME stack where Bonobo
continues to makes a sense and will continue to require Bonobo/ORBit2
support.
The committee recommends working with the GNOME community to ensure that
Bonobo/ORBit2 interfaces have continued supported for at-spi usage.
Another solution could be redesigning at-spi so the Bonobo/ORBit2
interfaces are no longer directly exposed.
The GNOME team has done great work documenting the complexity of GNOME
Accessibility [24]. Developer documentation coverage for ATK and AT-SPI
is now at 100%, and complete documentation for the AT-SPI IDL is available
via HTML as well. User documentation for accessibility is quite
complete, with the exception of Gnopernicus and ORCA manuals). That said,
API overview documentation and developer guides to implementing
interfaces for custom widgets, but this is primarily due to the fact
that these interfaces are easily ignored by developers and thus need
extra promotion (compared to, say GTK+, for which there is much
supplemental unofficial documentation, tutorials, etc.). Investing
resources to further improve accessibility documentation will help
accelerate its standardization, use, and adoption.
The committee Advises that the Solaris PAC/PMT fund such additional
accessibility documentation efforts.
There are a number of important gaps in accessibility including fast,
competitive magnification; Sun Ray accessibility support; a lack of
quality dictation software; and identified bugs. Accessibility support
also suffers on Sparc architecture since some accessibility features
require the Xorg server which is not yet the default (such as the
Composite extension which will be used in future magnification solutions,
and the fact that XKB is not turned on by default in Xsun). Sun Ray is
Sun's most significant desktop product and accessibility support is
required by federal law, so Sun should be working harder to resolve these
issues.
The committee strongly recommends that identified gaps be resourced.
#ifndef OPEN_SOURCE_COMMUNITY
4.3 Documentation and Localization
Documentation and localization are areas where Sun makes a significant
investment to ensure that our documentation is high quality and
translated. However, Sun has not been effective at sharing our
documentation and localization work with the GNOME community. Reasons
include difficulty coordinating between the Solaris and GNOME release
schedules, the fact that Sun maintains data in different formats (e.g.
Solaris manpages are in SGML format while GNOME community uses NROFF),
and it is seen as an extra expense to spend additional time working with
the GNOME community.
Any interface exposed by the GNOME community API docs (gtk-doc) should be
given a section 3 manpage that highlights the library's interface table.
It can be assumed that if a GNOME library has no API documentation that
the interfaces can be considered "Private" (regardless of whether the
library is in the GNOME Platform or not).
Both Sun's localization and documentation teams give back our work to the
community and make the GNOME community aware that they can merge our work
into the GNOME codebase if they wish. However, because the GNOME
community is working several releases ahead of Sun, there has not been
interest from the community in doing this work.
4.4 Man Page Interfaces
Interfaces exposed in man pages (ATTRIBUTES section) should be clearly
marked in terms of their stability level. Some GNOME man pages do not
have proper values in the Attributes section, and these must be corrected
so they match the values assigned in this case. This issue is a TCR.
#endif /* OPEN_SOURCE_COMMUNITY */
4.5 GNOME Platform Interface Documentation
The committee notices that many GNOME Platform modules do not have
up-to-date interface documentation available on the web. The project team
is Advised to drive resolution on this issue with the community. This
might mean that the PAC/PMT fund a project to facilitate interface
documentation or simply the project team being proactive in documenting
and filing bugs against various GNOME components.
The committee and project team are concerned that these issues exist. The
committee Advises that the project team work with the GNOME community to
resolve the issues listed at the live.gnome.org website [3].
4.6 GNOME Library Versioning
Upon reviewing the discussion concerning library versioning (LT_VERSION
recommendations) on the Release Team website, the opinion of the committee
is that incrementing library version numbers does not add any interface
stability value on Solaris and does not need to be encouraged. Though
it may be useful for other platforms with different linker capabilities.
The GNOME Community Library Versioning Definition [14] states (reformatted
for readability):
---
For libraries, update the LT_VERSION string. There's usually a comment in
configure.in that explains how this works. For instance:
# Before making a release, the LT_VERSION string should be modified.
# The string is of the form C:R:A.
# - If interfaces have been changed or added, but binary compatibility has
# been preserved, change to C+1:0:A+1
# - If binary compatibility has been broken (eg removed or changed
# interfaces) change to C+1:0:0
# - If the interface is the same as the previous version, change to
# C:R+1:A
LIB_PANEL_APPLET_LT_VERSION=0:14:0
AC_SUBST(LIB_PANEL_APPLET_LT_VERSION)
---
4.7 GNOME Footprint Clutter
The GNOME desktop could better manage its installation footprint. GNOME,
for example, seems to clutter the /usr/share directory. It would be
useful if the GNOME community had more clear guidelines to encourage GNOME
maintainers to install files in a less cluttered fashion. For example, by
installing application specific files to /usr/share/gnome/application
rather than /usr/share/application. See advisory.
4.8 libxklavier
libxklavier uses private XKB configuration files [22] that are not safe to
use, so if a user has a non-standard Xserver or if a user is remote logged
into a computer running a different Xserver, keyboard switching will
break. However, many users who are use a supported Xserver obviously find
the ability to switch keyboard layout very useful.
"LSARC 2004/576 libxkbfile update for GNOME 2.6" discusses the fact that
Sun is now exposing the X header files used by libxklavier, but this case
does not highlight the fact that this interface is considered private and
unsupported by X.org. Nor does this case discuss the issues caused by
using this interface discussed in this section.
The project team is Advised to drive resolution on this issue with the
community. The Xorg team is currently working on a more Stable solution
which the GNOME team should adopt when it becomes available.
The project team is Advised to work with the Xorg Sun team and the
external Xorg and GNOME communities to facilitate this work.
The committee recommends that the Sun GNOME team facilitate the adoption
of a more stable interface to support libxklavier functionality.
4.9 Application Dependencies
More effort could be taken to ensure that GNOME libraries that are not
needed do not get pulled into memory. So running pldd shows many more
GNOME dependencies than elfdump, which just shows what an application links
against.
For example, when accessibility is enabled, libgail is loaded into memory
for all running GTK+ based applications. libgail contains the ATK
implementation of gnome-canvas, so libgail pulls libgnomecanvas into
memory. Moving this ATK implementation directly into gnome-canvas would
reduce the number of libraries needed when running with accessibility.
The project team is Advised to further identify such issues and work
towards minimizing the number of dependencies that are pulled into memory
when running GNOME applications.
#ifndef OPEN_SOURCE_COMMUNITY
4.10 CBE
The GNOME Custom Build Environment (CBE) contains a number of GNU tools
not found in Solaris that are needed for building the GNOME desktop. It
should be possible to build GNOME out-of-the-box with Solaris. These
same tools are needed for building many Free/Open Source applications
and Solaris should better support users who wish to build and use such
applications.
Sun should consider enhancing existing tools (make, m4, diff, flex, etc.)
so it is not necessary to use the GNU versions of these tools to build
GNOME and other Free/Open Software applications. Sun should consider
shipping GNU build tools such as autoconf, automake, libtool, and CVS that
are commonly required for building most Free/Open Software applications.
CBE Tools (according to [25]):
Apache ant *
GNU autoconf
GNU automake
GNU bison
CVS
GNU diffutils
GNU fileutils
GNU flex
GNU gettext
GNU libtool
GNU m4
GNU make
pkgbuild
rsync *
*=optional
Ideally, the GNOME CBE would eventually become simply the same as the
existing Solaris Common Build Environment, with all needed tools contained
in either the Solaris WOS or Studio compilers packages.
The committee Advises the PAC/PMT to find a resolution to the problem of
being unable to build the GNOME desktop (and other Free/Open Software
applications) on Solaris without needing to install additional build
tools, some of them needed to replace existing Solaris tools that lack
needed functionality (make, m4, diff, flex, etc.).
4.11 Solaris intltool
This project must NOT integrate with a version of intltool that continues
to be incompatible with Solaris. Shipping software in /usr/bin in the
Solaris WOS that cannot run on Solaris is simply inexcusably broken. (See
bugs 4812320 and 5042612.).
Either GNU gettext options need to be integrated into Solaris
/usr/bin/xgettext (RFE 4826523), or GNU xgettext needs to be added to
Solaris (e.g. /usr/sfw/), or make intltool work with Solaris xgettext.
Also, the project team has to hack the configure script to use
AM_GLIB_GNU_GETTEXT macro (which is unsupported by the external community)
instead of the supported AM_GNU_GETTEXT macro (bug 6329710).
The committee Requires that the PAC/PMT fund a project to have the
intltool problem resolved.
#endif /* OPEN_SOURCE_COMMUNITY */
4.12 GConf
Solaris users complain that user preferences are not managed in a Stable
fashion when switching between GNOME environments. Examples include users
who share the same $HOME directory across multiple versions of GNOME, or
users who experience problems on upgrade. Typically users must delete
their $HOME/.gconf directory to get their preferences back to a usable
state.
It is likely more common for Solaris users to share $HOME directories
across multiple machines, so this problem is likely of lesser importance
to other GNOME distributions. Likewise, it is more common for Sun to
skip GNOME minor releases. So Linux users upgrading from
2.0->2.2->2.4->etc. may experience less problems than Solaris users
upgrading from 2.0->2.6->2.12+.
Even though GConf is considered a GNOME Platform library, the GNOME
community stability guarantee does not extend to the GConf file structure
or the key/value pairs. Resolving this problem would require identifying
which GConf keys require stability and working with the GNOME community to
mark these keys as Stable. This would require a significant amount of
work and community interaction to resolve. This is also probably not
necessary to resolve the underlying problems.
Fixing backwards compatibility issues with GConf from a coding perspective
is typically not much work. The hard part is identifying issues when they
are introduced in the codebase. Therefore, the best approach to address
this issue if more QA effort were invested to ensure that problems are
identified, reported to the GNOME community, and corrected. Also, more
effort could be made to make sure that when Solaris users complain about
such problems, the user's corrupted $HOME/.gconf settings are captured,
the issue identified and corrected.
One example of work done in the past to resolve such an issue is the
gnome-panel patch [21] applied to GNOME 2.6. This patch was used to
address a problem that was causing the panel to crash due to
incompatibilities in the panel configuration between 2.0 and 2.6. This
patch causes the user to have separate panel configuration for the two
GNOME versions. Leaving this patch in place for future builds will
ensure that panel preferences are not lost between GNOME 2.6 and future
builds.
The committee Advises that the PAC/PMT to fund QA testing efforts to
identify GConf instability issues when sharing a $HOME directory across
different versions of GNOME.
4.13 Default Application Launching
There exists a mechanism (Preferences->Preferred Applications) for users
to specify their default Browser, Mail program, and Terminal Program. Yet
in the Applications menu, we have choices for "Evolution", "Firefox", etc.
The menus should contain menu choices which will launch the appropriate
program instead of listing the programs separately. Perhaps a "Default
Browser" choice in addition to, say, "Firefox".
The project team is Advised to improve the menu choices so they work with
the user's preferred choice.
4.14 MIME Info Update Utilities
Associated with the MIME Info Integration FreeDesktop specification is an
"update" utility. To get additions to be seen it is necessary to run
this utility. For example, to add the "foo" mime type:
cp foo.xml /usr/share/mime/packages/foo.xml
update-mime-database /usr/share/mime
To be useful, these commands need to be at the same commitment level
(Stable) as the uncached formats. Hence "update-desktop-database" and
"gtk-update-icon-cache" need to be made stable as part of this case and
"update-mime-database" need to promoted when the MIME interfaces are
promoted.
4.15 Evolution
The Evolution project has resolved the following TCR's from the previous
LSARC 2003/298 case:
Section 6, item 2: Evolution must no longer statically link against
private BerkeleyDB interfaces.
Section 6, item 5: S/MIME must be supported.
Appendix A, issue 1: All C++ libraries supplied by Evolution must be
compiled with the Sun CC compiler rather than g++ to
product ABI-conformant libraries.
Appendix A, issue 2b: Evolution must use SunLDAP instead of OpenLDAP.
Appendix A, issue 3: Files in /usr/libexec need to be moved to /usr/lib.
Appendix A, issue 4: Do not ship archive libraries.
However, the following tasks have not been completed:
Appendix A, issue 2a: The project team must not use GnuTLS. Instead they
must find the root cause of the problem that
originally required the use of GnuTLS, and resolve
it without using this additional security library.
Appendix A, issue 5: Libraries should be shipped with version numbers and
version tags.
Appendix A, issue 6: Make all the components of aspell which are
necessary for runtime, private and hidden from the
user, and not to ship any documentation.
Also, the following usses (from section 6 of LSARC 2003/298) were given
a one-time exception, but need to be resolved before Evolution can be
updated.
1. The committee allowed a one-time exception to the "Packaging rules
for system extensions" policy in regards to statically linking to the
BerkeleyDB package. This must be corrected.
2. S/MIME is a missing feature that must be added.
It has been pointed out that other GNOME programs (GOK, for example)
use aspell, so making a commitment to make these interfaces more Stable
than "Consolidation Private" should be considered if these interfaces
are intended for use beyond Evolution.
It is disturbing that these issues were not resolved before shipping
the last release of Evolution, and the project team is reminded to
resolve TCR's before shipping, or acquire a waiver through the appeals
process. It is not acceptable to ship without following process.
#indef OPEN_SOURCE_COMMUNITY
5. Minority Opinion(s)
None.
6. Advisory Information
Escalation to Solaris PAC/PMT
-----------------------------
The committee recommends that the SSG PAC fund the SSG project to port
the SPARC graphics drivers to Xorg, and the Sun Ray PAC to fund the Sun
Ray project to complete required Sun Ray work to support the extensions
needed to support accessibility. Refer to section 4.2.
The committee strongly recommends that the Solaris PAC/PMT fund additional
accessibility documentation efforts. Refer to section 4.2.
To resolve this problem and foster a better relationship between Sun and
the GNOME community the committee Advises the PAC/PMT to fund Sun's
documentation and localization teams to work more closely with the GNOME
community by working against community CVS head so we leverage concurrent
efforts by community members. Refer to section 4.3
Solaris quality and branding rules have encouraged Sun to maintain forked
documentation and internationalization data, and attempting to merge our
work with the GNOME community is seen as additional work. The committee
Advises the PAC/PMT to rethink our quality, glossary, and branding rules to
see what creative solutions can be found to work better when working with
external groups. Refer to section 4.3.
The committee recommends that the Solaris PAC/PMT fund integration of the
GNOME CBE tools into Solaris. Refer to section 4.10.
The committee recommends that the Solaris PAC/PMT fund QA resources to
identify issues with GConf preferences failing to work across multiple
versions of GNOME, and to fund engineering to fix issues discovered.
Refer to section 4.12.
Advice to Sun GNOME Project Team
--------------------------------
The committee recomments that the Sun GNOME Team work more closely with
the GNOME and FreeDesktop groups to stabilize interfaces which Sun
considers Stable, but do not have a clear stability indication from the
external community. For example, the FreeDesktop specifications. Refer
to section 4.1.
The committee recommends that the Sun GNOME team be more involved with
ensuring high quality GNOME API documentation. Refer to section 4.5.
The committee recommends that the Sun GNOME team share the ARC
perspective about library versioning being unnecessary with the GNOME
community, since there seems to be debate regarding the usefulness of
this practice. Refer to section 4.6.
The committee recommends that the Sun GNOME team work with the GNOME
community to ensure better FHS compliance. Refer to section 4.7.
Appendices
Appendix A: Technical Changes Required
1. The project team is Advised to integrate Sun's man pages with the
GNOME community codebase and work with the community to determine
the best format for them (NROFF, SGML, or preferably docbook).
Sun should ship the man pages in whatever format is used by the
GNOME community, if possible, and avoid maintaining forked man
pages. Refer to section 4.4.
2. The Sun GNOME team must work with the intltool team and put
together a strategy for resolving the problems described in
section 4.11. If the team cannot resolve the problem in this
way, the broken interfaces must be removed from the GNOME
distribution.
3. The Evolution project must address the TCR's described in
section 4.15 or go through the appeals process.
Appendix B: Technical Changes Advised
1. The committee recommends that libgail be re-engineered so that
it does not require non-Stable library dependencies for
improved performance. Refer to section 4.9.
2. The committee recommends that the application menu choices work
with the user's preferred settings. Refer to section 4.13.
#endif /* OPEN_SOURCE_COMMUNITY */
Appendix C: Reference Material
1. http://sac.sfbay.sun.com/Archives/CaseLog/arc/LSARC/2005/734/nevada-gnome-one-pager.txt
Project 1 pager
2. http://sac.sfbay.sun.com/Archives/CaseLog/arc/LSARC/2005/734/inception.materials2/
Inception Materials
3. http://live.gnome.org/InterfaceSpecification/Issues
GNOME Interface Issues
4. GNOME-Nevada-Interfaces.txt
GNOME Interface Table
5. http://sac.sfbay.sun.com/Archives/CaseLog/arc/LSARC/2003/298/opinion.txt
LSARC 2003/298 Evolution Opinion
6. http://sac.sfbay.sun.com/Archives/CaseLog/arc/LSARC/2001/384/commit.materials/contract-01
FreeType Contract
7. http://sac.sfbay.sun.com/Archives/CaseLog/arc/LSARC/2002/447/contract-2002-447-01.txt
Solaris Printing Contract
8. http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2003/397/contract.gdm
Solaris Audit Contract
9. http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2003/612/contract-01
libdevinfo Contract
10. http://sac.sfbay.sun.com/Archives/CaseLog/arc/LSARC/2005/414/contracts/contract-721-01
libusb Contract
11. http://sac.sfbay.sun.com/Archives/CaseLog/arc/LSARC/2005/734/commit.materials/wiki/gnome.ireland/gnome/ARC/gdm/2.8/gdm.html
GDM Documentation
12. http://opensolaris.org/os/community/onnv/os_dev_process/
OpenSolaris ARC Process Documentation
13. http://live.gnome.org/ReleasePlanning
GNOME Release Planning Website
14. http://live.gnome.org/MaintainersCorner_2fReleasing
The GNOME Community Library Versioning Definition
15. http://live.gnome.org/ProjectRidley
GNOME Project Ridley website
16. http://www.pathname.com/fhs/
FHS website
17. http://www.freedesktop.org/wiki/Standards
FreeDesktop Standards Website
18. ftp://ftp.gnome.org/pub/GNOME/platform/
GNOME Platform Libraries
19. http://www.gnome.org/start/2.8/
http://www.gnome.org/start/2.10/
http://www.gnome.org/start/2.12/
GNOME Release Notes
20. http://www.freedesktop.org/wiki/Portland
FreeDesktop Portland project.
21. http://cvs.opensolaris.org/source/xref/jds/patches/gnome-panel-06-concurrent-login.diff
GNOME Panel Concurrent Login patch
22. http://bugzilla.gnome.org/show_bug.cgi?id=152105
libxklavier usage of private Xorg interfaces
23. http://bugzilla.gnome.org/show_bug.cgi?id=301364
Bug regarding making intltool work with Solaris xgettext
24. http://gnome.org/learn/access-guide/2.10/
Accessibility Guide
25. http://www.opensolaris.org/os/community/desktop/communities/jds/building/
Building JDS on OpenSolaris
GNOME 2.14 - Vermillion, Functional Specification
1 Project Description
This project continues on the work of LSARC 2005/734 to provide
a newer version of GNOME, as part of the Java Desktop System,
targeted for Nevada. More formally, this project will integrate
GNOME 2.14 along with some other components that aren't
currently part of the official community release.
GNOME is essentially comprised of 2 sets of components
- The GNOME Desktop, a collection of utilities and applications
that a user needs for every day work. Some internal 'desktop
private' libraries are included here.
- The GNOME Developer Platform, a set of libraries that
developers can use to write applications that integrate
well into the desktop. All GNOME Stable library interfaces
fall into these components.
1.1 Definition
This case will build on from previous cases, in that it will
only outline the differences between GNOME 2.12, as detailed
in LSARC 2005/734 and GNOME 2.14.
Those differences can be loosely summarized as follows:
- Continuing focus on user experience and consistency
throughout the desktop
- Significant performance improvements to several
important components eg. Terminal
- Search framework in File Manager and Help Browser
- Improved Window Management
- Improved configuration support in Login Manager
- New applications eg. Deskbar Applet, Fast User
Switching, Sound Juicer
- Shared calendaring in Evolution over CalDAV
- Significant improvements to the multimedia framework,
GStreamer in terms of stability, performance and
integration of 3rd party plugins, and introduction of
new media applications.
- Continuing evolution of the GTK+ widget library and
dependencies
1.2 Motivation, Goals, and Requirements
GNOME meets the desktop needs of Sun customers who have invested in
the Solaris OS, and prefer the stability and maturity of that platform.
Moreover, the GNOME desktop provides an alternative for customers
migrating away from Microsoft, or a comparable offering to those
migrating away from Linux.
The following requirements from section 14 of the Solaris Nevada
Product Requirements Document are relevant to this particular
ARC case -
o Up-to-date support of community components (GNOME, browser,
email, GAIM, etc...)
o Up-to-date productivity and entertainment application support
o Accessibility features (minimally to meet 508)
o Enhanced printing management (print utility)
o Remote Desktop Administration (help desk)
o Enhanced/complete localization of desktop components for all
geographic target markets
As a modern productivity, collaboration, and tools environment, the
Solaris OS desktop in Nevada needs to deliver a media rich and highly
personalizable, yet simple and uncluttered user experience. The Nevada
desktop needs to support all leading media formats (documents, voice,
multimedia, etc.). It also needs to deliver a set of core - but well
integrated - desktop applications.
Specifically, it needs to offer one standard browser, email client and
Instant Messaging client (as opposed to several clients) that the
mainstream desktop market shows to favor.
Furthermore, with appropriate increases in Stablility and quality,
the GNOME desktop will become an operationally complete replacement
for CDE, allowing that product to be completely EOL/EOF. This
should result in a significant cost reduction to Sun.
1.3 Changes From the Previous Release
This is a minor change to the GNOME desktop that addresses concerns raised
in "LSARC 2005/734 GNOME For Nevada", adds new desktop functionality as
described above, or detailed externally in the GNOME 2.14 release notes [6],
adds some new components (notably in better support of media), and fixes bugs.
This case adds some new interfaces to Stable libraries and new External
applications and libraries as detailed in the Interface Table.
1.4 Program Plan Overview
1.4.1 Development
Community development is very much at the core of the GNOME Desktop,
and consequently the Java Desktop System, JDS. The project team values
this, and chooses to work 'with' rather than 'against' where possible
on an open development model.
Furthermore, with the relatively recent birth of the OpenSolaris project,
the project team also works under the OpenSolaris Desktop Community,
with a public development environment. The project sees the importance
of an open development strategy in the hope to leverage key allies and
communication among the different product groups in Solaris.
1.4.2 Quality Assurance/Testing
The project team will continue to uphold high standards in QA, creating
test assertions for new functionality, along with regression testing
with existing components. Frequent builds will be available under the
OpenSolaris project, and the project team will encourage feedback.
1.4.3 Documentation
Documentation will be leveraged from the community where possible. If
missing, the project team will be provide the necessary documentation
in conjunction with existing documentation teams within Sun.
Furthermore, the project team will promote the use of high standards
within the community, and ensure that missing documentation will go
back to the community.
1.4.4 Release Cycle
The project team aims to integrate this project as close to build
40 or 41 of Solaris Nevada. Once integrated, the project will follow
existing Nevada release schedules.
1.4.5 Technical Support
Technical support will be provided by existing support channels.
1.4.6 Training
Training will be provided as per existing Solaris requirements.
1.5 Related Projects
1.5.1 Dependencies on Other Sun Projects
LSARC 2004/109 Trusted Solaris X Server Extension
LSARC 2005/280 Trusted Solaris Gnome
PSARC 2005/399 Tamarack: Removable Media Enhancements in Solaris
Refer to LSARC 2005/734 GNOME For Nevada Imported Interface
table for additional dependencies.
1.5.2 Dependencies on Non-Sun Projects
FreeDesktop (http://www.freedesktop.org/)
GNOME Project (http://www.gnome.org/)
XOrg Project (http//www.x.org/)
1.5.3 Sun Projects Depending on this Project
PSARC 2000/487 Solaris-Linux API Compatibility (contract in
PSARC 2001/804 Glib becomes Contracted External)
LSARC 2003/273 fontconfig library (contract in LSARC 2003/273)
LSARC 2003/274 Xft2 library (contract in LSARC 2003/274)
LSARC 2004/707 SWUP Bootstrap (contract in LSARC 2004/707)
LSARC 2004/840 Firefox for JDS4
LSARC 2005/221 APOC2.0 (contract in LSARC 2003/217 APOC)
LSARC 2005/504 Orca Screen Reader/Magnifier
LSARC 2005/506 Orca Support Libraries
LSARC 2005/701 Realplayer plugin and reader integration into Solaris
FIXME: Thunderbird?
1.5.4 Projects Rendered Obsolete by this Project
LSARC 2005/345 GNOME Keyboard Layout Switcher EOF
FIXME: ggv/gpdf?
FIXME: nautilus-media?
FIXME: jdshelp?
FIXME: gnome-cd?
1.5.5 Related Active Projects [Describe the relationship.]
LSARC 2006/182 Ekiga: a videoconferencing and VOIP/IP-Telephony
application
1.5.6 Suggested Projects to Enhance this Program
JDS team currently working with gettext team to resolve TCR's
highlighted in LSARC 2005/734 GNOME For Nevada.
1.6 Competitive Analysis
Today's information worker relies on a disjointed set of office
productivity, content, collaboration and portal tools. The future
desktop will be much simpler, yet richer, than today's by incorporating
contextual, role-based information from business systems, applications
and processes. It will deliver:
- Voice
- Documents
- Rich media
- Process models
- Business intelligence
- Real-time analytics
It will also foster just-in-time eLearning as well as real-time
collaboration. Using a service-oriented architecture, the future desktop
will be rich with presence awareness, information rights, and
personalization. It will provide offline and online support to a plethora
of devices. As this unfolds, information work will expand beyond
traditional knowledge workers. The future desktop will begin to emerge
in two years and will evolve radically during the next five to eight
years. It will include a wide range of new technologies and capabilities.
Core elements of this new information workplace will be:
- Enterprise information
- Metadata
- Integration services
- Identity services
- Content services
- Collaboration services
Internal and external users will be able to access all enterprise
information to which they have privileges using a variety of devices,
not just laptops and PDAs. For that reason, privacy and security will
be key concerns.
It is essential that Solaris OE ships with an updated desktop, both in
terms of providing support and the technical merits of a newer desktop.
2 Technical Description
2.1 Architecture
This project is a new iteration of the GNOME Desktop and Developer
Platform. It continues development of existing technology, on an
existing architecture of a layered X11 application environment -
+---------------------------------------+
| GNOME Desktop |
+---------------------------------------+
| Additional Desktop Libraries |
+---------------------------------------+
| GTK+ |
+-------------------------+-------------+
| Pango | GDK |
+-----------+-------------+-------------+
| Cairo | Glib |
+-----------+---------------------------+
| X11 |
+---------------------------------------+
The GNOME Desktop contains a rich set of utilities and applications
that a user needs for every day work, which get launched from a
comfortable user windowing environment including session manager and
panel.
GNOME 2.14 continues its evolution of the GNOME Platform, a set of
libraries that developers can use to write applications that integrate
well into the desktop. The project team continually evaluates these
interfaces separate to the community and classify them accordingly
to our confidence in their evolution and stability.
2.2 Interfaces
2.2.1 Exported Interfaces
Interfaces Exported
Proposed Specified in
Stability What Document?
Interface Name Classification Comments.
==========================================================================
Detail on FreeDesktop Specs defined in LSARC 2005/734
-----------------------------------------------------
/usr/share/applications Stable System integration point from
Desktop FreeDesktop spec.
$HOME/.local/share/applications Stable User integration point from
Desktop FreeDesktop spec.
/usr/share/gnome/applications Obsolete Obsolete Sun-specific location
for desktop files supported
on Sun for GNOME 2.0 backwards
compatibility.
/usr/share/icons Stable Icon Integration FreeDesktop
spec.
/usr/share/mime/packages External Need to make MIME FreeDesktop
spec Stable before Nevada
ships.
ATK
---
atk_component_get_alpha Stable New ATK functions.
atk_document_get_attribute_value Stable
atk_document_get_attributes Stable
atk_document_get_locale Stable
atk_document_set_attribute_value Stable
atk_image_get_image_locale Stable
atk_object_get_attributes Stable
at-spi
------
AccessibleComponent_getAlpha Stable New libcspi (at-spi)
functions.
AccessibleEvent_getSourceApplication
Stable
AccessibleEvent_getSourceDetails Stable
AccessibleEvent_getSourceName Stable
AccessibleEvent_getSourceRole Stable
AccessibleImage_getImageLocale Stable
Accessible_getAttributes Stable
Accessible_getHostApplication Stable
pango
-----
pango_matrix_get_font_scale_factor
Stable New pango functions
specified in gtk-docs
gobject
-------
g_object_force_floating Stable New gobject functions
specified in gtk-docs
g_object_is_floating Stable
g_object_ref_sink Stable
g_param_spec_gtype Stable
g_param_spec_ref_sink Stable
g_hash_table_get_type Stable
g_gtype_get_type Stable New get_type functions
These are normally not
documented in gtk-docs.
g_initially_unowned_get_type Stable
g_value_get_gtype Stable
g_value_set_gtype Stable
g_object_compat_control Consolidation This is "hidden" but
Private since this attribute is
not supported, Forte
exports this symbol.
glib
----
g_async_queue_push_sorted Stable New glib functions
specified in gtk-docs
g_async_queue_push_sorted_unlocked
Stable
g_async_queue_sort Stable
g_async_queue_sort_unlocked Stable
g_atomic_int_set Stable
g_atomic_pointer_set Stable
g_date_set_time_t Stable
g_date_set_time_val Stable
g_hash_table_ref Stable
g_hash_table_unref Stable
g_intern_static_string Stable
g_intern_string Stable
g_list_insert_sorted_with_data Stable
g_main_context_is_owner Stable
g_slice_alloc Stable
g_slice_alloc0 Stable
g_slice_free1 Stable
g_slice_free_chain_with_offset Stable
g_slist_insert_sorted_with_data Stable
g_thread_foreach Stable
g_thread_pool_get_max_idle_time Stable
g_thread_pool_set_max_idle_time Stable
g_thread_pool_set_sort_function Stable
g_slice_get_config Stable
g_slice_get_config_state Stable
g_slice_set_config Stable
GDM Configuration
-----------------
debug/Gestures Stable
daemon/GdmXserverTimeout Stable New GDM Configuration
allowing users to specify
how long GDM should wait
for the Xserver to start.
Default is 10 seconds.
greeter/PreFetchProgram Stable New GDM Configuration
to support preloading
session libraries for
better performance
/usr/lib/gdmprefetch External Program launched by
greeter/PreFetchProgram
/etc/X11/gdm/gdmprefetchlist External List of libraries to
prefetch.
Package Names
-------------
SUNWlibcdio Stable Package name for libcdio
SUNWgst-fluendo-mp3 Stable Package name for MPEG-1
level 3 (MPG audio)
GStreamer plugin.
SUNWapoc-adapter-gconf Stable New package name : FIXME
SUNWgnome-internet-applets-devel Stable New package name
SUNWgnome-pilot Stable New package name FIXME.
SUNWgnome-pilot-devel Stable New package name FIXME.
SUNWgnome-pilot-devel-share Stable New package name FIXME.
SUNWgnome-pilot-root Stable New package name FIXME.
SUNWgnome-pilot-share Stable New package name FIXME.
SUNWgnome-python-desktop Stable New package name
SUNWgnome-python-desktop-devel Stable New package name
SUNWgnupg Stable New package name
File Locations
--------------
/usr/share/gdm/defaults.conf External GDM default configuration
/etc/X11/gdm/custom.conf External GDM custom configuration
/etc/X11/gdm/gdm.conf Obsolete Old GDM configuration,
supported as custom.conf
file if on system for
backwards compatibility.
/usr/lib/libnautilus-burn.so External Library for CD burning. FIXME.
/usr/bin/sound-juicer External New media player
/usr/bin/rhythmbox External New media player
/usr/lib/pkgconfig/rhythmbox.pc External New pkgconfig file.
/usr/bin/gnome-cd Obsolete No longer shipping
gnome-media CD player.
Now shipping symlink to
sound-juicer for
backwards compatibility.
/usr/lib/gstreamer-0.10/libgstflump3.dec.so
External New MP3 plugin for
GStreamer to support
MPEG1 level 3 (MP3 audio)
decoding.
/usr/lib/gstreamer-0.10/libgstcdio.so
External New cdio paranoia plug
for GStreamer to support
CD ripping.
/usr/bin/cd-drive External New libcdio interface
/usr/bin/cd-info External New libcdio interface
/usr/bin/cd-paranoia External New libcdio interface
/usr/bin/cd-read External New libcdio interface
/usr/bin/iso-info External New libcdio interface
/usr/bin/iso-read External New libcdio interface
/usr/lib/libcdio.so External New libcdio interface
/usr/lib/libiso9660.so External New libcdio interface
/usr/lib/libudf.so External New libcdio interface
/usr/include/cdio/*.h External New libcdio interface
/usr/lib/pkgconfig/libcdio.pc External New pkgconfig file
/usr/lib/pkgconfig/libcdio_cdda.pc
External New pkgconfig file
/usr/lib/pkgconfig/libcdio_paranoia.pc
External New pkgconfig file
/usr/lib/pkgconfig/libiso9660.pc External New pkgconfig file
2.2.2 Imported Interfaces
FIXME.
2.3 User Interface
GNOME 2.14 continues on its focus of user experience and usability.
While there have been made significant changes both in terms of
functionality and other user-oriented features, the core user interface
remains the same as previous cases.
2.4 Compatibility and Interoperability
2.4.1 Standards Conformance
This project will continue standards conformance as detailed in
LSARC 2005/734 GNOME For Nevada.
The Evolution mail, addressbook and calendar client now supports
CalDAV, a protocol allowing calendar access via WebDAV. CalDAV is
part of the Network Working Group, Internet Engineering Task Force
(IETF).
2.4.2 Operating System and Platform Compatibility
This project is targetted for Solaris Nevada on x86 and SPARC platforms.
While there has been discussion regarding providing this project in a
Solaris Update release, there has been no formal decision to date.
Support for Linux is not currently in the scope of this project, although
The GNOME Desktop obviously runs well on that platform.
2.4.3 Interoperability with Sun Projects/Products
Due to the nature of this project, and its architecture, all existing
Sun products should run seemlessly in this desktop environment. Exceptions
to this rule may involve using legacy windowing interfaces.
2.4.4 Interoperability with External Products
All products that can interoperate with the X11 window system will run
seemlessly in their desktop environment as above.
2.4.5 Coexistence with Similar Functionality
[Can other products with overlapping functionality be run on the same
machine, or will they clash (e.g. over resources such as specific port
numbers)? ]
FIXME.
2.4.6 Support for Multiple Concurrent Instances
[Can more than one instance of this product be safely run on the same
machine? If yes, can they be different versions? ]
FIXME.
2.4.7 Compatibility with Earlier and Future Releases
[See discussion in the Changes to Interfacessection of the Architectural
Considerations document[5], even if this is the first release. ]
FIXME.
2.5 Performance and Scalability
FIXME - we need some metrics here. There's some nice bits in the GNOME
release notes.
2.5.1 Performance Goals
2.5.2 Performance Measurement
2.5.3 Scalability Limits and Potential Bottlenecks
2.5.4 Static System Behavior
[Resources required (footprint, disk space, large files, database, etc.)]
2.5.5 Dynamic System Behavior
[does the system wake up periodically? what is the expected working set?
how much of is is potentially shareable? Is it MT-safe (will it work
with multi-threaded clients)?
See the Performance, Resource Consumption, and Scalability section of the
Architectural Considerations document[5] for more advice.]
2.6 Failure and Recovery
2.6.1 Resource Exhaustion
[What happens when resources (e.g. virtual memory, disk space) are
unavailable or exhausted?]
2.6.2 Software Failures
[What circumstances cause abnormal behavior? How are user interrupts
handled?]
2.6.3 Network Failures
2.6.4 Data Integrity
[Will data be lost if the program aborts or crashes?]
2.6.5 State and Checkpointing
2.6.6 Fault Detection
2.6.7 Fault Recovery (or Cleanup after Failure)
2.7 Security
[What support does this product have for authentication? authorization
policies? privacy (e.g. encryption)? integrity? Are there any associated
export restrictions? Is sensitive data protected against snooping?
against unauthorized modification? Are the policies different for local
and on-the-wire data?
See the Security Classifications section of the Architectural Considerations
document[5].]
2.8 Software Engineering and Usability
2.8.1 Namespace Management
[The key goal is to avoid "namespace pollution". That is, consume as
little of the client namespace as possible, make sure names are unique,
and document what you're consuming. Pick a common prefix and use it
for public names and symbols. Reserve Solaris package names and Java
package names that are unique and comply with the appropriate conventions.
A secondary goal is to avoid gratuitous creation of new namespaces. If
there is a public namespace, how is it administered?]
2.8.2 Dependencies on non-Standard System Interfaces
[Do Solaris components depend on kernel features not in the default
kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib,
optional loadable kernel modules)?
Do Java components depend on Java classes that are non-standard or
not included in the JDK runtime?
Projects using system (or other project) interfaces that are neither
Standard nor Stable (formerly Public) should explain to the ARC why
the risk of being broken by an incompatible change are sufficiently
low, and howthe risk will be managed.]
2.8.3 Year 2000 Compliance
[All SunSoft products FCS'd on or after May 1, 1997 must be compliant,
though the working definition is merely "still work in the year 2000".
(Those price-listed after Jan. 1, 1995, need a solution plan.) Advice:
save years in 4 digits, not just 2; interpret and sort 2-digit years
as indicating years from 1969 through 2068, if possible. For more
infomation, visit http://spg-quality.eng/y2000. For help evaluating
your software for Year 2000 compliance, or to volunteer to help define
guidelines, contact y2000 boutique eng ]
2.8.4 Internationalization (I18N)
[Sun products must comply with Internationalization levels 1-4. (The
levels are not truly hierarchical, but generally indicate increasing
difficulty.)
I18n Level Meaning
========================================================================
"Level 0" Are images trivially replaceable without source code?
Cultural differences demand it.
Level 1 "8-bit clean" to support ISO Latin-1 (European)
codesets. This includes data paths and messages.
Level 2 Formatting (date, time, currency, numbers) are
locale-sensitive.
Level 3 User-visible text trivially translated in message
catalogs. Localization (L10n) should be possible
without algorithmic source code.
Level 4 Asian language support--via Extended Unix Coding (EUC)?
Are data paths capable of handling wide Asian
characters? Code Set Independence (CSI) enabled? (See
Solaris 2.6's attributes(5) manpage.)
A replacement set of requirements for Internationalization is under
development. For more information, see the Internationalization section
of the Architectural Considerations document[5]. Questions may be asked
of the "i18n-interest sun" alias.]
2.8.5 64-bit Issues
[How will it deal with issues in the 64-bit world, including 64-bit
address spaces, 64-bit integers, and 64-bit files? Most Solaris projects
should at least be 64-bit "clean." For C, you can use DevPro lint with
-errchk=longptr64.]
2.8.6 Porting to other Platforms
[Is this anticipated? What would be involved?]
2.8.7 Accessibility
[Sun products must support Section 508 compliant accessibility for users
with disabilities. What is your plan for compliance? See
http://solaris.eng/accessibility/index.html.]
3 Release Information
Note: Some of the packaging and installation details may not be available at
design time. Describe expected solutions, and augment the description as the
details are decided.
FIXME.
3.1 Product Packaging
[Is this product bundled or unbundled? How is it released for each major
configuration/platform?
3.1.1 Package Overview
For each Solaris package or installation unit, give
+ its purpose
+ its name
+ its default installation root
+ whether it is required, recommended, or optional]
3.1.2 (Default) Installation Locations
[For each of the following categories, state the default installation
directory name(s).
+ configuration files
+ libraries
+ temporary files
+ DLLs, VxDs for Windows
+ Java packages and zip or class files]
3.1.3 Effect on External Environment
[Are any of the above components shared with other projects? Is anything
external to this project modified or circumvented?
For SAC advice about packaging and installation locations, start at
http://sac.eng/sac/HTML/Considerations/#Packaging.
ARCs should review "ABI application certification" results for all
executables and libraries that run on Solaris. See http://abi.eng/ and
http://suntools.eng/tools/toolpages/appcert.html and/or
http://www.sun.com/developers/solbrand/app-cert.certify.html.]
3.2 Installation
3.2.1 Installation procedure
3.2.2 Effects on System Files
[what is touched outside this project?]
3.2.3 Boot-Time Requirements
[rc start/kill scripts, dependencies, etc.]
3.2.4 Licensing
[Describe licensing scheme, if any. Default should be the approved DevPro
licensing package, 1995/151; FlexLM is also a possibility.]
3.2.5 Upgrade
[Describe versioning scheme, and explain how version mismatches are
handled (e.g. upgrades, backwards compatibility).]
3.2.6 Software Removal
3.3 System Administration
[What is supported? GUI or command line? Configuration? Maintenance?
Logging? Monitoring? Can administration be performed remotely?
Backup/Restore capabilities? Is relocation supported?
See the System Administration section of the Architectural Considerations
document[5].]
4 Component Name Architecture
Note: Section 4 and beyond should be used for detailed functional
specifications for each major component or subsystem as described in the
Architecture section. (A component can be anything, for example: a library, an
executable, an applet, or a GUI.) The following Section 4 is intended as an
example outline of such a component specification. Include any subsections of
Sections 2 or 3 that are appropriate for this component if not already covered
above.
FIXME - moved from an alternate section.
This project adds the "External" GNU libcdio library to Solaris, allowing
programs that depend on GStreamer, such as Sound Juicer, to have access to
CD ripping functionality. This library is built with GCC because Sun
Forte compiler does not yet support GNU style "flexible arrays". According
to the Sun Studio team RFE's 6308028, 6342333, and 6342974 should be
resolved in Sun Studio 11, and we will start building libcdio with Forte
when this happens. In the meantime, we are not shipping libcdio with
C++ headers and library stub functions as these are not required for
GStreamer or Sound Juicer support. To better follow the external
project, we plan to ship the C++ headers and library stubs when we port
libcdio to Forte. Hopefully before Nevada ships, if possible.
4.1 Description
[May include component architecture, if desired.]
4.2 Interfaces
4.2.1 User-visible
[Are there relevant aspects of this component's interfaces that are not
covered by the global interface table from section 2.2?]
4.2.2 Internal (optional for ARC review)
4.3 Operation
[How and when is the component started? What are its operating
requirements? How does it interact with other components?]
There are specific guidelines in the Architectural Considerations
document[5] for command line syntax, libraries, daemons (search for
"daemon"), device drivers, and Graphical User Interfaces (GUIs).
Appendix A: Standards Supported
References
[Reference key documents mentioned in your specification.]
R.1 Related Projects
[List projects by name and ARC case numbers. Include in this section any
interface contracts or other inter-project info.]
R.2 Background Information for this Project or its Product
[Reference the Requirements Specification, Project Plan, etc.]
R.3 Interface Specifications
[If not within this document, reference specifications for the syntax and
semantics of any interfaces. Use man pages, tables, state diagrams, or
whatever means is appropriate.]
R.4 Project Details
[Include design documents, implementation notes, etc.]
Important References for embedded comments
[1] http://sac.eng/arc/Processes/Client.Handbook/
[2] http://sac.eng/BestPractices/interface_taxonomy.txt/
[3] Motif 1.2 Style Guide (sun part no. 801-5366-10)
[4] CDE Style Guide and Certification Checklist (Sun part no. 802-1581-10)
[5] Architectural Considerations Document, http://sac.eng.sun.com/arc/ARC-Considerations.html
[6] GNOME 2.14 Release Notes, http://www.gnome.org/start/2.14/
[7] MP3 License, http://jds.ireland/common/legal/patents/MP3_Patent_License.pdf
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
