On Wed, 14 Jan 2004 11:34:04 +0100, Michael Natterer <mitch@xxxxxxxx> wrote: > Raphaël Quinet <quinet@xxxxxxxxxx> 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. -Raphaël
