On Tue, 13 Jan 2004 18:15:38 +0100, Michael Natterer <[EMAIL PROTECTED]> wrote:
> RaphaŽl Quinet <[EMAIL PROTECTED]> writes:
> > Here are the priority levels that we need, 1 being the highest
> > priority:
> > 1) Messages from interactive operations (short duration) such as the
> >    size or offsets displayed by the selection tools, move tool, crop
> >    tool, blend tool or measure tool.
> > 2) Messages from plug-ins processing the image.
> > 3) Default messages, which would be the help messages for the current
> >    tool.  This would replace the custom messages showing the layer
> >    name, size, etc.
> >
> > Alternatively, we could use 3) for tool-specific help messages only
> > when the image window has the input focus, and 4) for the user-defined
> > status messages, shown only when the image window is not the active
> > one.
> Actually, I would keep the API, copy the implementation from
> GtkStatusbar to GimpStatusbar, rip what we don't need and add
> one single new function: gimp_statusbar_replace(), which would
> replace the message with the given ID and keep the stacking
> order of the statusbar intact.

I considered that (because that's what you suggested in bug #120175)
but it would require all parts of the code to have the correct
context_id and I don't think that it would work better than what I
proposed.  Why should we use a dynamic stack if we know in advance
how many slots it would have?  Also, my proposal allows the
following scenario to work as the user would expect:
- start with the initial default message;
- run a plug-in that displays some progress information;
- while the plug-in is running, use the measure tool to check
  something in the image and keep the mouse button down: the
  info from the measure tool replaces the plug-in info;
- the plug-in ends: the cancel button is back to normal, but the
  info displayed is still from the measure tool;
- release the mouse button: the default message is back, there
  is no conflict with the info from the plug-in.
A pure stack model would not work well in this case.

> The reason why we won't get away with fixed priorities is
> that we can't know them beforehand. E.g. the GimpEditSelectionTool
> would want to push its messages on top of everything that
> is already there (e.g. the GimpMoveTool message on top of the
> default message).

The point of my proposal is that I believe that we _do_ known
the priorities in advance, so we do not need a dynamic stack to
be exposed in the GimpStatusbar.  Unless I missed something, all
messages that fit in the same category would simply replace each
other.  In the case that you describe, you would simply replace
the level 1 message instead of pushing another one on top of it.
The user can only perform one interactive operation at a time
(typically, an operation during which the mouse is grabbed, such
as when you are dragging something) so it makes sense to simply
replace the level 1 message when the current operation changes.
And as soon as it is finished, then you get back to the level 2,
3 or 4.  Unless you immediately start another operation that
changes the level 1 message.

Gimp-developer mailing list

Reply via email to