IMPORTANT IMPORTANT IMPORTANT This is a work in progress. It is not finished. It started as a brain dump of FedericoMenaQuintero's ideas about how to let ISVs know whether their apps are gnome-friendly or not. So don't go cooking conspiracy theories about freedesktop.org, gnome.org, or anything like that.

1. Introduction

This was discussed during the GNOME Foundation Board meeting at GUADEC 2005. The idea is to be able to answer this question: What is a GNOME application?

To answer the question, we can define a few levels of certification. The most basic, obvious level would be something like "the app runs under GNOME, and it is accessible through the panel's menus". The most sophisticated level would probably include using GTK+ as the GUI toolkit, using gnome-vfs, GConf, etc.

In the end, we can probably have certification images or logos which people can rubber-stamp on their apps. This looks nice and strengthens the GNOME brand. Users can then know what to expect from "certified" applications: those with low certs will at least run on Gnome; those with high certs will provide a pleasant, polished experience. This is about branding, marketing, and along the way we might come up with a nice list of things you need to do to make your apps as nice as possible.

The IdealDeveloperDocumentation would help with this.

2. To-do list

• Think of friendly, understandable names for the different certification levels; numbers are just placeholders for now.
• Think of how to test for compliance. Can we have automated tools, or is a simple checklist enough?
• Be more specific. We need good descriptions for every point.

• Link to documentation, standards, etc. this blog entry has a good start.

• what do we need to let people rubber-stamp "Certified for GNOME" on their products? (from a legal point of view, eg)

• Merge Javier's porting guide/guidelines into this page

3. Level 0

• The app runs under a GNOME session, and doesn't do idiotic things like taking over the whole screen or preventing interaction with the rest of the desktop. Do we need to consider full-screen games at all?

  • MikeHearn: Yes, there are several ways games can go full-screen, only one of them (using the NETWM hint) is correct. Also games like to change screen resolution using XrandR but GNOME is a bit buggy in this regard, the panel tends to re-arrange launchers when the desktop resizes. It might be nice to have an XrandR protocol extension that can tell the WM not to resize every window on the screen so temporary resolution changes don't reconfigure the desktop.

    • DanWinship: Ooh, yes, an app should be able to say "this is a full-screen window to be displayed at resolution X", and then when the window closes (for whatever reason, even if it's because its app crashed), the resolution will switch back automatically.

• The app installs a .desktop file as per the freedesktop.org desktop file standard. The app can thus be run through the panel's menus.

• The app follows the freedesktop.org MIME standard. It lists the MIME types it supports, and installs icons for any custom MIME types it may support. FIXME: link to the MIME and icon specs.

4. Level 1

• The app uses GNOME standard dialogs. FIXME: which ones? OpenOffice and Firefox can be made to use GtkFileChooser, at least.

  • AlanHorkan I think the important point here is they use the standad API for things like the File Chooser and About Dialog. Then they can provide alternatives that use the standard API but it need not be all or nothing. If we dont allow GPE applications might technically fail this test.

• Anything else for very basic integration which uses minimal parts of the GNOME platform?

5. Level 2

• The app uses GTK+ as its GUI toolkit, using the stock controls (as opposed to just using GTK+ as a drawing engine for a custom widget toolkit).

• Use filename encodings correctly. (This could probably go in level 1, as a derivation of apps being required to use GtkFileChooser)

6. Level N: things which lead to nice apps

I'll put everything here, and then try to sort it by how gradually one can implement things. For example, adding support for simple drag-and-drop of files is easier to do than writing complete online help.

Sorted, more or less:

• Use libglade rather than code generation in Glade. FIXME: what about crazy apps which don't use Glade at all?
• Drag files from Nautilus into the program.
• Support recent-files.

• I18n in general: see GnomeI18nDeveloperTips. APIs in which people forget to set gettext domains, situations in which the domains must be explicitly set rather than using the domain from the main program, etc.

• Follow the HIG. The HIG checklist should be expanded.

• Work with high contrast / large print / inverse themes.
• Accessibility.

Unsorted:

• Use gnome-vfs for accessing user files.
• Use GConf to store settings.
• Lockdown.
• Session management.

• Use GnomeProgram correctly (pass all the magic macros, etc.). What does this actually give us? MurrayCumming. FedericoMenaQuintero: It lets your program work when installed to a different prefix, since various libraries use the GnomeProgram functions directly or indirectly to find the locations of installed files.

• Gnome-keyring if you use passwords.

• Help -- user documentation that makes use of GNOME's help viewer, Yelp

• Right-to-left.
• Make custom stock icons themable.
• Thumbnailers.
• Use the clipboard manager (as per the freedesktop spec. For instance, via the GTK+ API)

Miscellaneous:

• GTK+ good citizen's checklist. FIXME: FedericoMenaQuintero has this list, and Søren has interesting stuff as well.

• Notification area behaviour?

DavidMalcolm: I think we should recommend the use of GTK 2.*, rather than GTK 1.*, and talk about avoiding the deprecated widgets. Should this go in "level 2" above (part of usage of GTK)?

7. A Possible Process of Certification

Note: This is a braindump. It is written from my perspective (someone who has lurked aroung GNOME for 1-2 years) who now is starting to develop their own apps. I am 22 and at university and in general aggree with the sentiments expressed here (re: the future developers of GNOME)

It is hard to quantify what the GNOME Foundation Board does. I appreciate they are volunteers. Having been in volunteer administrative roles myself I know that often too much time is spent firefighting leaving little time left for strategizing. The problem with this is

• Firefighting is invisible (people wonder what it is the foundation does)

• Not enough strategizing leads to confusion, people feeling like this

• Not enough strategizing leads to arguments about where to go next. Too many chiefs and not enough indians.

The Symptoms:

Every time a new release comes around there is the huge discussion on ddl about includion of new modules. These fall into 2 categories;

1. Flamewars regarding signigant introduction of new pieces of technology (frameworks, mono, python, desktop search, etc)
2. Comments on changes that proposed apps will need to make that will make them more suitable for inclusion (alacarte, deskbar, etc)

Some Solutions??:

Im not sure that 1 can be solved easily. Perhaps a BDFL is needed?. Perhaps the Foundation needs a steering committee.

I believe that 2 can be solved through some Gnome Certification process. I envision that any application can be submitted to the GNOME Foundation Steering/Review committee. It is their JOB to spend a few hours looking over the application to determine its level of compliance to the goals allready outlined in this page. At the end of the certification process the foundation places their thoughts on a page somewhere in this wiki and the application author can make changes to the application as needed.

This process isnt really all that different to what happens now. It is just a formalising of some things, the completion of the specs on this page, and the publication of stuff in a public place. Then at least some policy is in place. For example for inclusion into the GNOME release (whatever that is, whatever ReleaseSet, etc) requires GNOME certification. That way discussion on ddl will be restricted to a smaller subset of flaming - the application will at least be of known good qulity.

The Outcome??:

• GNOME Certified Applications can be listed on the (forthcoming) [GnomeWeb/GnomeProducts].

• Only GNOME Certified Applications can be included in a release set

From my perspective (a budding app author) It provides me with

• Direction. Complete these x steps and you will have a GNOME Certified Appliction (Good!)
• Motivation. There is a certain enigma and respect surrounding getting an application into the release
• A Concrete example of what the GNOME Foundation Does.
• Confidence that GNOME has a grand vision (or at least the mechanisms in place to recognise it when it comes out of the murky haze of developers imaginations)