Raphaël Quinet <quinet@xxxxxxxxxx> 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 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. 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. 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 only problem with the current API is that it's impossible to exchange messages without pulling them to the top of the stack. The API is fine otherwise and fits our needs. This simple approach also has the advantage that it will most probably not break anything because the code is tested and the API won't change except for the s/gtk_statusbar/gimp_statusbar/. ciao, --mitch
