[Gimp-developer] gimpmisc cvs fixes.
Hi, as you may know, the files libgimp/gimpmisc.[ch] have been split into libgimp/gimppixelfetcher.[ch] and libgimp/gimpregioniterator.[ch]. Can you do the necessary changes to keep cvs history for these files? This is something like copying gimpmisc.c,v and gimpmisc.h,v directly on the CVS server. Thanks, DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2 news ...
Hi, 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. Are there any concerns about that or do i missed something? 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? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimpmisc cvs fixes.
On Tue, Jan 13, 2004 at 10:41:46AM +0100, David Odin wrote: Hi, as you may know, the files libgimp/gimpmisc.[ch] have been split into libgimp/gimppixelfetcher.[ch] and libgimp/gimpregioniterator.[ch]. Can you do the necessary changes to keep cvs history for these files? This is something like copying gimpmisc.c,v and gimpmisc.h,v directly on the CVS server. Done. In the future, it's smoother to take care of this before you commit the new files. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-freetype plugin
Hi,
Owen [EMAIL PROTECTED] writes:
I just downloaded the freetype plugin from CVS and received
./configure: line 3628: syntax error near unexpected token `1.3.23,'
./configure: line 3628: `AM_PATH_GIMP_2_0(1.3.23, , { { echo
$as_me:$LINENO: error: Cannot find GIMP-2.0. 5'
This is a known problem with gimp-2.0pre1. You cannot compile plug-ins
using AM_PATH_GIMP_2_0() against 2.0pre1. This has been fixed in CVS
and we will release 2.0pre2 shortly so that people can port their
plug-ins to the 2.0 API.
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimpmisc cvs fixes.
Hi, David Odin [EMAIL PROTECTED] writes: as you may know, the files libgimp/gimpmisc.[ch] have been split into libgimp/gimppixelfetcher.[ch] and libgimp/gimpregioniterator.[ch]. Can you do the necessary changes to keep cvs history for these files? This is something like copying gimpmisc.c,v and gimpmisc.h,v directly on the CVS server. That should have been done beforehand, not afterwards. I don't think that loosing the CVS history is a problem here, so don't worry. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] unirectangle selection tool
Hello. The GIMP does not compile in my Linux and thus I cannot fully develop the tool myself: Unirectangle selection tool -- Select one rectangular region I post the design later, but now I would like to know why the crop tool and the Bezier selection tool are not visible in all views of the image? I want my selection tool to be visible in all views. The reason why a selection is visible in all views, is because the selection is a mask. Likewise, I want the tool to be on the image object, not on a view object. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Proposal for fixing the GimpStatusbar API
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 ___ 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: 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 ___ 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 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. Why should we use a dynamic stack if we know in advance how many slots it would have? 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. 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. Unless I missed something, all messages that fit in the same category would simply replace each other. 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. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimpmisc cvs fixes.
On Tue, Jan 13, 2004 at 02:32:50AM -0800, Manish Singh wrote:
On Tue, Jan 13, 2004 at 10:41:46AM +0100, David Odin wrote:
Hi,
as you may know, the files libgimp/gimpmisc.[ch] have been split into
libgimp/gimppixelfetcher.[ch] and libgimp/gimpregioniterator.[ch]. Can
you do the necessary changes to keep cvs history for these files? This
is something like copying gimpmisc.c,v and gimpmisc.h,v directly on the
CVS server.
Done. In the future, it's smoother to take care of this before you commit
the new files.
Oh. Didn't know this. I'll remember this.
Thanks.
DindinX
--
[EMAIL PROTECTED]
/D{def}def /d{.00017 add D}D /C{2 copy dup mul exch dup mul}D /g 150 string
D /y .29 D 150 150 8[.4 0 0 .4 -45 -90]{/x -1.2 D 0 1 149{x y /n 300 D{/n n
5 sub D C exch sub x add 3 1 roll 2 mul mul y add C add 4 gt n 5 eq or{exit
}if}loop pop pop g exch n put /x x d}for /y y d g}image showpage
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
