Department of Engineering

IT Services

The CentOS 7.1 Desktop - internals

In order to have a better idea of how to deal with some gnome desktop issues on CentOS 7.1 (in particular how to set system-wide defaults for which application to run when files are clicked on) I started reading the documentation. The notes below are cobbled together from various sources (often incomplete even when they're official) and may well include my own additional misunderstandings.

Much has changed since the last version we used (CentOS 6) so this document deals with some system-level changes before considering the destop.

Gnome

GNOME 2 used the traditional desktop metaphor, but GNOME 3 introduced GNOME Shell, a more abstract metaphor where switching between different tasks and virtual workspaces takes place in a separate area called Overview. There are also plans to replace X by Wayland.

Gnome uses Glib data structures and utilities library, GObject object and type system and GTK+ widget toolkit, D-Bus (inter-process communication; replaces Bonobo), Cairo (2D vector-based drawing), Clutter (accelerated graphics library), Pango (international text rendering library), PulseAudio (low-level audio API), GStreamer (multimedia framework), etc.

systemd

A Linux Journal article gives a good overview of Unix's process 1, and why systemd has been introduced. It says that

  • 4.4 BSD init is pretty simple and monolithic. When booting, the kernel runs /sbin/init, which spawns a shell to run the /etc/rc script.
  • SysV init can be started in one of many distinct states (runlevels). The kernel runs /sbin/init as usual, which in turn loads parameters and execute directives defined in /etc/inittab. The last thing to happen is to run the /etc/rc.local script. SysV was not designed to handle certain things well, in particular - USB devices, External storage volumes, Bluetooth devices, The cloud. It was designed for a world that was static and slow moving.
  • Upstart implements an event-driven model that allows it to respond to milestones asynchronously
  • systemd uses units and targets. A target is analogous to a runlevel in previous schemes and is composed of several units. systemd will execute units to reach a target. The instructions for each unit reside in the /lib/systemd/system/ directory. "systemd" refers to the init dæmon executable itself, namely /lib/systemd/systemd, but it also refers to the set of utilities and programs used to manage the system and services. "systemctl" is used to enable, start and disable services.

For more information, see -

File handling (gvfs)

gvfs performs basic I/O operations. It consists of two parts: a shared library which is loaded by applications supporting GIO; and gvfs itself, a collection of daemons which communicate with each other and the GIO module over D-Bus ( GIO is a new library for I/O. gvfs runs a single master daemon (gvfsd) that keeps track of the current gvfs mounts.

Gconf and Dconf

GConf (XML based database) is becoming obsolete, though older apps might still use it. Dconf is a newer BLOB based database. Gsettings is a development library used to read and write to a configuration store backend. On Linux, it uses Dconf, but on Windows, it uses the registry, and on OS X, it uses a native data store.

dconf-editor (see the screen dump) can be used to display and edit settings. From the command line, the following can be used to get the settings for (e.g.) gedit

    gsettings list-recursively | grep gedit

which produces lines like

org.gnome.gedit.preferences.editor editor-font 'Monospace 12'
org.gnome.gedit.preferences.editor insert-spaces false

According to strace, gsettings looks at least in these folders -

/usr/share/glib-2.0/schemas/gschemas.compiled
/usr/local/share/glib-2.0/schemas/gschemas.compiled
/etc/dconf/profile/user
.config/dconf/user
/etc/dconf/db/local

Clutter

Clutter is a GObject-based graphics library for creating hardware-accelerated user interfaces. It is an OpenGL-based 'interactive canvas' library and does not contain any graphical control elements. It relies upon OpenGL (1.4+) or OpenGL ES (1.1 or 2.0) for rendering. It also supports media playback using GStreamer and 2D graphics rendering using Cairo.

Clutter isn't analogous to GTK+. Only Clutter together with Mx or Nbtk can match the extent of the GTK+, which is why Clutter is used together with GTK+.

Mutter

Mutter is a window manager for the X Window System, and is in the process of becoming a Wayland compositor; it became the default window manager in GNOME 3, replacing Metacity. While Metacity uses GTK+ for rendering, Mutter uses Clutter.

The Mutter window manager can function as standalone window manager application for GNOME-like desktops, and serves as the primary window manager for the GNOME Shell desktop. Mutter is extensible with plugins and supports numerous visual effects. GNOME Shell is written as a plugin to Mutter.

Gnome shell

The Gnome Shell (/usr/bin/gnome-shell) acts as a compositing manager for the desktop, and displays both application windows and other objects in a Clutter scene graph. Much of the code of the shell is written in Javascript but uses Clutter and GNOME platform libraries via GObject Introspection and JavaScript bindings for GNOME.

Much of this structure, plus future developments, is shown on this diagram produced by Shmuel Csaba Otto Traian

MIME

MIME (Multipurpose Internet Mail Extensions) is a way to identify the format of a file and decide how it should be dealt with. Mailers and Web browsers use it. The Nautilus file manager depends on this heavily to decide which icon to use when displaying a file, and to decide what to do when the file is clicked on.

As well as dealing with file-handling, GIO also includes the GNOME mimetype system. It contains code that can detect the mimetype of files, and a database that lets you map from mimetypes to the application that can handle it. It also allows for per-user overrides of this database so that users can configure their own preferred application for different types of files.

The details matter to us here, so here goes!

MIME file contents

The Mime-related information needed by gvfs includes

  1. Data used to deduce the MIME type for a file.
  2. For each MIME type, a human language description
  3. For each application, a human readable name.
  4. For each application, information about how it should be invoked, which includes the name of the command, whether file locations should be passed as URIs or as file system paths, whether multiple files can be opened with a single command, and whether the application should be opened inside a terminal window.
  5. For each application, a list of MIME types for files that application can open when passed as command line arguments and schemes for locations it can understand as command line arguments.
  6. For each MIME type, an ordered list of preferred applications and components for each user level, from most to least preferred. This list need not include all applications that can open files of this MIME type.
  7. For some MIME types, a file name that specifies which icon to use when displaying a file of this type.

To get information about a particular file (say ~/final.pdf) you can use

  • gvfs-info ~/final.pdf
    This displays info including the following
      name: final.pdf
      type: regular
      standard::content-type: application/pdf
      standard::icon: GThemedIcon:0x612640
    
    but not a "Default app"
  • gnomevfs-info ~/final.pdf
    This displays info including the following
      Name        : final.pdf
      Type        : Regular
      MIME type   : application/pdf
      Default app : AdobeReader.desktop
    
  • xdg-mime query filetype ~/final.pdf
    returns
      application/pdf
    
    XDG aims to provide generic support for various desktop programs. I don't know whether Nautilus uses the routines, though the XML files used to set up the MIME types it uses are in standard XDG locations.

Gnome MIME defaults

Default settings for MIME type and application information are stored in several places. Some of the configuration can be extended or overridden by other modules when they are installed or by user preferences.

application/arj=xarchiver.desktop

On our system gnome seems to use /usr/share/applications/defaults.list.

The "desktop files" are files associated with icons. For example, here is /opt/Adobe/Reader9/Resource/Support/AdobeReader.desktop

[Desktop Entry]
Name=Adobe Reader 9
MimeType=application/pdf;application/vnd.fdf;application/vnd.adobe.pdx;applicati
on/vnd.adobe.xdp+xml;application/vnd.adobe.xfdf;
Exec=acroread 
Type=Application
GenericName=PDF Viewer
Terminal=false
Icon=AdobeReader9
Caption=PDF Viewer
X-KDE-StartupNotify=false
Categories=Application;Office;Viewer;X-Red-Hat-Base;
InitialPreference=9

There are also desktop files in /usr/share/applications and /usr/local/share/applications which also has a mimeinfo.cache file with contents like

[MIME Cache]
image/jpeg=gimp.desktop;kde4-okularApplication_kimgio.desktop;kde4-gwenview.desktop;imageviewer.desktop;eog.desktop;f-spot-view.desktop;
image/x-pcx=gimp.desktop;kde4-okularApplication_kimgio.desktop;imageviewer.desktop;eog.desktop;f-spot-view.desktop;

application/x-rar=file-roller.desktop;xarchiver.desktop;kde4-ark.desktop;

etc. I don't know what uses this cache file.

MIME system and user file locations

The MIME database is created from the set of files located in the $XDG_DATA_HOME/mime and $XDG_DATA_DIRS/mime directories. We have $XDG_DATA_HOME and $XDG_DATA_DIRS unset. If these environment variables are unset, they default to ~/.local/share and /usr/local/share:/usr/share respectively. Each environment variable can be a colon separated list of directories. The user's database at $XDG_DATA_HOME/mime has precedence over the system database at $XDG_DATA_DIRS/mime.

The update-mime-database program creates the default files in these system directories by reading from freedesktop.org.xml (???). Doing

  update-mime-database /usr/share/mime

updates the databases (in particular /usr/share/mime/mime.cache) under /usr/share/mime. Note that mime.cache needs to be world readable, and that the umask at install time isn't always correct.

Adding extensions to this can be done with appropriate xml files in, for instance, /usr/share/mime/packages. e.g. /usr/share/mime/packages/nautilus.xml

Rather than change the existing files, user defined mime types can be added to ~/.local/sharemime/packages/Overrides.xml

To modify the database for all users, make changes to the file Overrides.xml in a system $XDG_DATA_DIRS/mime/packages directory. After changes are made, you must always run the update-mime-database application, with the directory location of the MIME database as the first parameter.

When users change settings using the right-button on a file and change this panel
openwithprops.png
~/.local/share/applications/mimeapps.list is written to, containing something like

[Added Associations]
image/jpeg=eog.desktop;
text/plain=kde4-kopete.desktop;

[Removed Associations]
image/jpeg=kde-amarok.desktop;

These modify the initial system defaults. The first of these "Added Associations" is used as the default application for such files from then on.

Note that some apps (firefox notably) still get their MIME information from /etc/mime.types and /etc/mailcap so you may need to duplicate information.

Start-up

The /usr/share/gnome-shell has some configuation info. E.g. /usr/share/gnome-shell/js/misc/config.js has some setings for the javascript part of the gnome shell.

Nautilus

The file manager Nautilus itself is made up of several parts. Apart from the main executable there are executables and libraries for some of the components. There is also the public library libnautilus and its headers, used by third parties that want to implement nautilus extensions.

When a file is clicked on, the attributes of the file are used to figure out the default component to use for the URI. This was done by constructing a bonobo-activation query but I think D-bus is now used. Components are matched in the following order:

  • component specified in the metadata for the location (set if the user visited the location with a non-default component before), (metadata is stored as an xml file per directory in $HOME/.nautilus/metafiles). For example, the *Desktop.xml file there has
    <?xml version="1.0"?>
    <directory><file name="Trash" icon_position="64,442"/>
    <file name="ksnapshot.desktop" timestamp="1187177245" icon_position="64,522"/>
    
    etc. The metadata system is implemented as a Bonobo server that handles all accesses to the metadata files.
  • default gnome-vfs component for the mimetype
  • gnome-vfs short list of components for the mimetype
  • components that lists the mimetype or the super-mimetype (e.g. image/*) in the bonobo:supported_mime_types attribute.

Modules

Add-ons include

  • nautilus-open-terminal (lets you to open a terminal in arbitrary local folders using right-click)
  • seahorse (for PGP encryption)

p.s. nautilus produces a lot of textual output, which can bloat ~/.xsession-errors

References

Questions

  • One document said that Nautilus now uses gvfs/gio instead of gnomevfs for MIME info. Another said that Nautilus gets such info via bonobo which once used gnomevfs. Does Nautilus still use bonobo? Does bonobo still use gnomevfs?
  • How should /var/cache/gio-2.0/defaults.list and /usr/share/applications/defaults.list be synchronised?
  • Are the files under /usr/share/applications/kde4/ (in particular mimeinfo.cache) used? I think the files are, because /usr/share/ is in $XDG_DATA_DIRS, but what about the cache file?