Raphaël Quinet <quinet@xxxxxxxxxx> writes: > 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. Look at the current code. Nobody has to remember the status ID. That's exactly the state I want to keep. > Why should we use a dynamic stack if we know in advance > how many slots it would have? As I explained in my previous mail we do *not* know how man slots we need. Also having a static array instead of a dynamic list sounds more than unelegant. We try to hack widgets in a more general manner to enable gimp-like apps to be built on them in the future. > 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. >> 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. Limiting ourselves to what we need now is always a bad idea. > 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. > 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. ciao, --mitch
