[Gimp-developer] a new book about GIMP (in French)
A new book about GIMP will be published to-morrow. Unfortunately for many readers of this list, it's in French. However, an English version will be published by No Starch during next summer. Look at the following: http://compagnons.pearson.fr/gimp/ http://www.amazon.fr/gp/product/2744023051/ref=s9_simh_gw_p14_d6_i1?pf_rd_m=A1X6FK5RDHNB96pf_rd_s=center-4pf_rd_r=1CRWYQ2TYT9M9MHB7R0Rpf_rd_t=101pf_rd_p=463375613pf_rd_i=405320 -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
We are not speaking about the same thing. The fact that you want to change some channels in some color model does not mean that the internal representation of images must be based on this color model. You need tools for generating a proper CMYK representation of you image, suited to your printing shop hardware, but that does not mean that the image you handle must use this representation from the beginning. RGB is the internal representation of the images. It's also a color model, not especially suitable for manipulating colors. Thus you need tools that handle the image in more convenient color spaces. When you define a color using the color chooser, I suppose you work in HSV, not RGB? 2011/3/8 Bogdan Szczurek thebod...@gmail.com or better yet: Lab? ;] Anyway CMYK is neccessary too... W dniu 2011-03-08 10:08 użytkownik Ofnuts ofn...@laposte.net napisał: On 03/08/2011 08:46 AM, Olivier wrote: 2011/3/8 Michael Grosberg grosberg.mich...@gmail.com ... Could you explain why retouching photos should be made in RGB rather than HSV/HSL :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
2011/3/8 Michael Grosberg grosberg.mich...@gmail.com Debi Rapson drapson at mansd.org writes: Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. Hmm. GIMP is not well suited for professional photo retouching - it lack the necessary CMYK color model (among other things). I'm not sure what the focus of your program is but if you're looking for real-world use I would look more into video game art creation or online content. Could you explain why retouching photos should be made in CMYK rather than RGB? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
2011/1/5 Martin Nordholts ense...@gmail.com That is not necessary, the reason I haven't hacked on GIMP the last two months is that I am working on a website which will allow people to easily track progress of GIMP development (or any project for that matter). I expect to be back working on single-window mode in 1-3 months. What could be the implications on the date of the future release of version 2.8? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] brush tool artefacts = slow brush tools
2010/10/10 Sven Neumann s...@gimp.org On Sun, 2010-10-10 at 17:24 +0200, Olivier wrote: There are no longer brush tool artefacts on the canvas, which is very good. Unfortunately, and maybe this is because of the repair, the brush tools are now very slow. Olivier, please, this is ongoing development. And yes, we are using the application that we are developing. And yes, we notice such problems. There is really no need to tell us about each and every problem you encounter with current git. In particular not if there's already a bug-report on it. Please forgive me for the bothering. I do know that GIMP is in development, and I'm following the process as close as I can, so that the book I'm preparing will be published as soon as possible after 2.8 delivery. I'm only trying to be helpfu to the developers, and some times I signaled a problem not yet discovered. This time, as soon as I saw that the bug about brush artefacts was fixed, I made a try and sav the slowness problem. I was not aware of the other bug report, and I did the mistake of not checking before. I don't really know what is the best way to signal problems without bothering the developers: the gimp-developer list, the IRC channel, or bugzilla ? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] exporting to GIF
In the current git version, exporting to GIF an image in RGB mode does not offer the opportunity to specify a way to change the mode to indexed. The conversion occurs silently. Should not at least a warning message pop up? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] exporting to GIF
2010/10/6 Martin Nordholts ense...@gmail.com On 10/06/2010 03:48 PM, Olivier wrote: In the current git version, exporting to GIF an image in RGB mode does not offer the opportunity to specify a way to change the mode to indexed. The conversion occurs silently. Should not at least a warning message pop up? We can safely assume that our users knows the limitations of the GIF format. Of course! And if we want to add a warning message, it shall not be in the form of an annoying popup. Certainly, but in what form? Giving a way to choose the palette in the dialog that opens would be useful. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] current git version: weird behavior of the eraser and clone tools
Look at this part of a screen capture: http://olecarme.homelinux.net/Capture.png GIMP is the git version from two days ago, on Ubuntu 10.04. The traces on the image are only artefacts, left by the clone tool in this case, but the eraser has the same effect. They disappear if you minimize the image, or change to another desktop and come back. The healing tool also cleans it. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fade has a blocking dialog
I'm not sure whether this is a bug or a feature: although most GIMP dialogs are not-blocking ones (i.e. you can leave the dialog open and do something else), the Image: Edit - Fade dialog is blocking. It happens in the current git version, but maybe also in the stable version. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fade has a blocking dialog
2010/10/4 Sven Neumann s...@gimp.org On Mon, 2010-10-04 at 15:01 +0200, Olivier wrote: I'm not sure whether this is a bug or a feature: although most GIMP dialogs are not-blocking ones (i.e. you can leave the dialog open and do something else), the Image: Edit - Fade dialog is blocking. It happens in the current git version, but maybe also in the stable version. That's intentional. Due to the way that Edit-Fade is implemented, the user must not do anything else while this dialog is opened. I suspected so, but it was just to be sure. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] why is the Toolbox not an ordinary dockable dialog?
The subject says it all: in the present situation (especially in the current git version), the Toolbox is definitely not an ordinary dockable dialog, but much less than before. In previous versions, closing it terminated GIMP, and it was the main support of the menu bar, which probably explained its special status. Now, the Toolbox remains special, but I don't know why. In single-window mode, it cannot be moved, nor closed. A dockable placed in the same dock behaves differently, especially it cannot show the image selection, not automatically follow it. Are there serious reasons for this special behavior? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] behavior of Shift+digit
In the Image - View menu, the Zoom sub-menu contains entries for 1:2, 1:4, 1:8, and 1:16 zooming factors. They are supposed to be associated with shortcuts Shift+2, Shift+3, Shift+4, and Shift+5. With the current git version and Ubuntu 10.04, I get a different behavior: - Shift+ a digit on the main keyboard does not have any effect. - If the auxiliary keyboard is num unlocked, no effect at all, with or without Shift. - If it is num locked, Shift+2 divides by two the current zooming factor, Shift+8 doubles it, Shift+3 sets the zooming factor to 1:8, and Shift+9 to 8:1. Other digits are inoperant, as well as all digits when they are typed without Shift. If this is what is intended, it does not work as documented in the Zoom menu. At least the auxiliary keyboard should be mentioned. In the documentation, there is nothing about this. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Tool options dialog
In the current git version, the Tool options dialog no longer tells the user what tool is directed by the corresponding options. If it i a Toolbox tool, we see the corresponding icon emphasized. If it is, for example, the Levels tool and we did not place its icon in the Toolbox, there is no way to know what is the current tool. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] useless sliders in the Tool options, git version
I tried several times to send the present message, sorry in case there is duplication. On one computer (with Debian testing), the git installation of GIMP dates from August 28. On the other one (with Ubuntu 10.04), it dates from September 5. I tried to attach screen copies of the Tool Options dockable with the Clone tool active, but the message is too heavy. In the oldest version, the sliders work as customary, because their title is above them. In the newest version, the sliders are no longer usable, because their title is on their left and they are too short, and I would need to enlarge the dock to at least 7 tools per row to get something usable at all. By the way, what's the meaning of the 4 x 138 or 5 x 172 indications that pop up while I'm enlarging the dock? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] current git version: weird behavior in a detached menu
Git version compiled today on Ubuntu 10.04. Using a right-click in the Image window, I detach the Image - File - Create menu. In this detached menu, the menu entries work as customary. However, the simple entries, for example Screenshot, have no other effect than to display a comment iin the bottom of the Image window. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] a slight problem that has existed for some time
The following problem exists in the current git version, but is not new. When a new dockable dialog is created, for example by double-clicking a tool icon in the Toolbox when there is no Tool options dialog open, or by double-clicking a paint dynamics entry in the Paint dynamics dialog, the new dialog is open under the current window. Sometimes, it is almost completely hidden. Either it should be open over the current window, or in another location on the screen, if available. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wish: A better animation system inside GIMP
You seem to be interested only in animated GIF? Even in this case, are you aware of the GIMP Animation Package? Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wish: A better animation system inside GIMP
2010/8/29 LightningIsMyName lightningismyn...@gmail.com Hello, Forgot to mention that it would also require to change most animation scripts and GAP... On Sun, Aug 29, 2010 at 10:15 AM, Olivier oleca...@gmail.com wrote: You seem to be interested only in animated GIF? Even in this case, are you aware of the GIMP Animation Package? Olivier Lecarme First of all, yes - I am aware of GAP and I used it several times (although I'm still not completely familiar with it). Still, abusing layer names must stop and this is my main request - and in order to stop this we must introduce a very simple animation editor (since we have many animation scripts and it should be possible to edit their result). GAP is very good and complicated, and I'm referring to something much simpler only to edit the frame duration/disposal (instead of the ugly layer name hack) - nothing more. GAP is not very complicated, simply it is not well described. If you are interested in multi-layer animations, the duration and mode of layers is obviously a layer property. Why not use the layer name for this? It is available and not very useful for anything else in this precise case. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject) plus dockables
Just the simple point of a basic user: 2010/8/28 g...@catking.net I think this is the logical error here from usage point of view. It is not the fact that they are dockable which means they should be grouped together. They should be grouped according to function. If I want to hide a layer I should not need to think : last time I did this what did it look like, what sort of GUI element was it that allowed me to hide a layer, was it dockable, where are dockables hidden? If I want to hide a layer , I go to the layers menu. I find it strange anyone would argue against that. The layers (dockable) dialog should never be hidden, every GIMP user guide says that. Thus for anybody following this idea, the real question is If I want to hide a layer, I go to the layers dialog. Otherwise, it would be necessary to copy in the layers menu all the functionalities of the layers dialog, which means a lot. Is this argument so strange? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] compilig the git version
I'm installing a brand new computer with Debian testing. I want to compile the current git version of GIMP. All things work well for babl and gegl, but I can't manage to compile GIMP itself. Here are the last lines after ./autohen.sh : gtk-doc.make:58: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL devel-docs/libgimpthumb/Makefile.am:54: `gtk-doc.make' included from here gtk-doc.make:7: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL devel-docs/libgimpwidgets/Makefile.am:66: `gtk-doc.make' included from here gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL devel-docs/libgimpwidgets/Makefile.am:66: `gtk-doc.make' included from here gtk-doc.make:58: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL devel-docs/libgimpwidgets/Makefile.am:66: `gtk-doc.make' included from here menus/Makefile.am:58: `%'-style pattern rules are a GNU make extension plug-ins/common/Makefile.am:202: `%'-style pattern rules are a GNU make extension If I disable gtk-doc, the result is the same, except the message telling me I disabled it. What should I do? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
On Sun, Jul 25, 2010 at 3:04 PM, Vincent Beers vincentbe...@gmail.comwrote: Hi, I have a feature/enhancement request. Currently, the GIMP shows the program's menu when right-clicking within the drawing area. However, this seems superfluous as the menu is already displayed at all times. This is certainly false. You can hide the menu bar, as well in normal mode as in full screen mode, and you can handle an image so large that the menu bar is out of the screen. The menu bar available on a right click is absolutely necessary, it is the only certainly available way to get the menu bar. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
On Sun, Jul 25, 2010 at 3:52 PM, Vincent Beers vincentbe...@gmail.comwrote: While you have a point about being able to hide the menu bar, doesn't the main window never get larger than the screen size, meaning that your window title and everything in it will always be visible? This limitation does not exist. Suppose I have an image 4000x6000 and I want to look at it at 100%, or an image 400x600 and I want to look at it at 800%. If I shrink wrap it (Ctrl+E with version 2.6, or Ctrl+J with version 2.8), certainly the window will be larger than my screen. Since I can easily move it using some key combination and the mouse, I can look at various parts of the image, and be not limited by my screen size. Actually, I have encountered no other image manipulation suite that would obscure the menu bar like this other than the GIMP. I'm not saying that it is a bad thing, just that it removes the chance to do anything else with said button. For a mouse button, which is one of the buttons that is easily and quickly clickable, opening a menu might not be the most desired action to give it. I cannot count how many times I have been happy to be able to reach almost everything from a simple right-click. If other image manipulation applications cannot offer this possibility, too bad for them. If accessing the menu is absolutely necessary in this way, why not map it to another common key (like tapping the space bar) and leave an extra mouse button to added editing power? Or perhaps use the context menu button on the keyboard to good use. The space bar is invaluable as a way to move the image withing its window. Why do you want to confiscate existing possibilties, instead of unused keyboard and mouse combinations? If you really can't go without the right-click-menu thing, how about making it more context sensitive, then? Show appropriate options when you right-click a selection or a text box for example, with the original menus shown below the context sensitive options. Same remark as above. I would suggest you to propose new combinations for interesting, new capabilities, but not try to remove somewhat which has existed from the first version of GIMP, simply because you don't use it. Vincent Beers On 25 July 2010 15:15, Olivier oleca...@gmail.com wrote: On Sun, Jul 25, 2010 at 3:04 PM, Vincent Beers vincentbe...@gmail.com wrote: Hi, I have a feature/enhancement request. Currently, the GIMP shows the program's menu when right-clicking within the drawing area. However, this seems superfluous as the menu is already displayed at all times. This is certainly false. You can hide the menu bar, as well in normal mode as in full screen mode, and you can handle an image so large that the menu bar is out of the screen. The menu bar available on a right click is absolutely necessary, it is the only certainly available way to get the menu bar. -- Olivier Lecarme -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] various clicks in a layer row of the layers dialog
On Sun, Jul 4, 2010 at 2:47 PM, Marco Ciampa ciam...@libero.it wrote: On Sat, Jul 03, 2010 at 05:38:40PM +0200, Olivier wrote: Would it be interesting and useful to add some mechanism to correct this situation? There could be additional entries in the Layers dialog menu, or in the Image: Layer menu. There could be information messages displayed when the mouse pointer is hovering some parts of the layer row. I could refine the idea, but unfortunately I'm not able to implement it. Indeed that is a _very_ good idea. Maybe it is better to file a bug report for it? Just to avoid to loose it in the dev mailing list... Maybe the idea should be more precise for filing a bug? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] various clicks in a layer row of the layers dialog
In the present situation of GIMP, a layer row in the Layers dialog may be the target of a lot of different clicks: simple click in the visibility eye or link symbol, double click in the name, and now Alt-click in the layer thumbnail, which can also be combined with Shift and Ctrl to give Alt-Shift-click, Alt-Ctrl-click, and even Alt-Ctrl-Shift-click. Moreover, if there is a layer mask, clicking the layer thumbnail becomes meaningful, as well as click, Ctrl-click, and Alt-click in the layer mask thumbnail. A total of eleven different clicks, if I'm not forgetting some. All these are certainly useful. However, there is no mechanism for revealing them to users, and no other way to do the same thing. Thus many users, not reading the user manual or the good books, can very well be unaware of all these possibilities, and maybe they are using complicated and poor solutions to do some actions that are in fact very simple. Would it be interesting and useful to add some mechanism to correct this situation? There could be additional entries in the Layers dialog menu, or in the Image: Layer menu. There could be information messages displayed when the mouse pointer is hovering some parts of the layer row. I could refine the idea, but unfortunately I'm not able to implement it. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.7.1
In the new release notes of http://www.gimp.org/release-notes/gimp-2.7.htmlthe keyboard shortcut for shrink wrap is still noted Ctrl+R, although it is now Ctrl+J. Same problem for Fit in Window. Incidentally, does this latter command appear in some menu? Same question for Alt+click in a layer thumbnail: what is the name of the command, and does it appear in some menu? Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] windows always on the visible workspace
I'm using the git version of last Sunday, on a Dell Inspiron 530 with Debian testing and GNOME. I have a dual screen environment, and I want all GIMP windows to be always visible on the visible workspace. Thus I can change workspace on one of the screens, and always look at GIMP windows on the other screen. I'm not certain that the problem I encounter is new to this git version. Using the GNOME right-click on the title bar of the GIMP windows, I ask for having them always visible on the visible workspace.As soon as I call a filter which opens a dialog window, the property I set disappears, and I have to set it again after closing the window. Moreover, the dockable dialogs and the toolbox, although they still have the property set, no longer behave properly. However, if I set the property again on the image window, the other dialogs again behave as expected. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] impossible to get the new git version
Here is what I get: 17:50 r...@olecarme /opt/gimp# git pull remote: Counting objects: 288, done. remote: Compressing objects: 100% (182/182), done. remote: Total 182 (delta 143), reused 0 (delta 0) Receiving objects: 100% (182/182), 36.59 KiB, done. Resolving deltas: 100% (143/143), completed with 64 local objects. From git://git.gnome.org/gimp 1c91f68..552158a gimp-2-6 - origin/gimp-2-6 bc72b15..ba3d530 master - origin/master Updating bc72b15..ba3d530 error: Your local changes to 'm4macros/gtk-doc.m4' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. zsh: exit 1 git pull Is it a problem with me, or with the git site? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] impossible to get the new git version
You have a local change in which gtkdocize has change the version controlled file m4macros/gtk-doc.m4 into a symlink. I've pushed a change that removes our local copy of gtk-doc.m4. You need to get rid of the local changes before you pull, so first do git checkout m4macros then git pull should work. It works! Thanks a lot! -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] impossible to get the new git version
You have a local change in which gtkdocize has change the version controlled file m4macros/gtk-doc.m4 into a symlink. I've pushed a change that removes our local copy of gtk-doc.m4. You need to get rid of the local changes before you pull, so first do git checkout m4macros then git pull should work. If anyone finds more problems with gtk-doc, let me know. It worked on one computer, not on the other. Both are using Debian testing and are up-to-date. On the first one, the compilation is working smoothly just now. On the second one, here is the problem: 18:11 r...@pierredelune /opt/gimp# ./autogen.sh --prefix=/opt/gimp-2.7 I am testing that you have the tools required to build the GNU Image Manipulation Program from git. This test is not foolproof, so if anything goes wrong, see the file HACKING for more information... checking for libtool = 1.5 ... Major version might be too new (2.2.6) checking for gtkdocize ... yes checking for autoconf = 2.54 ... yes (version 2.65) checking for automake = 1.9.6 ... yes (version 1.11.1) checking for intltool = 0.40.1 ... yes (version 0.41.1) checking for xsltproc ... yes I am going to run ./configure with the following arguments: --enable-maintainer-mode --prefix=/opt/gimp-2.7 libtoolize: putting auxiliary files in `.'. libtoolize: linking file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4macros'. libtoolize: linking file `m4macros/libtool.m4' libtoolize: linking file `m4macros/ltoptions.m4' libtoolize: linking file `m4macros/ltsugar.m4' libtoolize: linking file `m4macros/ltversion.m4' libtoolize: linking file `m4macros/lt~obsolete.m4' data/tags/Makefile.am:19: wildcard $(top_srcdir: non-POSIX variable name data/tags/Makefile.am:19: (probably a GNU make extension) data/tips/Makefile.am:20: wildcard $(top_srcdir: non-POSIX variable name data/tips/Makefile.am:20: (probably a GNU make extension) desktop/Makefile.am:52: wildcard $(top_srcdir: non-POSIX variable name desktop/Makefile.am:52: (probably a GNU make extension) gtk-doc.make:7: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL devel-docs/app/Makefile.am:116: `gtk-doc.make' included from here [a lot of similar couples of lines] zsh: exit 1 ./autogen.sh --prefix=/opt/gimp-2.7 -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Edit - Fade
I just discovered this new entry in the Edit menu, as well as the three new fading modes with erase in their name. It's seem interesting, but is there somewhere explanations about the purpose and working of this feature? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Edit - Fade
On Mon, Jun 14, 2010 at 9:00 AM, Tobias Jakobs tobias.jak...@googlemail.com wrote: Hello Olivier, you can find more information about this in the Gimp help: http://docs.gimp.org/2.6/en/gimp-edit-fade.html Shame on me! I did not discover this menu entry until now! However, the GIMP help is rather terse, and tells nothing about the Color Erase, Erase, and Anti Erase blending modes. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] paint dynamics in the git version
In a git version compiled a few hours ago, there remain at least two anomalies in the Paint Dynamics dialog: Duplicate Dynamics is always inoperant, and on the contrary it is still possible to edit a predefind dynamics by using other tabs than the mapping matrix. Moreover, Duplicate Dynamics, when it will work, should also appear as a button in the bottom of the Paint Dynamics dialog. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] paint dynamics in the git version
A small but annoying point: when I edit a paint dynamics, the new dockable dialog dor this editing always pops up below the paint dynamics dialog. I have to move it elsewhere and place it in the foreground. This is the only dialog with this behaviour, to my knowledge. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] git version and layer groups
A small problem about layer groups in the git version: if I hide the layers of a layer group by clicking on the small white triangle in the layers dialog, then make another image active, and come back to the first image, then the layers of the layer group are no longer hidden. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] incomprehensible behavior with the git version
On Wed, Mar 31, 2010 at 10:20 AM, Omari Stephens x...@csail.mit.edu wrote: Try running ldd `which gimp-2.7` on both machines. I would imagine there's a dependency issue. Specifically, I'd wonder about your versions of X11 and GTK Since the problem finally occurs on the same machine, but with two different users, it must be a matter of personal GIMP environment. I'm searching in this direction. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] incomprehensible behavior with the git version
On Wed, Mar 31, 2010 at 11:12 AM, Olivier oleca...@gmail.com wrote: On Wed, Mar 31, 2010 at 10:20 AM, Omari Stephens x...@csail.mit.eduwrote: Try running ldd `which gimp-2.7` on both machines. I would imagine there's a dependency issue. Specifically, I'd wonder about your versions of X11 and GTK Since the problem finally occurs on the same machine, but with two different users, it must be a matter of personal GIMP environment. I'm searching in this direction. I think I have the answer, but I don't know why it is such, and whether I should file a bug: it depends on the input device mode setting. If the tablet mouse is set to GDK_MODE_SCREEN, its wheel no longer works in the image, although it works in the scrolling bars. It no longer allows to change the text parameters in the image, and the tablet pen, which must be in screen mode for the pressure and tilt parameters to work, cannot be used for changing parameters of a text in the image. I don't have the same problem on the computer at home because I don't have a tablet there. And a new user does not have the problem, because the input device configuration is in its default state. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] incomprehensible behavior with the git version
The scroll not working on the mouse with extended device enabled is most likely a gtk issue. current stable GTK has several quirks in the extended device department. for example occasionally mouse does not work at all on the canvas with the tablet connected and quite randomly on next run it will work again. Should I file a bug about it? The text tool controlls not working with the tablet is different tho. Most likely something worth filing a bug against Gimp. I just did it. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] remarks about the current git version
Just to be sure nothing passes unnoticed: - still no tooltips in the Toolbox; - Ctrl+mouse wheel no longer zooms; must it be configured now with the Input Controllers page in the the Preferences dialog? - the new set of parameters that appears when one uses the toolbox seems interesting, but I cannot find how to use it; - I discovered the wheel column and the flow row in the mapping matrix of the Paint Dynamics, but could not understand their meaning. If my remarks are useless, or worse, please tell me! -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Paint Dynamics in git version
2010/3/10 Aurimas Juška aurimas.ju...@gmail.com Hi, 2010/3/9 Olivier oleca...@gmail.com: With regards to useful extensions to this feature, it seems to me that the most important one is the capability to tag several resources at the same time, for example using combinations of the Ctrl and Shift keys while clicking. In fact, this feature is useful mainly when you have a lot of brushes, for example, and it would be a burden to have to tag several hundreds of them. I have just commit such feature into development version. In you choose 'View as list' in any data view you can select multiple in usual way. Common set of tags for all selected items is displayed in assign tags box. If you add/remove tags there, all selected objects are updated accordingly. It is possible that in the future this feature will be available in other views and more actions might be available on multiple items at a time. Thanks a lot, this adds something very useful, and strongly improves the usability of the whole thing. A useful feature, in the same vein, would be to store resources in sub-folders of the normal folder, and to give them automatically a tag depending on the name of the sub-folder. Maybe also this could help the idea of lazy loading that you mention: a given sub-folder would be loaded only if the corresponding tag is used as a filter. I think tags are more flexible than folders. You can put a thing in only one folder (category) while tagging solution allows to assign any number of tags (categories, keywords) that should make it easier to find an item you're searching for. I explained my idea poorly, let's try again. Suppose you find somewhere a large set of interesting brushes, which you plan to use some times, but not always. You install them in a sub-folder of your brushes folder, and choose for this sub-folder a meaningful name. Then, maybe depending on some explicit action, you would ask to import these brushes, giving to them as a first tag their sub-folder name. This would not prevent you to add to them other tags later, but it would automatically categorize them, and you could look at them in the brushes dialog simply by placing their tag in the filter field. By the way, it would also be useful, especially in this case, to have a negative filter, i.e. filter the resources that don't have a given tag. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] segmentation fault in current git version
Version compiled today. If I change the current gradient in the Gradients dialog, all works well. If I try changing it in the Blewnding tool options, I get the following: This is a development version of GIMP. Debug messages may appear here. (gimp-2.7:22938): GLib-GObject-WARNING **: value -2147483648 of type `gint' is invalid or out of range for property `cache-size' of type `gint' /opt/gimp-2.7/bin/gimp-2.7: fatal error: Segmentation fault /opt/gimp-2.7/bin/gimp-2.7 (pid:22938): [E]xit, [H]alt, show [S]tack trace or [P]roceed: e (script-fu:22949): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error Trying to show trace does not produce any result. Debian testing on a Dell Inspiron 530. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Paint Dynamics in git version
Two questions about Paint Dynamics, a feature which I find extremely promising, and about which I would like very much to have more explanations than the current GUI specifications: 1. What is the difference between Fade Tapering and Fade Tappering, and the same question for Velocity Tapering and Tappering? 2. When trying to change an existing Paint Dynamics, the Mapping Matrix is grayed out, to show that it is read-only. However, the other tabs are not, and I can check boxes and change curves. Is this a bug or a feature? By the way, is there somewhere some explanations about the purpose and use of tags and filters? I think I can guess a large part of this, but reading authorized text would be useful. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] observations about the git version
1. Shrink wrap, up to version 2.6 on Ctrl+E, then on Ctrl+R, is now on Ctrl+J. 2. Right-click in the image window no longer does anything. 3. When you open an image narrower than the menu bar, it is now flushed to the left of the canvas, instead of being centered. Just to be sure that all this is on purpose... -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] no fade out in painting with the git version
The subject says all. A lot of things are already working in the new features of brush tools, but no longer the fade out feature. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no fade out in painting with the git version
In my opinion, a good explanation in the documentation could be enough: the Fade out tool option has an effect only if the Mapping matrix of the current Paint Dynamics has at least one box checked in the Fade column; similarly, the Use color from gradient tool option has an effect only if the Mapping matrix of the current Paint Dynamics has at least one box checked in the Color row. What seems surprising, however, is the dissymetry between these two characteristics. Moreover, the sentences I have to write would clearly need to be shortened. On Thu, Feb 25, 2010 at 1:26 PM, Alexia Death alexiade...@gmail.com wrote: As the bug and this post prove, that behavior is not sane. I hope Peter proposes a sane solution soon. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] no tooltips in git version
For some time now, there has been no tooltips in the Toolbox. They still appear in menus. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
On Wed, Feb 17, 2010 at 7:34 PM, Akkana Peck akk...@shallowsky.com wrote: Olivier writes: For several weeks now (I compile the git version every Monday), the windows in normal mode (i.e. multi-window mode) behave in a weird way: I place them where I want them on one virtual screen, and then I move to another one virtual screen. When I come back, the windows have moved to a different place, always the same. https://bugzilla.gnome.org/show_bug.cgi?id=608834 That also has a workaround, if you want to patch your local version so you can use gimp in the meantime. GIMP remains usable, of course, simply somewhat irritating! With regards to Sven Neumann's comment mentioning some window managers, the problem occurs with Metacity, although I had the impression it was the reference window manager for GIMP. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] paint dynamics
I discovered some weeks ago the new Paint Dynamics feature of version 2.7 and the git one, but I would like to find some explanations about its use. One point which bothers me is that I thought there was some way to control the shape of the answer curve between some varying parameter (pressure, velocity, tilt, etc.) and some brush characteristic (opacity, hardness, size, etc.). However, I don't see this anywhere. Where should I search? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] moving windows in the git version
For several weeks now (I compile the git version every Monday), the windows in normal mode (i.e. multi-window mode) behave in a weird way: I place them where I want them on one virtual screen, and then I move to another one virtual screen. When I come back, the windows have moved to a different place, always the same. I'm with Debian testing and GNOME. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] watercolor tab in the color chooser
In the current git version of GIMP, the watercolor tab in the color chooser seems to be broken. If you click enough times anywhere in the color rectangle, you always finish with the same color, #00. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] watercolor tab in the color chooser
No, this is really a problem of the git version. Version 2.6 works according to the watercolor model. It seems that the git version is broken. Should I fill a bug in Bugzilla? On Tue, Jan 26, 2010 at 2:27 PM, Austin Donnelly -- yahoo austin_donne...@yahoo.co.uk wrote: That’s by-design. Think of mixing paint: if you add in more and more paint, eventually you’ll get to a muddy brown colour. Since the watercolour tab in the colour picker simulates mixing paint, it also has this effect. I’m not sure why it would converge to cyan, though. That might be a bug. Austin *From:* gimp-developer-boun...@lists.xcf.berkeley.edu [mailto: gimp-developer-boun...@lists.xcf.berkeley.edu] *On Behalf Of *Olivier *Sent:* 26 January 2010 13:01 *To:* GIMP Developer *Subject:* [Gimp-developer] watercolor tab in the color chooser In the current git version of GIMP, the watercolor tab in the color chooser seems to be broken. If you click enough times anywhere in the color rectangle, you always finish with the same color, #00. -- Olivier Lecarme -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Artistic extensions to Gimp with (Wacom) drawing pad
On Mon, Nov 30, 2009 at 7:47 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Mon, Nov 30, 2009 at 9:42 PM, Sven Neumann wrote: Of course! But since I'm writing a book about GIMP, I'm trying to get as close as possible to what will be finally published. When speaking about documentation, I was thinking to the NEWS file. If you are writing a book, then you should write it about GIMP 2.6. Everything that is in GIMP 2.7 now may still change at this point, in particular any new features. Or plan an appendix to cover possible changes in 2.8, time/deadline permitting Alexandre Since the book is not anticipated to be published before the Autumn of 2010, on the contrary I would very much like that it covers at least version 2.8, or still better, version 3.0. This means I'm not writing or completing chapters that deal with matters changing a lot presently: one-window or multi-window interface, brush dynamics, layer groups, color depth, color management, and so on. Am I forgetting important points subject to changes until version 3.0? Since I intend to write a very thorough book (about 800 pages in English, about 550 in French because the publisher cannot afford more), I have a lot of work in other areas, and I can wait until things are stabilized. But I want to follow the progress as much as possible. The American publisher is No Starch, and the French one is Pearson. Do you think this approach is sensible? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Artistic extensions to Gimp with (Wacom) drawing pad
On Mon, Nov 30, 2009 at 12:19 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 11/29/09, Olivier wrote: OK and thanks! Was it documented somewhere and escaped me? Dear Olivier, We are talking about a feature that is not even officially published, not being part of any release :) It's too early to document this change. Of course! But since I'm writing a book about GIMP, I'm trying to get as close as possible to what will be finally published. When speaking about documentation, I was thinking to the NEWS file. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP to be removed from Ubuntu Lucid Lynx?
On Fri, Nov 20, 2009 at 2:41 AM, Joao S. O. Bueno gwid...@mpc.com.brwrote: On Thu, Nov 19, 2009 at 4:48 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Thu, Nov 19, 2009 at 9:45 PM, Thorsten Wilms wrote: I have been in that session and can confirm it. OK, but what session? At UDS? Yes, friend of mine was tehre, confirmed it too. (btw, it evenshowed up in slashdot). IMHO, stupidiest decision ever - they _want_ their users to be dumb and continue that way. As for me, up to today I used to recomend ubuntu to people I presented Free Software. (despite some ongoing really great flaws, like translating the name of special user folders such as Desktop and Documents). Now, with the promise of a GIMPless Ubuntu, I will burn some other distro for people to taste Linux and Free Software. Give a try to Debian, the netinst version http://www.debian.org/devel/debian-installer/ You need a decent Internet connection, but the available room on a CD is no longer a problem, and GIMP is present, of course. After all, Ubuntu is based on Debian, why not stick to the original, rather than to deviant copy? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wish: adding Jitter and Brush Dynamics into Script-Fu
Sorry if my question is out of context: has this problem anything to do with the fact that the Gfig or Spyrogimp filters, for example, are no longer usable with version 2.7, since there is no way to change the size of the brush? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] core plugin concept
Hi, I have a question for core developers about plugins : How are the images and other parameters passed to (C++) plugins ? via network or via the file system ? Is there any documentation about the gimp plugins concept (I don't want documentation on how to build a plugin for gimp) ? Thanks. Olivier ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cvs tree not compiling
On Fri, Oct 01, 2004 at 09:43:29AM +0200, Olivier wrote: after a cvs (anonymous cvs) update last morning: Making all in libgimp make[2]: Entering directory /home/olivier/inst/cvsgimp/gimp/libgimp' make[2]: *** No rule to make target `gimpgradientedit_pdb.c', needed by `gimpgradientedit_pdb.lo'. Stop. make[2]: Leaving directory /home/olivier/inst/cvsgimp/gimp/libgimp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory /home/olivier/inst/cvsgimp/gimp' make: *** [all] Error 2 never mind, I guess something went wrong during the cvs update, because deleting a substree and updating it again solved the problem. regards, Olivier ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] difference between canvas_draw and draw_tool_draw functions
On Thu, Sep 30, 2004 at 11:27:17AM +0200, Sven Neumann wrote: what is the difference between for example gimp_canvas_draw_rectangle and gimp_draw_tool_draw_rectangle? The GimpDrawTool API takes image coordinates while the (lowerlevel) GimpCanvas API takes display coordinates. the drawtool always paints using GIMP_CANVAS_STYLE_XOR, correct? I'm creating a patch to add an option to the crop tool to blind the region outside the crop area, so you can see how the image will look after cropping. I've not decided yet if XOR is good, or if the area should become black. Anybody a preference? another question, how can I 'undraw' a section, after the user for example changed the location of a handle? If I use XOR this is not a problem, but if I draw the area black, this is a problem. thanks, Olivier ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] difference between canvas_draw and draw_tool_draw functions
On Thu, Sep 30, 2004 at 12:46:02PM +0200, Sven Neumann wrote: the drawtool always paints using GIMP_CANVAS_STYLE_XOR, correct? I'm creating a patch to add an option to the crop tool to blind the region outside the crop area, so you can see how the image will look after cropping. I've not decided yet if XOR is good, or if the area should become black. Anybody a preference? I think neither XOR nor black are an option here. What we would want to see is a less saturated and darkened version of the image being shown outside the crop region. That is not going to be a trivial change though. less saturated won't work for grayscale images, but darkened would be OK I think, but I don't think I can do that on my second day of gimp hacking indeed ;-) But black is a useful start, it can always be improved to a darkened image any later time (for now you can always toggle the checkbox if you want to see what the outer region of the image looks like). regards, Olivier ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] adding option to crop tool
Hi all, I'm trying to create a patch to fix several feature requests about the crop tool. However, after adding my first option to the crop tool info window, I get these messages during startup: (gimp-2.1:11796): GLib-GObject-CRITICAL **: file genums.c: line 402 (g_value_get_enum): assertion _VALUE_HOLDS_ENUM (value)' failed I've added a boolean (not enum!!) option to the struct in gimpcropoptions.h, added it to the set and get functions, to the class init, and added a corresponding widget to the GUI. If I try to click the widget, I get the same errors. Where should I look for the problem? Is there some auto-generated file that contains all registered options for all the tools or something like that?? thanks, Olivier ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] adding option to crop tool
On Wed, Sep 29, 2004 at 04:15:46PM +0200, Sven Neumann wrote:
You should show us your code if you want us to help you.
what is the policy towards attachments on this list? If allowed I'll attach
the file, for now I'll list my changes:
-- in gimpcropoptions.h added a gboolean to the struct:
struct _GimpCropOptions
{
GimpToolOptions parent_instence;
gboolean layer_only;
gboolean allow_enlarge;
gboolean keep_aspect;
GimpCropMode crop_mode;
gboolean blank_outer_region;
};
-- in gimpcropoptions.c added a number to the enum:
enum
{
PROP_0,
PROP_LAYER_ONLY,
PROP_ALLOW_ENLARGE,
PROP_KEEP_ASPECT,
PROP_CROP_MODE,
PROP_BLANK_OUTER_REGION
};
-- added to gimp_crop_options_class_init (GimpCropOptionsClass *klass):
GIMP_CONFIG_INSTALL_PROP_BOOLEAN (object_class, PROP_BLANK_OUTER_REGION,
blank-outer-region, NULL,
FALSE,
0);
-- added to gimp_crop_options_set_property:
case PROP_BLANK_OUTER_REGION:
options-blank_outer_region = g_value_get_enum (value);
break;
-- added to gimp_crop_options_get_property:
case PROP_BLANK_OUTER_REGION:
g_value_set_enum (value, options-blank_outer_region);
break;
-- added to gimp_crop_options_gui:
/* blank outer region */
button = gimp_prop_check_button_new (config, blank-outer-region,
_(Blank outer region));
gtk_box_pack_start (GTK_BOX (vbox), button, FALSE, FALSE, 0);
gtk_widget_show (button);
(b.t.w: there is a memory leak in this function, the last string 'str' is
not freed, but I'll include that in my patch whenever it is working)
so what is missing now?
thanks,
Olivier
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] adding option to crop tool
On Wed, Sep 29, 2004 at 06:19:15PM +0200, Dave Neary wrote: Hi, Quoting Olivier [EMAIL PROTECTED]: snip gboolean blank_outer_region; snip GIMP_CONFIG_INSTALL_PROP_BOOLEAN (object_class, PROP_BLANK_OUTER_REGION, blank-outer-region, NULL, FALSE, 0); snip options-blank_outer_region = g_value_get_enum (value); g_value_set_enum (value, options-blank_outer_region); This looks rather suspicions - you're declaring a gboolean as a BOOLEAN property, and then using get_ and set_enum to get and set its value. Try changing these to get_ and set_boolean and see what happens. how blind did I become thanks for noticing that! regards, Olivier ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Some feedback on Gimp 1.3.x
Raphaël Quinet wrote: On Tue, 18 Mar 2003 17:48:32 +0100, Olivier Ripoll [EMAIL PROTECTED] wrote: MArk Finlay wrote: 1. Everyone loves a good splash screen, but now Gnome has startup-notification which kinda makes them superflous. [...] I want the splash screen! ;) I've seen Jimmac has done a new (or updated) one in the changelog for today, and already look forward to see it! Besides, not everyone is running the GIMP under GNOME. I use GNOME on all of my Linux boxes, but none of my Solaris boxes have GNOME installed so the startup notification would not work there. 2. To a lot of new users the way Gimp works is quite alien. A lot of users just get used to it, but some find it too weird. One of the hardest things to get used to is right clicking on an image to access the menus. [...] For users who want to use the rightclick menu, the menubar is un-obtrusive and can be turned off if they really hate having it there, and for a lot of users this will be invaluable. I know the option is there already, but it's the defaults that matter. Newbies are not going to go looking for a menubar that they don't know exists. I agree with this. As an experienced user, I would not use the menu on top of the image windows because I can work faster with the right-click menu, but it should be enabled by default so that new users do not feel lost for the first time they use the GIMP. I would go as far as suggesting that the default should be to have a WiW MDI model (at least for the Windows version, maybe even for other platforms) because this would allow the GIMP to be more similar to other image editing programs. Cross-application consistency is more important than the efficiency of any single application, for those who do not use this application frequently. The majority of GIMP users do not use it frequently. So I think that the default configuration of the GIMP should have the menubar in the image window or even use a full MDI model. There could be a tip of the day suggesting to disable this menubar and to use only the right-click menu in order to save space and to work faster. The default mode should focus on cross-application consistency. -Raphaël After a good night of sleep (la nuit porte conseil ;) ) I had of one more of my stupid ideas that may solve the default configuration issue. When one launches gimp for the first time (even on multiple user systems), there is this orange dialog which asks you where you want the gimp config directory to be set, and what is the resolution of the screen. Perhaps it could be asked there, together with an image illustrating it, which of the with or without menu style the user wants. Of course, there would be a mention that it can be changed afterwards in the preferences. Regards, Olivier. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] installing Gimp-1.3.8 on a DEC Alpha computer with OSF1
I'm trying to do what the subject explains. I already installed successfully Gimp-1.2.3. In order to prevent conflicts within incompatible versions of glib and gtk+, they are installed in distinct hierarchies. configure --disable-print works correctly. When compiling, I get the following error in plug-ins/sel2path and plug-ins/common: the loader does not find the entry point abort. In order to terminate the compilation, I make the following change in the Makefile of both these directories: add /usr/lib/libc.a in front of the definition of GTK_LIBS. The compilation then terminates, as well as the make install. When I call gimp --verbose, I get the flash image, and after a while, here is what happens: parsing /usr/local/etc/gimp/1.3/gimprc parsing /net2/ciceron2/ol/.gimp-1.3/gimprc Adding theme 'Default' (/usr/local/share/gimp/1.3/themes/Default) Parsing '/usr/local/share/gimp/1.3/themes/Default/gtkrc' Parsing '/net2/ciceron2/ol/.gimp-1.3/gtkrc' loading module: '/usr/local/lib/gimp/1.3/modules/libcolorsel_triangle.so' loading module: '/usr/local/lib/gimp/1.3/modules/libcdisplay_gamma.so' loading module: '/usr/local/lib/gimp/1.3/modules/libcdisplay_highcontrast.so' ** (gimp-1.3:6106): WARNING **: Could not find XftConfig file cannot open file /usr/X11R6/lib/X11/XftConfig querying plug-in: /usr/local/lib/gimp/1.3/plug-ins/tool-safe-mode writing /net2/ciceron2/ol/.gimp-1.3/pluginrc initializing plug-in: /usr/local/lib/gimp/1.3/plug-ins/tool-safe-mode gimp-1.3: tool-safe-mode init called gimp-1.3: tool_plug_in_path: /net2/ciceron2/ol/.gimp-1.3/tool-plug-ins:/usr/local/lib/gimp/1.3/tool-plug-ins gimp-1.3: tool-safe-mode init done Starting extensions: extension_script_fu gimp-1.3: fatal error: Segmentation fault gimp-1.3 (pid:6106): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0x30005812a64 in g_on_error_stack_trace (prg_name=0x11be8 gimp-1.3) #1 0x300058128f8 in g_on_error_query (prg_name=0x11be8 gimp-1.3) #2 0x120053e6c in gimp_terminate () #3 0x120053cfc in gimp_fatal_error () Then the process enters and endless loop, which I terminate with a C-c: gimp-1.3: terminated: Interrupt /usr/local/lib/gimp/1.3/plug-ins/script-fu terminated: Interrupt (script-fu:6120): LibGimp-WARNING **: script-fu: gimp_flush(): error: Broken pipe I know that this version is unstable, but probably I get more problems than expected. What could I try? -- Olivier Lecarme ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] installing Gimp-1.3.8 on a DEC Alpha computer with OSF1
I'm trying to do what the subject explains. I already installed successfully Gimp-1.2.3. In order to prevent conflicts within incompatible versions of glib and gtk+, they are installed in distinct hierarchies. that's not necessary since glib/gtk+-1.2 happily coexist with glib/gtk+-2.0 in the same prefix (provided that your 1.2 versions aren't overly outdated). I did it after having encountered enormous problems when trying to install several Gnome 2 modules. When compiling, I get the following error in plug-ins/sel2path and plug-ins/common: the loader does not find the entry point abort. In order to terminate the compilation, I make the following change in the Makefile of both these directories: add /usr/lib/libc.a in front of the definition of GTK_LIBS. abort? I've never heard about that problem before, seems to be OSF1 specific. Probably, but I don't understand it. Maybe this comes from one specificity of OSF1, i.e. libc.so is in /usr/shlib, not in /usr/lib. The abort entry point is mentioned in libglib-2.0.so. Maybe the fix should occur in the glib configuration ? ** (gimp-1.3:6106): WARNING **: Could not find XftConfig file cannot open file /usr/X11R6/lib/X11/XftConfig you should install a suitable XftConfig file to make the text tool happy. On the other hand since the text tool is almost unuseable it's not that important... I must confess I don't even know what XftConfig is... I'd suggest you temporarily move the plug-ins directory away and check if gimp works w/o any plug-ins. If that works you could reinstall some simpler plug-ins and test them. Perhaps only script-fu is broken for you. I did exactly that. Finally, only script-fu seems to be broken. I get some unaligned accesses, maybe because the Alpha is a true 64-bit processor. I can make some specific tests for this configuration, if this seems interesting. Anyway, many thanks for your help! -- Olivier Lecarme ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] installing Gimp-1.3.8 on a DEC Alpha computer with OSF1
abort? I've never heard about that problem before, seems to be OSF1 specific. Probably, but I don't understand it. Maybe this comes from one specificity of OSF1, i.e. libc.so is in /usr/shlib, not in /usr/lib. The abort entry point is mentioned in libglib-2.0.so. Maybe the fix should occur in the glib configuration ? you should try to run the tests that come with the glib-2.0 tarball. If you get problems there you should definitely report them using bugzilla.gnome.org against the glib module. In the tests directory of glib, make check-TESTS immediately fails because of the same problem: zenon(~/src/Gnome2-rc1/Install/glib-2.0.6/tests) : make check-TESTS mer 21 /bin/ksh ../libtool --mode=link gcc -g -O2 -Wall -D_REENTRANT -o array-test array-test.o ../glib/libglib-2.0.la -liconv -lintl -liconv gcc -g -O2 -Wall -D_REENTRANT -o .libs/array-test array-test.o ../glib/.libs/libglib-2.0.so -L/usr/local/lib /usr/local/lib/libintl.so -lc /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib creating array-test /bin/ksh ../libtool --mode=link c++ -g -O2 -o cxx-test cxx-test.o ../glib/libglib-2.0.la -liconv -lintl -liconv c++ -g -O2 -o .libs/cxx-test cxx-test.o ../glib/.libs/libglib-2.0.so -L/usr/local/lib /usr/local/lib/libintl.so -lc /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib /usr/local/bin/ld: Unresolved: abort free malloc strcmp strlen bcopy bzero collect2: ld returned 1 exit status make: *** [cxx-test] Error 1 zsh: 6768 exit 2 make check-TESTS I will report the problem as soon as bugzilla.gnome.org accepts to answer me. you should install a suitable XftConfig file to make the text tool happy. On the other hand since the text tool is almost unuseable it's not that important... I must confess I don't even know what XftConfig is... the font configuration for Xft, the next-generation X font rendering. The text tool uses it since PangoFT2 shares the configuration file with the Xft backend. This means you need to configure Xft even though your X server doesn't have support for it. I will try this. I'd suggest you temporarily move the plug-ins directory away and check if gimp works w/o any plug-ins. If that works you could reinstall some simpler plug-ins and test them. Perhaps only script-fu is broken for you. I did exactly that. Finally, only script-fu seems to be broken. I get some unaligned accesses, maybe because the Alpha is a true 64-bit processor. we definitely need to fix this problem. Could you please file a bug-report for it at bugs.gimp.org? Same remark as before. The problem seems to occur always at the same place, for example when I update the preview of an image, or when I select an image whose preview has already been selected, or when I open an image. -- Olivier Lecarme ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
