Whole document tree
Chapter 9. Talking to the user: GnomeDialog, GnomeMessageBox, GnomeAppBar, and utility functions.
9.1. Introduction
Gnome strives to provide the user with a maximum level of configurability, and the programmer with a maximum level of convenience. Happily, these two goals tend to go hand in hand: fewer decisions for the programmer means more decisions for the user.
This section describes Gnome's facilities for communicating simple messages or questions to the user, and retrieving a response. The main widgets involved are GnomeDialog and GnomeAppBar (a statusbar, but that name was taken). Gnome also provides convenience functions which give the user greater choice as a side effect. For example, if you call gnome_app_message() instead of creating a dialog directly, the user can request that messages appear in the app bar instead.
Some functionality is missing, and some of the API is suboptimal. Hopefully this will be fixed eventually. In particular:
GnomeAppBar does not work in interactive mode, so all questions must be asked via dialog. Full Emacs-minibuffer-style functionality needs to be added.
GnomeAppBar should use GnomePreferencesType for its has_progress parameter, and not use a progress bar if the user wants progress dialogs instead.
Nonstandard function pointer callbacks are a poor substitute for Gtk signals and unpleasant in non-C bindings. One possible solution is to create a GtkObject to represent the user interaction, complete with signals. GnomeQuestion, for example, with a "answered" and "cancelled" signal. More complex, but more flexible.
It is all sort of clunky feeling. Perhaps convenience functions are inherently inelegant?
Patches and suggestions are always welcome. Please think about how the API could be improved as you read this and use the facilities, then send along your thoughts.