Re: [Gimp-developer] Proposal for fixing the GimpStatusbar API
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 pushed or popped above or below the current element, so this would break the strict stacking order. I wouldn't mind if we could keep some of the existing API because that would minimize the changes to the code (and also because Mitch would probably do the work and I wouldn't have to implement my proposal so that would be less work for me ;-)). But I don't think that the addition of a simple ..._replace() function would be sufficient if we have to break the stacking order. The API that I propose would look as follows. The details such as the names (_set() or _update()) could change and there would still be a function for updating the coords, although its parameters could be a bit different from the current ones. typedef enum { GIMP_STATUS_INTERACTIVE = 1, /* interactive (modal) operations */ GIMP_STATUS_PROGRESS= 2, /* progress from plug-ins, etc. */ GIMP_STATUS_TOOLHELP= 3, /* description of current tool */ GIMP_STATUS_DEFAULT = 4 /* customizable message */ } GimpStatusbarType; void gimp_statusbar_set (GimpStatusbar *statusbar, GimpStatusbarType message_type, const gchar *message, guint duration); void gimp_statusbar_clear (GimpStatusbar *statusbar, GimpStatusbarType message_type); The duration parameter could be used to specify that a message should be cleared automatically after N milliseconds, unless another message has already replaced it (at that priority level). This would allow the caller to display a message for up to 3 seconds (for example) without having to care about when to clear it. This could be used for the GIMP_STATUS_TOOLHELP messages if we want to display the help for the current tool during a few seconds (renewed each time one switches tools or changes the tool mode, etc.) and still allow the default messages to be shown after a while. Another option would be to clear the GIMP_STATUS_TOOLHELP messages when the window loses the input focus, as I suggested yesterday. Then we would not need to limit the duration of these messages. This mechanism based on priority levels could be extended easily. For example, let's say that we want to add another type of messages that have a very high priority and are only displayed for a brief moment. This could be used for warning messages such as: Swapped 666 MB of tile data to disk - memory low. This could be done by adding a new value GIMP_STATUS_SYSTEM = 0 in the enum above. These messages could then be displayed briefly (short duration) while a plug-in or some other memory-consuming task is running. Using fixed priority levels instead of a stack allows these asynchronous messages to be displayed without having to care about the number of push/pop calls in the lower levels while that message is displayed or updated. If we still want to use a stack model in order to minimize the API changes, then a solution could be to use more than one stack or to use special cases for the interactive messages in order to allow them to be updated regardless of what happens with the stack of messages from plug-ins, etc. That could also solve the problem of asynchronous updates. Anyway, the API and even the model are not very important, as long as the functionality is there. So I am open to other suggestions. But I would like the API to be available soon so that I can work on fixing the bugs that require the updated GimpStatusbar API. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal for fixing the GimpStatusbar API
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. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal for fixing the GimpStatusbar API
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 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. 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 from the tools should always be visible. I may have misunderstood how you are planning to implement this, but I think that a stack model would cause the messages from the tool to disappear either when a new progress message is pushed by the plug-in (e.g., because it has called another plug-in) or when it wants to pop its message from the stack while the interactive message is still displayed. 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. As I explained in my last message, the priorities could be extended easily if necessary. So we are not really limited. 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. Then I failed to understand why. As far as I can see, the GimpEditSelectionTool message is simply a priority 1 message (GIMP_STATUS_INTERACTIVE in my proposal) that would replace what is there, and would in turn be replaced when the action ends and the control goes back to another part of the code. How would that conflict with the model that I proposed? 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. I do not see why it doesn't. I had a look at the different parts of the code using the status bar and I think that my proposal covers them fairly well. But I may be wrong, of course. As I said in my last message, I do not insist on having this implemented in the way that I proposed. Any solution is welcome as long as it solves the problems that we have now. So if you have a better solution that allows messages to be added, removed or replaced asynchronously, then I would be happy to use it. It would be nice if you could explain how your solution would solve these problems, though. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal for fixing the GimpStatusbar API
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 from the tools should always be visible. 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. At this point we are not seeking for a perfect solution but for a quick fix for 2.0. The proposal that needs the smallest amount of changes should definitely be favored at this point. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal for fixing the GimpStatusbar API
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. That's right. It would still be a problem if the interactive message from the tool has to compete with a plug-in updating the message showing its progress, but this is not a very serious issue for the moment. At this point we are not seeking for a perfect solution but for a quick fix for 2.0. The proposal that needs the smallest amount of changes should definitely be favored at this point. OK, I agree. Let's use a quick fix for 2.0 and then see how the API can be improved later (e.g., for 2.2). So I will try to work on bug #124040, assuming that bug #120175 could be fixed soon. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2 news ...
On Tue, Jan 13, 2004 at 11:32:21AM +0100, Sven Neumann wrote: Roman Joost [EMAIL PROTECTED] writes: I looked at http://www.sagehill.net/docbookxsl/UseCatalog.html#d0e3162 and it seems for me, that we don't need a DTD declaration on top of gimp.xml if the catalog file is present and the corresponding environment variable is set. I tried to build the manual after removing the declaration and the translation process works fine. If this would work on other machines, i'll remove the DTD declaration on top of gimp.xml. You loose the ability to validate the file w/o explicitely specifying the DTD file. Also I am surprised that you can process the file w/o the DTD. Aren't you using any entities? What would be the advantage of removing the DTD declaration? We don't use entities anymore (except for one in gimp.xml). I thought, that the advantage of removing the DTD declaration would be no more hassles with building the manual. The XML book from www.sagehill.net explains, that a (correct) catalog file would be the best of both - local and network DTD. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature