On Wed, 14 Jan 2004 11:34:04 +0100, Michael Natterer <[EMAIL PROTECTED]> wrote:
> RaphaŽl Quinet <[EMAIL PROTECTED]> writes:
> > 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.
> As I said, that what the new gimp_statusbar_replace() API would
> be for. I'm aware of the stacking problem. It's exactly the
> issue we want to resolve here.

I don't understand how the gimp_statusbar_replace() API would
solve the problem, because one or several other messages from
the plug-in would have to be pushed or popped _under_ the
message from the measure tool because the interactive actions
from the tools should always be visible.  I may have
misunderstood how you are planning to implement this, but I
think that a stack model would cause the messages from the
tool to disappear either when a new progress message is pushed
by the plug-in (e.g., because it has called another plug-in)
or when it wants to pop its message from the stack while the
interactive message is still displayed.

> > 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.
> Limiting ourselves to what we need now is always a bad idea.

As I explained in my last message, the priorities could be
extended easily if necessary.  So we are not really limited.

> >  Unless I missed something, all
> > messages that fit in the same category would simply replace each
> > other.
> No they won't. My GimpEditSelectionTool example from the previous
> mail explains why.

Then I failed to understand why.  As far as I can see, the
GimpEditSelectionTool message is simply a priority 1 message
(GIMP_STATUS_INTERACTIVE in my proposal) that would replace
what is there, and would in turn be replaced when the action
ends and the control goes back to another part of the code.
How would that conflict with the model that I proposed?  

> > 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.
> What you propose doesn't even cover the current use cases of
> the status bar API, let alone stuff we might not even think
> about now.

I do not see why it doesn't.  I had a look at the different parts
of the code using the status bar and I think that my proposal covers
them fairly well.  But I may be wrong, of course.

As I said in my last message, I do not insist on having this
implemented in the way that I proposed.  Any solution is welcome
as long as it solves the problems that we have now.  So if you
have a better solution that allows messages to be added, removed
or replaced asynchronously, then I would be happy to use it.  It
would be nice if you could explain how your solution would solve
these problems, though.

Gimp-developer mailing list

Reply via email to