http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-84.html#HEADING84-0 Suggestions for enhancing the user experience in your application: Menus: ------ - The order of the toplevel menus should be: File, , Edit, View, Game, CUSTOM MENUS, Settings, Windows, Help The Help menu should not be right-justified. CUSTOM MENUS is where you should put your application-specific top-level menus, such as Gnumeric's "Insert" menu. These are all optional except Help. - The prescribed order of standard menu items in the "File" menu is the following: New Window, SEPARATOR, New, Open, Save, Save As, Revert, SEPARATOR, Print, Print Setup, SEPARATOR, Close, Exit The first menu must always be the "File" menu (unless there are no files in your application, for example, in a game you can call this "Game"), and it must always be called "_File". The main reason for this is that it is important for the menu accelerators to be consistent. Your application is required to have at the very least a "File" menu containing at the very least "Exit". The New Window menu item should be a subtree if there are different types of new windows which can be spawned. All of these are optional, except Exit. - The prescribed order of standard menu items in the "Edit" menu is the following: Undo, Redo, SEPARATOR, Cut, Copy, Paste, Clear, Select All, SEPARATOR, Add, SEPARATOR, Find, Find Again, Replace The "Add" item should be used to insert new editable items, e.g. a new card in a rolodex app. If there is more than one type of insertable editable item, "Add" should be a menu subtree. - The View - The Settings menu should contain: . All toggles (as menu items) . All configuration dialog menu items . The standard "Preferences" menu item The order of the items in the Settings menu should be the following: Toggles SEPARATOR Configuration dialog menu items Preferences It is OK if the only item in Settings is "Preferences". Of course, if you have hundreds of toggles, use your best judgment; only put the commonly-toggled ones in the Settings menu, and use a nice Preferences dialog to contain the complete set. - The 'Windows' menu should be used by MDI applications to contain a list of the document windows. It should be structured like this: MDI window list - For standard menu items (Save, Save As, Close, Quit, etc), use the macros defined in gnome-app-helper.h, e.g. GNOMEUIINFO_MENU_EXIT_ITEM(CB, DATA) except for New where the define is: GNOMEUIINFO_MENU_NEW_ITEM(LABEL,TIP,CB,DATA) Where LABEL is the the text which appears in the menu for this menu item. You should put LABEL in the form of N_("_New Document"), or whatever is appropriate for your application. TIP should be the description of this menu item's function, e.g. N_("Create a new document"). The standard print menu item should immediately print the document without popping up a dialog. If the user wants a dialog, he will use the print_setup menu item. - For some standard toplevel menus (File, Edit, Help, etc), you should use the macros GNOMEUIINFO_*_MENU(tree). - For the help menu, you should have this: GNOMEUIINFO_HELP(app_name), GNOMEUIINFO_MENU_ABOUT_ITEM(cb, data), GNOMEUIINFO_END - Use the GnomeAppBar in your application, and provide hints for all of your menu items, including submenus. See balsa and Gnumeric for examples. - Ellipsis ("...") should be used on menu items that require the application to prompt the user for extra information before the command can execute. "Save as..." is one of these because the application needs to ask the user for the filename. "About" is not because the command *is* to pop up an about box, and it does not need to prompt for information before doing that. - Your menu hints should not have a trailing period. They should be phrased like commands, e.g. "Open a new file". Do NOT phrase them like a description, e.g. "Opens a new file". - All menu text should be internationalized. Use the N_() macro, e.g. N_("Open new mailbox") - You may notice that most of these guidelines seem geared towards "productivity" applications (editors, spreadsheets, ...). If you're writing a game, most of your menu items won't be appropriate in these menus. The solution is to create a "Game" menu which contains the game-related menu items. The contents of the Game menu are as follows: New Game, Pause Game, Restart Game, SEPARATOR, Undo Move, Redo Move, Hint, SEPARATOR, Scores, End game End game should just end the current game -- it shouldn't close the application. That's the job of File/Exit. Dialogs ------- - Use GnomePropertyBox widgets for configuring things in your application. These will allow the user to use their preferred way of configuring the application. - If you only want to ask the user a question from a set of options, you can use the gnome-messagebox code. - When creating dialog boxes, use a GnomeDialog widget, instead of a GtkWindow. - Use the gnome_dialog_set_parent routine if possible, to "bind" your dialog boxes to your main toplevel window (this allows window managers to hide all of your dialog box windows when minimizing your main window for example). - For file-input entry widgets, use the GnomeFileEntry widget, this will provide a browse selector (and in the future it will use the enhanced file open dialog box). - When you require an entry for typing in an icon name, use the GnomeIconEntry widget. - For text-input that might benefit from a history, use the GnomeEntry widget (this will provide automatic history for you). - Use the GnomeAbout dialog. Be sure to include an email address for reporting bugs and the copyright notice. About dialogs should: 1. Not be modal. 2. Allow one and only one instance of the dialog to be open at a time. 3. If the user selects the About command while a previous about box is open, then it should be gdk_window_raise()d. General Widget Use ------------------ - Use the GnomeApp widget for your toplevel windows. - Use the gnome-app-helper.h interface for creating menus and toolbars. If you use this, the task of creating Baboon-aware applications will be reduced. - Use GnomePixmap to load your images. - Try to use consistent spacing and padding everywhere. libgnomeui/gnome-uidefs.h has some preset values you should use. Miscellaneous ------------- - GNOME uses Imlib, so try to provide your images in PNG format. You do not need to care about the color usage, Imlib will dither to a nice palette if necessary. Internationalization -------------------- - Tag any strings in C statements with _(...) and with N_(...) for static initializers to allow your application messages to be localized. Session management ------------------ - Make your application support session management. Top Level Windows ----------------- - Make sure you call gtk_window_set_wmclass() on ALL top-level GtkWindows you create. The first string is the name, the second the class. Please ensure you have the class as something like the name of the app, and the name being the type of window it is - like ``filename_dialogue'' or ``main_window'' etc. Ensure you make calls like: gtk_window_set_wmclass(GTK_WINDOW(window), ``file_open_dialogue'', ``my_ap_name'');