On Tue, 13 Jan 2004 18:15:38 +0100, Michael Natterer <mitch@xxxxxxxx> wrote: > Raphaël Quinet <quinet@xxxxxxxxxx> 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. -Raphaël
