RaphaŽl Quinet <[EMAIL PROTECTED]> writes:

> 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.

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.

Gimp-developer mailing list

Reply via email to