Application Integration

GNOME 3 brings a renewed focus on delivering a beautiful, integrated, and cohesive user experience with a Free Software OS. 3.0 is the beginning, where we have started to shape the user experience with new designs for many core OS components. We have tried to limit the redesign, initially, in order to properly focus our efforts and ensure all of our important partner applications will continue to run without significant modification. We expect that once we have demonstrated our vision for the GNOME core we will refocus our energy and enthusiasm on resigning application guidelines.

Your application will continue to run in GNOME 3.0 without any changes. However, there are a number of things you can do to ensure your application appears and performs at its best.

Toolkit use

GNOME 3 ships a visually compatible GTK+ 2 theme, but minor differences will remain. Porting your application to GTK+ 3 will ensure seamless visual appearance with the rest of the desktop. In addition you will gain other benefits that come with GTK+ 3, such as more flexible size allocation, better (multi-)device support, new widgets, etc.

GTK+ 3 comes with a porting guide that can be found here: http://library.gnome.org/devel/gtk3/stable/gtk-migrating-2-to-3.html

Application Naming

Giving your application a good name is important, since the name is often the first thing a user will see of your application. For a thoughtful essay on the factors involved in choosing a good name, see http://blogs.gnome.org/mccann/2009/08/08/whatchamacallit/

You should also make sure to use your application name consistently. The desktop shell will pick up the name of your application from its desktop file, while GTK+ itself will rely on you to call g_set_application_name(). You should make sure that the name in the desktop file and the one passed to g_set_application_name() are the same.

Application Tracking

In order to correctly display your application launcher, icon, and name the OS needs to know about your application. http://live.gnome.org/GnomeShell/ApplicationBased

Application Categorization

It is also important to correctly categorize your app, since various things rely on desktop file categories:

• If it is part of the core GNOME desktop (very unlikely): Include Core and System
• If it is a control-center panel (very unlikely): Include Settings and X-GNOME-Settings-Panel
• If it is a core utility (unlikely): Include Core and Utility
• If it is an application: Don't include Core and X-GNOME-Settings-Panel

AppMenu Integration

Starting with 3.4, GNOME will provide a facility for application customization of the application indicator area. http://developer.gnome.org/gtk3/3.3/GtkApplication.html explains the APIs that you can use to show your own items in the app menu.

Icon Usage

Review you applications use of icons in light of GnomeOS/UX/Guidelines/SymbolicIcons

One important icon to choose is a good hi-res application icon, to make your app look good in the shell overview.

Status Icon Usage

If your application uses a status icon, consider dropping it, or only using it if the notification daemon does not support persistent notifications. For more information, see http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility

Notifications

You should investigate some of the other new possibilities offered by version 1.2 of the notification spec such as persistent and transient notifications. These are implemented both by gnome-shell and the latest notification-daemon. Recommendations for many applications can be found here: http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility

Use of Dialogs

If your application is using dialogs, make sure to properly set a transient parent and make them modal where appropriate. This is important because the shell is showing dialogs attached to their parent window.

If you are up for more far-reaching changes, you could drop by on #gnome-design on IRC and let the designers help you find a solution that avoids the need for popping up dialogs.

For an analysis of dialog usage throughout the GNOME stack, see http://live.gnome.org/GnomeShell/Design/Whiteboards/SystemDialogs/Compatibility

Application Data

Application data should be stored according to the XDG Base Directory Specification.

Per User Data

• Configuration files should be stored in $XDG_CONFIG_HOME - use g_get_user_config_dir()

• Runtime files (sockets, locks, mounts, etc) should be stored in $XDG_RUNTIME_DIR - use g_get_user_runtime_dir()

• Cached data should be stored in $XDG_CACHE_DIR - use g_get_user_cache_dir()

• [proposed] Add-ons, plugins, modules, libraries should be stored in $XDG_LIB_HOME - use g_get_user_lib_dir()

• Other application data should be stored in $XDG_DATA_HOME - use g_get_user_data_dir()