[Gimp-developer] Proposal for fixing the GimpStatusbar API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 tools in the status
bar (like the path tool does now).  The first issue is to fix the API
because the best way to fix the other bugs would be to use a better
GimpStatusbar API.

I have checked a bit how the status bar is used in the current code
and tried to find a way to solve the problem described in bug #120175,
which applies not only to plug-ins but also makes it very hard or even
impossible to see the coordinates when you are moving a selection.  I
don't think that the current model using gimp_statusbar_push() and
gimp_statusbar_pop() (inherited from GtkStatusbar) is the best
solution.  Adding just one function gimp_statusbar_replace() could
improve it a bit (if the context_id is known by all parts of the code
that need it), but it would be better to reconsider the model.

I propose to change the GimpStatusbar model so that instead of using a
variable stack, it uses several pre-defined priority levels (using
some global enum, e.g. GimpStatusbarType).  Each part of code that
wants to update the status bar would just set or clear the message for
its own level and there would be no push/pop.  The status bar would
always display the message that has the highest importance.  A part of
the code could update a low-priority message (e.g., help for the
current tool) while another message of higher priority is still being
displayed (e.g., progress for a plug-in).  As soon as that message is
cleared, the low-priority one would become visible.  This is not
possible with the current implementation.  Another advantage of using
pre-defined priority levels is that all parts of the code could use
them directly instead of having to pass a context_id or something
similar to different parts of the code.

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.

Regarding the implementation, the GimpStatusbar would keep an array
containing the message for each priority level.  If we still want to
derive from GtkStatusbar, then the code in gimpstatusbar.c would take
care of calling gtk_statusbar_push()/_pop() when necessary, i.e. when
the visible message (highest priority) changes.

Is it a reasonable proposal or am I completely off-track?  If this
proposal is acceptable, then I could work on it and also propose a
list of help messages for all tools in order to solve bugs #51108 and
#124040.

-Raphaël

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux