A little addition to what I wrote yesterday...
The stack model for the GimpStatusbar is well suited for plug-ins
because they have a strict nesting order, but it does not work well
when this has to be mixed with changes that can happen asynchronously
because this would require messages to be
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)
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
Hi,
Raphal Quinet [EMAIL PROTECTED] writes:
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
On 14 Jan 2004 13:25:44 +0100, Sven Neumann [EMAIL PROTECTED] wrote:
Raphaël Quinet [EMAIL PROTECTED] writes:
I don't think that the tool status always being visible is mandatory.
IMO it would be sufficient to be able to replace messages. Tools will
set the statusbar every so often anyway.
Raphaël Quinet [EMAIL PROTECTED] writes:
I would like to fix several bugs related to the usage of the status
bar in the image windows. There is bug #120175 proposing to update
the GimpStatusbar API, and bugs #51108 and #124040 that could be
easily solved by displaying help messages for all
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
