A little addition to what I wrote yesterday...
The stack model for the GimpStatusbar is well suited for plug-ins
because they have a strict nesting order, but it does not work well
when this has to be mixed with changes that can happen asynchronously
because this would require messages to be pushed or popped above or
below the current element, so this would break the strict stacking
order. I wouldn't mind if we could keep some of the existing API
because that would minimize the changes to the code (and also because
Mitch would probably do the work and I wouldn't have to implement my
proposal so that would be less work for me ;-)). But I don't think
that the addition of a simple ..._replace() function would be
sufficient if we have to break the stacking order.
The API that I propose would look as follows. The details such as the
names (_set() or _update()) could change and there would still be a
function for updating the coords, although its parameters could be a
bit different from the current ones.
typedef enum
{
GIMP_STATUS_INTERACTIVE = 1, /* interactive (modal) operations */
GIMP_STATUS_PROGRESS = 2, /* progress from plug-ins, etc. */
GIMP_STATUS_TOOLHELP = 3, /* description of current tool */
GIMP_STATUS_DEFAULT = 4 /* customizable message */
} GimpStatusbarType;
void gimp_statusbar_set (GimpStatusbar *statusbar,
GimpStatusbarType message_type,
const gchar *message,
guint duration);
void gimp_statusbar_clear (GimpStatusbar *statusbar,
GimpStatusbarType message_type);
The duration parameter could be used to specify that a message should
be cleared automatically after N milliseconds, unless another message
has already replaced it (at that priority level). This would allow
the caller to display a message for up to 3 seconds (for example)
without having to care about when to clear it. This could be used for
the GIMP_STATUS_TOOLHELP messages if we want to display the help for
the current tool during a few seconds (renewed each time one switches
tools or changes the tool mode, etc.) and still allow the default
messages to be shown after a while. Another option would be to clear
the GIMP_STATUS_TOOLHELP messages when the window loses the input
focus, as I suggested yesterday. Then we would not need to limit the
duration of these messages.
This mechanism based on priority levels could be extended easily. For
example, let's say that we want to add another type of messages that
have a very high priority and are only displayed for a brief moment.
This could be used for warning messages such as: "Swapped 666 MB of
tile data to disk - memory low". This could be done by adding a new
value GIMP_STATUS_SYSTEM = 0 in the enum above. These messages could
then be displayed briefly (short duration) while a plug-in or some
other memory-consuming task is running. Using fixed priority levels
instead of a stack allows these asynchronous messages to be displayed
without having to care about the number of push/pop calls in the lower
levels while that message is displayed or updated.
If we still want to use a stack model in order to minimize the API
changes, then a solution could be to use more than one stack or to use
special cases for the interactive messages in order to allow them to
be updated regardless of what happens with the stack of messages from
plug-ins, etc. That could also solve the problem of asynchronous
updates.
Anyway, the API and even the model are not very important, as long as
the functionality is there. So I am open to other suggestions. But I
would like the API to be available soon so that I can work on fixing
the bugs that require the updated GimpStatusbar API.
-Raphaël
