Re: swap files
On Sun, 10 Oct 1999, Federico Mena Quintero [EMAIL PROTECTED] wrote: [quoting Jay Cox] If we unlink the swap file after opening it then we have no way of knowing how much space gimp is using for it's swap file. lseek() returns the offset to which you seeked, so lseek (swap_fd, 0, SEEK_END) will give you its size. This is fine from within the Gimp. But most of the time I want to monitor the size of the swap file from a shell window, while the Gimp is performing some memory- and CPU-intensive tasks on a large image. If we unlink the file after opening it, then the file may not be visible in a directory listing. I suppose that this depends on the OS and filesystem used. On Mon, 11 Oct 1999, Marc Lehmann [EMAIL PROTECTED] wrote: a) unlink might not succeed on non-unix-systems. cure: ignore the error from unlink and try to unlink it again after closing the file This means in any case, we have to add some code that deletes the file when a signal handler is called (close and unlink in case of a crash). So if we have to do this in a signal handler anyway, why would we also do it just after opening the file? b) if the swap file is on nfs (extremely bad idea anyway) it might go away (physically) on the server when gimp does not access it for extended periods (10 minutes). In some cases, you do not have the choice. On several machines that I use at work, I have to put the swap file on NFS because all writable partitions are mounted over NFS (except for /tmp but it is too small). However, any other solution (doing it in the signal handler) is extremely annyoing (leaves too many swap files around). Are you sure about that? I think that it is more likely that the Gimp crashes and calls the signal handler than to have a power failure (which has more serious effects than just leaving a swap file around). In any case, why not use tmpfile or a similar function to create it? that function will do exactly what is required and will work on all systems (as good as it can). The problem with tmpfile() is that it is not as easy for the user to predict or change the location of the swap file. This function calls tmpnam() which relies on TMPDIR for the location of the file. But in some cases, the user might want to store the huge Gimp swap file on a (slow but large) NFS-mounted partition instead of a (fast but small) local disk, while all other applications would keep their reasonably small temporary files on a local /tmp disk. It could still be possible to use tmpfile() as long as we clear or override TMPDIR from inside the Gimp, but this is not a very elegant solution. I would prefer to have the file closed and unlinked in a signal handler. This is not a perfect solution (e.g. in case of power failure), but it has more advantages than the other solutions (or at least less disadvantages). -Raphael
Re: How to make scripts undoable?
On Wed, 24 Nov 1999, Marc Lehmann [EMAIL PROTECTED] wrote: On Wed, Nov 24, 1999 at 12:13:56AM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: How to make these scripts undo-aware? The problem is not really I'd say the obvious way would be to make gimp_undo_push_group_start just "work", rather than adding another kludge no user will ever understand. I agree, that would be the right way to do it. However, after looking for a while at undo.c, undo_cmds.c and related files, I thought that I'd better refrain from fixing the undo groups because I might break too many things while trying to fix that. If a developer who is more familiar with this code could help me a bit or add some documentation to the undo code, then I will attempt to fix gimp_undo_push_group_start. If you must, name it something different, but adding multiple lines to a plug-in *just* to make it work together with other plug-ins seems a large step backwards. I agree that it is not an elegant solution (I said so in my message) but at least this is a solution that would work for 1.2, taking the feature freeze into account. I can re-modify the scripts later, when a better undo system is included in version 1.3. If necessary, these "undo kludges" in the scripts can be marked with a comment saying that future versions of the GIMP will use a nicer solution. I mean, the semantics of bracketing scripts with these calls is obvious, and does not include "is very slow". This is an implementation detail that should be optimized away. If your solution can be implemented as two pdb calls (start and stop) then this would be fine. I thought about this for a while, but I prefered to put the code directly in the scripts because several scripts will use this method in slightly different ways: some of them will only modify one layer, some others will modify/add several layers, some others will modify everything in the current image, and so on. I prefer to let each script do exactly what it wants to do, instead of copying the whole image every time. On the other hand, wrapping this into two PDB calls would indeed look much cleaner (even if the internals are still ugly) and it would be easier to implement this in a better way later. So... errr... I don't know what to do. Does anybody have strong preferences for one solution (several calls in each script) or the other (two PDB calls hiding the gory details)? Or a third one (fixing gimp_undo_push_group_start)? -Raphael
Re: [gimp-devel] Re: Feature wanted
On Tue, 21 Dec 1999, Marc Lehmann [EMAIL PROTECTED] wrote: On Tue, Dec 21, 1999 at 10:56:28AM +0100, "Paul E.C. Melis" [EMAIL PROTECTED] wrote: Default for images could then be that there's no specific active tool, while you could still select one (and make it active) later, if you want. I don't see how you could dislike this. I dislike it because it does not say how this is accomplished. Do I have a toggle for each tool, for each image, or? be changed, and if you would like an active tool at some point, just make one active. Yes, but how is this done? Here is a suggestion: the default would be to use the same tool for all images, as we do now. But there would be a new button or checkbox associated with the image, with a description (tooltip) saying something like "lock active tool for this image" or "remember tool". Any image (or any view?) that has this option turned on would always use the same tool, even if you change the "global" active tool. That would allow you to associate the color picker with one image, while you are switching tools freely for the other images. -Raphael
Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
On Tue, 11 Jan 2000, Nick Lamb [EMAIL PROTECTED] wrote: On Tue, Jan 11, 2000 at 11:50:28AM +0100, Sven Neumann wrote: As said, I can't reproduce your problem here. As soon as I open the error_console, all errors produced with g_message () appear in that dialog instead of popping up a message window. Oh, I see. Somehow I expected that all my errors would appear in that box, regardless of whether they happened before it was visible. Having played with that part I see what you mean... So maybe what we need is a new option in the gimprc, something like: make-error-console-visible-on-first-g-message-and-leave-it-open If you set that to true, then the error console would do what you were expecting. Or did I misunderstand this discussion? Now if only all errors, debug messages and so on could use g_message() instead of printf() (in some plug-ins), then everything would be perfect... -Raphael
Re: Thanks (Re: Gimp splash images)
On Thu, 13 Jan 2000, "Garry R. Osgood" [EMAIL PROTECTED] wrote: The latest is very good too, but the bristles are pointing the wrong way (they would point *into* the ink blot as the brush pushes to the left). I guess this bothers my boring and literal mind. Good catch! Actually, it is even more than that: the whole brush should be pointing in the opposite direction (unless the artist is starting to paint a second line on top of the first one). When you are painting, the brush is usually pointing in the opposite direction of the existing stroke, which is not very convenient for the image layout. I would certainly vote for the lastest splash screen if it could be fixed. Some suggestions for Tigert (because I am not much of an artist so I cannot do that myself): - Move the existing ink line a bit higher (or lower) and start a second one where the tip of the brush is. - Or do things differently: instead of a simple line, draw a large circle in dark red ink around the GIMP letters. The advantage of a circle is that the brush comes back where it started, but with the correct orientation. - Add some perspective on the background. - The tip of the brush should be soaked with ink. Just my .02 Euro... -Raphael
Gimp splash image and about image
I just had an idea: the lightbulb image that is used in File/About could also be updated because it has not changed much since the early days. So what about this: we use the image version 1.14 for the splash screen (or 1.15 if Tigert can improve it), and the version 1.4 with the baloon for the about page. By the way (yet another request for Tigert), it would be nice if the gimp splash screen history page contained the date at which each image was checked in. I know that Aspirin's 1.12 joke has been there for a while, but I don't remember when it appeared. Anyway, that's just an idea. I would do a "cvs log" if I could access CVS, but I cannot do that for the moment. -Raphael
Re: Remove the Stack Trace...
On Tue, 25 Jan 2000, Marc Lehmann [EMAIL PROTECTED] wrote: On Mon, Jan 24, 2000 at 11:05:35AM -0500, Glyph Lefkowitz [EMAIL PROTECTED] wrote: Since the only advantage of this is the stack-trace for non-developers, The consensus was to remove it in release versions. So if the only advantage is for non-developers, why not remove it altogether? There is a difference between having the stack trace and having the program asking you if you want a stack trace... The latter is more useful for developers because you can also choose to start gdb and attach to the process, but you also have some potential problems with pointer grabs and so on. Here is how I see it: - I like Yosh's suggestion to have a configure option that allows to choose between "yes/no/query" for the stack trace. The "yes" option triggers a direct call to g_on_error_stack_trace() when a SIGSEGV is received, the "no" option exits immediately, and the "query" option calls g_on_error_query() as it does now. The same choices would be available on the command-line regardless of the default value choosen while compiling. The main advantage of the configure option would be to set the default so that it is not necessary to use the command-line option every time, and this could help those who build binary packages. - The default for the code in CVS would always be "query". This ensures that all developers (those who use the CVS code) can easily debug the code without having to re-start with different options if they forgot to enable the stack trace (some heisenbugs can be difficult to reproduce). - The default for the "released" code (in tar files) for the "unstable" versions would be "--enable-stack-trace=yes", so that the users would get a stack trace that they could easily report (if they have gdb) without having any nasty problems with pointer grabs. - The default for the "released" code for the "stable" versions (1.2.x) would be "--enable-stack-trace=no" because we expect that the GIMP would never crash (ha!) and we hope that any crash occuring while running the program could be reproduced by running it a second time with the command-line option that enables the stack trace. Note that this means some additional work for the person who builds the releases, because it will be necessary to remember to change configure.in before building the tar file. Hmmm... Now that I think about it, maybe "make dist" could take care of this automatically. Tricky, but possible, I think. (It must be removed from the plug-in anyway, since it cribbles over the signal handlers prepared by the plug-in, rendering signal handling useless). What is the problem exactly? Most plug-ins do not install a special handler for SIGSEGV (actually, I don't remember any plug-in doing that) so it should not be a problem. Also, using sigaction() instead of signal() could ensure that all signals are propagated correctly, even if there was a handler installed previously. If you have a more specific problem, please explain it because I do not see what is wrong with the current plug-ins. BTW: the stacktrace option has never worked on my machine(s), unless you call "endless loop" working. Also, I could never get out of that signal handler. Gimp just started to suck 100% cpu time when I tried to "e"xit. I doubt that this thing is useful for anybody (I tried it even on a stock redhat 6.1 system). It is a constant annoyance. Hmmm... I had these endless loop problems some time ago with 0.99.x and an old version of glib, but I haven't seen any similar problem in the past year. Also, the stack trace and the option to attach the debugger have both been very useful for me when I had some crashes under Solaris. Anyway, you could use the new command-line option to disable the stack trace if this is causing some problems. -Raphael
Re: Performance
On Thu, 03 Feb 2000, Kelly Lynn Martin [EMAIL PROTECTED] wrote: On Thu, 3 Feb 2000 19:33:31 +0100 (CET), [EMAIL PROTECTED] said: If you have a shared maschine the best would be to let the administrator choose how much memory each user will get because users'll ALWAYS try to get what they can even if it makes no sense It might be a good idea to have a compile-time configuration option for maximum cache size, I disagree. This would only encourage some users to re-compile their own version of the Gimp in a private directory in order to get around the hardcoded limits. Being a system administrator myself, I believe that an admin should always suggest some limits (and maybe use some social engineering to encourage users to respect these limits) but should avoid hard limits. Because most users do not like hard limits and they start wasting their time and the admins' time trying to work around them. and it might also be a good idea for gimp to check its ulimits and adjust its cache size so as to avoid running over its data segment limit or maximum resident set size. Some admins use these as a way to prevent resource hogging. That would be a good idea, indeed. If the limit on memory is rather low but there is still some room left on the disk, then it would be good to lower the tile-cache-size. This would ensure that the Gimp would not die prematurely because of malloc problems when it could have swapped some tiles to disk. On the other hand, if ulimits are used to limit the maximum file size or CPU usage, there is not much that we could do about it. Same if disk quotas are activated. The Gimp can have some control over its memory usage, but many parts of the code assume that the disk space is unlimited (or is not the main constraint). -Raphael
Re: [gimp-devel] Re: Some UI inconsistencies and a patch....
On Fri, 4 Feb 2000 (late at night), Marc Lehmann [EMAIL PROTECTED] wrote On Fri, Feb 04, 2000 at 12:48:50AM +0100, [EMAIL PROTECTED] wrote: Since the menus were reorganized I am constantly guessing wether "Repeat Last" will repeat my last action, the one before or not work at all, since you can't tell from the menu anymore. Huh? Sounds strange, could you provide a snapshot in a private EMail? I can't image what this should look like "Repeat Last" will repeat the last plug-in. Since menus do not provide a feedback of wether an entry is a plug-in or "built-in" (I think it would even be wrong to do so), you have to know this, which is not easy for beginners. I agree with you, Mark. Knowing the difference between tools and plug-ins is rather important, but is not easy for the beginner who has several dialogs open and is not familiar with all of them. If the user does not know what belongs to a tool and what belongs to a plug-in, then some actions such as "Undo", "Repeat Last" or "Re-Show Last" become unpredictable. There is also an issue with scripts (e.g. Script-Fu) but hopefully this will be resolved soon. Hmmm... this reminds me that I still have to contribute some code there... I am quite sure it improves usabiloty for me a lot. Well, I could provide you a patch which reverts it when you compile it with CFLAGS="$CFLAGS -DIMPROVE_USABILITY_FOR_MARC" :) Please note that I am not alone with that opinion... Yup! I definitely prefer redundancy if it improves the usability. In this case, making sure that all tools contain "Tool" in their title (e.g. "Pencil Tool") would avoid some confusion. Even if this sounds a bit ridiculous. -Raphael
Re: Print plug-in
On Tue, 01 Feb 2000, Kelly Lynn Martin [EMAIL PROTECTED] wrote: GNOME claims GIMP as part of GNOME because GIMP is better than any of the existing GNOME apps. They're trying to piggyback on our success. Personally, I think this is odious, but hey... This statement is ridiculous. They are not claiming that they wrote the GIMP. They just state that it will be included as part of the Gnome-Office suite. Besides, you should know that several of the early and current developers of the GIMP are also contributing to GNOME. So it's not like the two projects are completely unrelated, even if they are maintained separately and they do not depend on each other. In case you did not know that, will this fact make you stop using the GIMP completely just because you think that some of the people on this list have GNOME stamped on their forehead? Please calm down instead of trying to start a flamewar. This list is supposed to be for people who intend to write code or contribute to the development of the GIMP. It is not for arguing like kids about who does things better and whatnot. My personal opinion: I'm all for using some of the GNOME things (especially gnome-font, gtk-pixbuf and gnome-canvas) as long as they do not have any dependencies on ORBit or other stuff that is difficult to compile on non-Linux systems or stuff that is simply not needed. -Raphael
Re: Move help menu item to last-on-left not first-on-right?
On Thu, 10 Feb 2000, Nick Lamb [EMAIL PROTECTED] wrote: On Thu, Feb 10, 2000 at 04:47:48AM +0100, Marc Lehmann wrote: c) you gave _no_ reason why? Ah, that wasn't clear from my diagrams? GTK+ draws space either side of a menu item, so the Help menu can cover over Xtns, making it useless and forcing me to have an otherwise unnecessarily wide toolbox. If the Help menu was in the same SET of menu items as File, Xtns (ie on the left) it would never overwrite them, and therefore use less space. Also if we're going to have casualties from manually shortened toolboxes, Help is much less useful than Xtns, because its key features are duplicated elsewhere. Hmm... I should have written that before. For a first-time user of the Gimp, there is no problem: the default layout of the toolbox has the colors, brush and gradient to the right of the tools and aspect ratio of the toolbox is close to a square. Since there is enough room for the full menu bar in the default layout, the user will be able to access "File", "Xtns" and "Help" easily. Also, the location of "Help" is consistent with other applications. But things are different once you really start using the Gimp: most of the users that I have seen start by resizing the toolbox to the "traditional" shape which puts the colors, brush and gradient at the bottom of the list of tools. They prefer the thin aspect ratio because it is easier to work with the toolbox when it is on the edge of the screen and not taking too much valuable space near the center. Once you resize the toolbox, its size is saved in your sessionrc so it will always have the same shape (even after you upgrade, so it is easy for us to forget what the default layout looks like). If you have the "thin" layout, then there is not enough room for all items on the menu bar. For example, what I get under Solaris (the font sizes are slightly different under Linux) looks like this: "File X Help" As a frequent user of the Gimp, I use "Xtns" much more often than "Help" and I would certainly prefer the following layout: "File Xtns H" Or even this, if there was a way to persuade Gtk to reduce the reduce the space between the items: "File Xtns Hel" If there is no easy way for the Gimp to detect when the menu bar is too narrow (depending on the font size and other parameters), then I would prefer to have the help menu item changed from first-on-right to last-on-left. If it is possible to detect when the menu bar is too narrow (I haven't checked the Gtk code), then there are several things that could be done: - rename "Help" to "?", as Simon suggests - reduce the space between items, if possible - switch help from first-on-right (which would be the default) to last-on-left, dynamically -Raphael
An experiment (was Re: Move help menu item...)
Here is an interesting experiment for those who do not understand what the problem is with the "Help" item in the toolbox: - start Gimp - resize the toolbox so that all tools are on a single column (approx. 30 x 750 pixels) - try to open a new image, or to do anything useful The problem is that Gtk draws the "right" menu items on top of evetything else. So in this case the help item occupies all the space available and it is not possible to access "Xtns" or even "File". And if your window manager does not put decorations on the toolbox, then you cannot even quit the Gimp without resizing it first. So the users who prefer the thin and tall toolbox will have some problems with the help menu. I just discussed that with a colleague who suggested that the menu bar should not be part of the resizable toolbox because the two features "being able to use the menu" and "being able to resize to toolbox" are simply incompatible with each other (in some cases). There are several solutions to that: 1. Use WM hints to ensure that the toolbox has a minimum width. This is a bad solution (IMHO) because it would prevent some users from using their favorite layout and it is hard to take font sizes into account. 2. Try to take corrective measures in the Gimp when it detects that the menu bar is too narrow (as I described in my previous mail). Unfortunately, in the extreme case of a single tall column, only the "File" menu would be visible. 3. Make it possible to split the toolbox in several independent windows (menu, tools, colors stuff), or at least make it possible to detach the menu bar. 4. Use some tricks in Gtk to make sure that the full menu bar pops out as soon as the mouse passes over the visible menu area. The menu would be extended out of the toolbox window and would have the minimum size necessary so that all items are visible. I think that solutions 3 or 4 would be the best long-term solutions, but I doubt that we could have them in the next stable release. In the meantime, maybe solution 2 would be the best choice. -Raphael
Re: An experiment (was Re: Move help menu item...)
On Thu, 10 Feb 2000, "Daniele Medri" [EMAIL PROTECTED] wrote: about Toolbox resizeble. Flexibility is ok.. but some time create problems. Why don't set fixed sizes x*y to cover all the dimension of toolbar? This could be usefull to have right dimension and good rappresentation. Unfortunately, this is not so simple. Constraining the dimensions of a window requires some cooperation between the application and the window manager. Under X, you cannot simply tell the WM that some fixed sizes should be allowed for your window but not some others. All non-broken window managers accept the following XSizeHints: - minimum width and height - maximum width and height - size increment for width and height - minimum aspect ratio - maximum aspect ratio That's it. You cannot specify a list of allowed sizes. You could try to get close to that by specifying a size increment that is a multiple of the size of the icons and by setting a minimum value for the width of the window. But that would not help: if you set the minimum width to 30 pixels or so, then the menu is not usable. If you set the minimum width to something larger, then the menu may be usable but you are preventing some users from using their favorite layout (it is very useful to have a tall and narrow toolbox on the edge of the screeen). -Raphael
Re: An experiment (was Re: Move help menu item...)
On Sat, 12 Feb 2000, Jon Winters [EMAIL PROTECTED] wrote: ^ You seem to have a problem with the date on your computer. :-) I've had problems with the toolbox ever since it became re-sizable. I can size it exactly the way I want it, three vertical rows of tools with colors, brushes, patterns, and gradients below but the brushes, patterns, and gradients are always pushed outside the window, invisible and un-usable. Well, here is how I usually resize the Gimp toolbox so that it becomes usable: 1 - Increase the height of the window to more than 400 pixels. It is important to start with more than enough room at the bottom of the toolbox. 2 - Do not change the height but reduce the width of the window so that exactly 3 columns of icons fit in it. This is easier to do if your window manager allows you to resize a window only in one dimension (e.g. by dragging an edge instead of a corner). For me, the best width is 86 pixels. 3 - Do not change the width but reduce the height of the window so that there is no blank space left between the last row of icons and the fgbg colors. For me, this means 86 x 376 pixels. Another way to do it is to quit the Gimp, edit ~/.gimp-1.1/sessionrc and change the entry for the toolbox so that it contains "(size 86 376)". Hmmm... Maybe this should go into a FAQ or something... Note that I had some problems with some versions earlier than 1.1.16 (I don't remember which) that were very sensitive to any modification of their size, and I had to leave some blank space between the last row of icons and the fgbg colors in order to get it to work. -Raphael
Re: Toolbox layout and Help menu
On Fri, 11 Feb 2000, Sven Neumann [EMAIL PROTECTED] wrote: Your list looked interesting. But, you seem to ignore the menu problem. IMHO 2 columns is the absolute minimum since even then get problems with the Help menu. If we'd allow less than 2 columns, not even Xtns will be accesible any longer. Hey, don't prevent me from using one of my favourite layouts! :-) Really, having all icons on a single column is quite useful sometimes. As I mentioned in my previous message, this fits perfectly on a Sun screen (1152x900) because the height of the single-column toolbox is 880 pixels + the WM title. And since it is so thin, I can configure my WM to make the Gimp toolbox appear on all workspaces. I like this when I work with large images and I put one very large window in each workspace. I did not ignore the menu problem. If the "Help" bug is fixed (it is a one-line change in app/menu.c to make it last-from-left), then only the "File" menu is visible. But when I work with very large images, I do not need the "Xtns" menu at all, so I can live without it until I finish working on full-screen images and go back to a more traditional layout for the Gimp toolbox. That being said, I also like the columns-spinbutton idea, as long as the minimum is 1 column. I agree with the other parts of your message, and with your suggestion to move the Measure tool in the View menu or Info window. -Raphael
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, 22 Feb 2000, [EMAIL PROTECTED] wrote: On 22 Feb, Manish Singh wrote: True, although we have a couple other inconsistencies already. The coding style needs to be the same as the rest of gimp though. I tried to bring it as near as possible. Of course a lot things could be better I noticed two obvious differences in your code: it does not use two spaces for indentation (the default in Emacs and the recommended GNU style) and there is no space between the function names and the opening parenthesis for the arguments. I suggest that you use a recent version of GNU indent to process your source code and re-indent everything automatically, or that you use Emacs with the default settings (no modifications in a ~/.emacs file) and call indent-region on the whole file. I did not like the GNU style at first (especially the space before the opening parenthesis) but now I understand that it is very important to keep a consistent coding style in each project, because it keeps the code manageable and maintainable. So I always use whatever coding style is recommended for the each project, even if this means that I have to format my patches differently for the Gimp and for a Linux driver, for instance. Since the Gimp uses the GNU style, I think that it is important to follow the GNU coding guidelines faithfully. While we are on the subject of coding style, there are two areas of the Gimp that are not using a consistent coding style: the Script-Fu scripts and, to a lesser extent, the Perl scripts. Is there a recommended style for these? It's not that much code, and does fix a gaping hole in the i18n framework for plugins not distributed with gimp. Especially if we want 1.2 to last a while.. That's absolutely right. Yup! Me too (tm). -Raphael
Re: What should I change in Script-Fu scripts?
On Wed, 16 Feb 2000, Glyph Lefkowitz [EMAIL PROTECTED] wrote: Why are you bothering to change this behavior (edit/fill) when it makes sense to 1/2 of the people who use GIMP, it's a historical precedent in terms of the UI, and it's a huge amount of work to get to function correctly? Are there not enough bugs in the gimp that need to be fixed that more twiddling like this needs to be done? The "fill with background" behaviour is a historical precedent in terms of the _Gimp_ UI. But most of the other programs that I tried are using the foreground color. So although some of the old users who use Ctrl-. frequently might be confused if the Gimp starts to behave like other programs, this should be a good thing for most of the new users. Besides, why should we have a Fill Tool that fills with the foreground color by default and an Edit-Fill menu that fills with the background color? Even if we end up making this option configurable, I would like the defaults to be consistent. Regarding the "huge amount of work", I would say that this is a tedious task but it is not hard to get it to function correctly. On the other hand, this allowed me to see that some scripts had a number of bugs that had not been reported yet: for example the "3D Truchet" script does not restore the colors correctly upon exit. Another script (I forgot which one) creates a layer, fills it with the current color, and then "forgets" to use it in the image. On Thu, 17 Feb 2000, Sven Neumann [EMAIL PROTECTED] wrote: Sven, thanks for clearing that up. Well, it's not yet cleared up since we'll first have to agree if we want to change the Edit-Fill behaviour globally or not. My 0.02 Euro: I would like to change the Edit-Fill behaviour globally and at the same time provide a three-lines script (or code in the core) that would register itself as "Edit-Fill with BG" and would swap the colors, call gimp-edit-fill and restore the colors again. So those who prefer the current behaviour could bind Ctrl-. to it. -Raphael
Re: What should I change in Script-Fu scripts? (Summary)
I received several replies to my opinion poll, by private e-mail or on this list. Here is a summary of what I got so far: About changing the scripts that call gimp-edit-fill without setting the colors first (thus taking the current color in use): A1) No change to the scripts (they would then use the fg color) A2) Swap foreground and background A3) Add a new parameter to the dialog box so that the color has to be specified explicitely. Almost everybody supports A3) so I will implement that. About flattening the image or not: B1) No change to the scripts B2) Add a "flatten image?" option to all scripts, defaults to TRUE. B3) Add a "flatten image?" option to all scripts, defaults to FALSE. B4) Never flatten, but rely on the Export mechanism (it works well). For this, I got mixed opinions. Several people support B3, but I also received two suggestions to use B4. More opinions are needed... About the default text string in the logo scripts: C1) No change to the scripts C2) Use "The Gimp" as the default text in all scripts C2b)Use "The Gimp" and adjust the font size so that all scripts generate an image of comparable size when run with the default parameters. C3) Use the script name. Here, this is a 50%-50% match between C1 and C2 (or C2b). More opinions are needed... My personal opinion (in order to bias the votes towards C2b :-)) is that the first thing that most users will do when they want to produce a logo is to change the text (of course!) and some of the other parameters. But before creating a real logo with these scripts, it is useful to run all of them quickly with the default parameters in order to get an idea of what these scripts are doing. Running them quickly means not having to change the defaults. It is much easier to compare the results if the images have similar sizes and contain more or less the same text. Currently, this is not easy because you have the "Textured" logo using the default string "The GIMP" at 200 pixels while the "Bovinated" logo uses the longer string "Fear the Cow" at 80 pixels and the "Comic" logo uses the short string "Moo" at 85 pixels. About adding a "padding" parameter to the scripts: D1) No change to the scripts D2) Add the "padding" parameter to the scripts that create a textured background. Most people seem to support D2, so I will implement that. -Raphael
What should I change in Script-Fu scripts?
Yesterday evening, I started to edit the Script-Fu scripts so that
they fill with the foreground color instead of the background color.
There are 215 calls to gimp-edit-fill in the scripts delivered with
Gimp 1.1.17, and most of them are preceded by a call to
gimp-palette-set-background, which can easily be replaced by
gimp-palette-set-foreground in order to get the correct behavior.
However, I found a couple of logo scripts that are filling the
selection without setting the color first; they take the background
color that is currently in use when the script is run. You can see
this effect with the "Bovination" and "Comic Book" script, for
example: set the background color to pink or something easily visible,
then run the scripts and look at the results.
There are several ways to fix these scripts, and I would like to get
your opinions about this:
A1) Do not change anything in these calls to gimp-edit-fill, which
means that these scripts would now create a background layer
that is filled with the current foreground color.
A2) Keep the current behavior by adding something like
(gimp-palette-set-foreground (car (gimp-palette-get-background)))
before filling the layer, or by changing the layer creation mode
so that it is directly created with the current background color
instead of being created transparent and then filled later.
A3) Add a new parameter ("background color") to the script so that it
uses the value specified in the dialog box instead of using the
current colors.
I think that the last solution is the best one, but of course it
changes the interface.
And if I am changing the interface, there is another thing that might
be worth changing in the logo scripts: should they flatten the final
image or not? Some scripts silently flatten (parts of) the final
image, some others provide this as an option (a "flatten image?" check
box), and some others always leave all layers in the final image. I
would like to make them a bit more consistent. Again, there are
several options:
B1) Leave the scripts as they are now, even if there are some
inconsistencies.
B2) Add a "flatten image?" option in all scripts, with the default
value set to TRUE.
B3) Add a "flatten image?" option in all scripts, with the default
value set to FALSE.
B4) Remove all calls to gimp-image-flatten as well as the option to
flatten the image in the scripts that already have it, because it
is not so important to have this option anymore. In previous
versions of the Gimp, it was useful for the scripts to flatten the
image so that the users would not have to remember to do it (and
risk loosing part of their work) before saving the result as a GIF
or JPEG image. But the current version will automatically ask if
the image has to be flattened before saving it, so the risk of
saving the wrong layer and loosing some data is greatly reduced.
So maybe we could remove the flatten option from the scripts?
There are some other inconsistencies in the logo scripts: they use
different values for the default text string to be used in the logo.
Ten of them use "The GIMP" or "The Gimp" as the default text; five of
them use "Hello world!" some of them use some text related to the name
or function of the script (e.g. "Alien Glow" uses "ALIEN", "Carved"
uses "Marble") and the others use something unrelated to the name of
the script (e.g. "Comic Book" and "Gradient Bevel" use "Moo"). If I
have to change all scrips anyway, maybe I could make them more
consistent? Time for another opinion poll...
C1) Leave all scripts as they are. Diversity is fun. Besides, who
am I to decide what the default text should be? Each author has
the right to decide what is best.
C2) Change all logo scripts to use "The Gimp" as the default text (or
only "GIMP" for those such as "Alien Glow" that look better in all
caps).
C3) Change all scripts to use their name (or a part of it) as the
default text.
C4) Change all scripts to use "Moo!".
C5) Or maybe "SCRIPT-FU" as in the "Basic II" script?
And finally, some scripts such as "Carved" or "Textured" are using a
background texture that cannot be easily extended if the logo has to
be integrated in a larger image. So you have to take the background
as it is, or do a lot of hand-editing if you want the background
texture to cover a larger area. Although this is a new feature, I was
thinking about adding a "padding" option to some of these scripts.
This would allow you to specify some extra padding around the text, so
that you could have a larger background if necessary. Do you think
that I should:
D1) Forget this idea and leave the scripts as they are.
D2) Add a "padding" parameter to these scripts, so that it is possible
to specify a number of padding pixels around the text.
I would like to get the opinions of other developers about these
options. If you have something to say about this, please post it
either in
Re: What should I change in Script-Fu scripts?
On Wed, 16 Feb 2000, Sven Neumann [EMAIL PROTECTED] wrote: [...] B2) Add a "flatten image?" option in all scripts, with the default value set to TRUE. B3) Add a "flatten image?" option in all scripts, with the default value set to FALSE. B4) Remove all calls to gimp-image-flatten as well as the option to flatten the image in the scripts that already have it, because it is not so important to have this option anymore. [...] B2 or B3. I'm not sure if Flatten=TRUE is a reasonable default. Why hide the beauty of layers and masks? OK. I'll go for B3 then. C1) Leave all scripts as they are. Diversity is fun. Besides, who am I to decide what the default text should be? Each author has the right to decide what is best. C2) Change all logo scripts to use "The Gimp" as the default text (or only "GIMP" for those such as "Alien Glow" that look better in all caps). [...] C1. I don't see why you would want to change the default text the script author has choosen. Using the same string all over the place doesn't give any real advantage. Well, I think that it does have two advantages: you can easily compare the effects of several scripts on the same string, and that string contains a reasonable mix of letters (e.g. you could check if anything strange happens near the descender in the "p"). Hmmm... On the other hand, in order to make the comparison between scripts even better, maybe I should also change the default font size. Changing the font itself is not a good idea (many scripts produce much better logos with their default font because they were designed for it) but changing the default font size might be good. My goal would be that a user could try a script with the default values, then switch to another script and get something that is comparable: same text and same overall size. Currently, the user has to change the default values in most scripts in order to be able to compare them side-by-side. OK, so let's see who likes this new option: C2b) Change all logo scripts to use "The Gimp" as the default text and to use a font size such that the resulting images would have comparable sizes (of course the font size to use for each script would depend on some features of the default font, which would not be changed) -Raphael
Re: v 1.1.17 libintla error
On Wed, 16 Feb 2000, "Tony Webster" [EMAIL PROTECTED] wrote: During the make process on my Mandrake Linux 7.0 machine of Gimp 1.1.17 I received the following error. Running Mkbootstrap for Gimp::Lib () chmod 644 Lib.bs LD_RUN_PATH="/usr/local/lib" cc -o ../blib/arch/auto/Gimp/Lib/Lib.so -shared -L/usr/local/lib -l./../../../libgimp.libs -Lirprefix/../../libgimp -lgimp-L/usr/lib -lglib /intl/libintl.a Lib.o cc: /intl/libintl.a: No such file or directory This is looks like a bug in the Makefile for the Perl plug-in in 1.1.17. If you do not want to edit that file, you can configure the Gimp with --disable-perl (but then you loose Perl) or you can create as root a symbolic link /intl pointing to the correct directory. This bug will probably be fixed in CVS soon, if not done already. -Raphael
Cleaning up gimp_tips.txt
By some sort of strange coincidence, I was in the process of cleaning up the file gimp_tips.txt, when I saw the message from Ar't suggesting to update that file. Well, here are some tips that I would like to remove from gimp_tips.txt: : When trying to save files as GIF, XPM, or any other indexed : color format, you need to convert the image to indexed using : the Image menu. This is not true anymore. The Export feature works rather well for RGB-to-Indexed conversions and will also warn you if your image has multiple layers and the image format supports only one. : All the old channel operations have been replaced with the more : powerful and flexible Layer and Layer Mode operations. They may : take getting used to, but they are simply a better way to operate. This was only useful for users of Gimp 0.60 or so. Most of the current Gimp users have started with 1.0.4 or have had plenty of time to learn the new Layer operations, so this can be removed. : When installing a new version, be sure to : delete your ~/.gimp directory first. This is wrong for the 1.1.x releases, and should not be necessary anyway. I will also remove the FIXME comments, because they are obsolete. I think that we should not put too many tips in that file. Instead, we should focus on putting the most useful tips there and make sure that the user takes a look at the on-line help (which should contain most of the information that is currently provided by the tips). I added the "Tip of the day" feature to the Gimp some time ago because there was no decent on-line help that could explain some hidden things such as the usage of Shift and Ctrl while making selections. But now that the on-line help is shaping up, maybe we could change the tips and take the existing help pages into account. -Raphael
[Slightly off-topic] Gimp mailing list archives?
Is there any current archive for the Gimp mailing lists? All links given the www.gimp.org page are dead and should probably be removed (this also applies to the gtk-list). I have unsubscribed myself from the gimp-users list some time ago and I wanted to have a look at the current traffic before considering if I should re-subscribe or not, but I cannot find a working archive. -Raphael
patch for gimp_edit_fill
I just uploaded a new patch to ftp.gimp.org (the file name is gimp-quinet-000308-0.patch.gz). This patch fixes the problems with Edit/Fill by allowing the user to choose the fill mode. The "Fill with background color" is prefered by some users who have been using the Gimp for a long time, but this is considered as a bug (or a non-intuitive feature) by those who are familiar with most other paint programs and who prefer "Fill with foreground color". This patch adds a new parameter to gimp_edit_fill(), which specifies the fill mode (FOREGROUND_FILL, BACKGROUND_FILL, ...). It also replaces the menu entry "Image/Edit/Fill" with two entries "Image/Edit/Fill with foreground" (bound to Ctrl-,) and "Image/Edit/Fill with background" (bound to Ctrl-. as before). WARNING: this patch applies to the core only and does not modify any of the Script-Fu or Perl-Fu scripts. This means that all scripts using gimp_edit_fill() will be broken because of the extra parameter. A trivial fix is to add the parameter BACKGROUND_FILL to all calls to gimp_edit_fill(), or BG-IMAGE-FILL in Script-Fu. Tomorrow, I will upload a separate patch adressing this issue (and some other fixes) in Script-Fu. In the meantime, this patch can be used by anybody who wants to update the Perl scripts or to update the translation of the menus. The patch is against 1.1.18. I wrote the first version for 1.1.17, but I upgraded to 1.1.18 yesterday and re-built the patch to make sure that it applies cleanly. I did not have the time to finish cleaning up all the Script-Fu scripts, so I decided to split the patch in two parts and to upload the first part today so that others (Marc?) can start working on the Perl scripts. -Raphael
Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
This has been suggested before, but I would like to bring it up again... I think that it would be better to disable the installation of all Perl-Fu scripts if any of the required modules (Gtk, PDL, Data::Dumper, Parse::RecDescent) are not detected by the configure script or, more exactly, by Makefile.PL. The argument for installing the scripts anyway is that the user can install the missing modules later. However, I think that it currently does more harm than good. Note that I am not criticizing the Gimp-Perl plug-in itself, only the way the Perl-Fu scripts are installed. I have installed the Gimp on many systems (Linux and Solaris) and the Perl-Fu scripts are working fine on the systems that have perl and all the required modules. But on the systems that do not have perl (it comes with all Linux distros but it is optional) or those that do not have the required modules (because the user did not download them from CPAN), the Perl-Fu scripts crash when the Gimp is started or when they are accessed from the menus. This makes a bad impression and the best solution is usually to uninstall everything, then re-configure with --disable-perl, re-compile and re-install. This extra hassle should not be necessary. Here are a few reasons why I think that the configure script should skip the installation of the Perl-Fu scripts if any of the required modules is missing: - All other plug-ins take the "safe" approach of not installing themselves if any dependency is not satisfied. As far as I know, the Perl plug-in is the only one that tries to install everything and hope that the user will install the missing things later. - I think that most users are updating the Gimp (re-compiling, re-installing) more frequently than they are updating Perl (even if it is only some modules). So there is no reason to force the installation of the Perl-Fu scripts if they could easily be installed later, after having installed the missing modules. One reason for updating the Gimp more frequently is that it is easier to get a single tar file for the Gimp than to have to search for separate modules on CPAN, especially on a computer that has no direct connection to the Internet. Another example: on a multi-user system, the user may not have the required priviledges for installing the Perl modules in the system directories (although the modules could be installed in a private directory if the users take care of modifying their environment.) - The Gimp takes 5 to 6 seconds longer to start if the required Perl modules are missing, because some Perl-Fu scripts crash during start-up and are queried again every time. See the first example included below. Besides, these crashes are not very informative for the user if he is not the one who installed the software and who knows what these messages mean. - The modules that do not crash during start-up will fail anyway when they are used. Except for some things such as the Perl Server, I haven't found a script that was usable without Gtk-Perl. When I attempted to use these scripts, they all started by popping up a dialog box that warns about the missing module, then start some operations and crash before producing any result (which brings another dialog box for reporting the error). Again, for a user who is not the installer, it only makes the Gimp look bad because the menus are cluttered with unusable entries that do nothing else than popping up error boxes. See the second example below. For these reasons, I think that it would be better to use the "safe" method: do not install any (or most of the) Perl-Fu scripts if the required modules are missing during the "configure" phase. And rely on the fact that the person who installed the Gimp will re-install it easily if the Perl modules are installed later. -Raphael -- Example 1 -- Here are the messages that are displayed every time the Gimp starts, taking 5-6 seconds on a Linux PC that has perl but does not have the required modules from CPAN: Can't locate Gtk.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i586-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i586-linux /usr/lib/perl5/site_perl/5.005 .) at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/gimp/1.1/plug-ins/avi line 10. ** WARNING **: wire_read: unexpected EOF (plug-in crashed?) Can't locate Gtk.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i586-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i586-linux /usr/lib/perl5/site_perl/5.005 .) at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/gimp/1.1/plug-ins/colorhtml line 9. ** WARNING **:
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Wed, 8 Mar 2000, Seth Burgess [EMAIL PROTECTED] wrote: On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet wrote: This has been suggested before, but I would like to bring it up again... I think that it would be better to disable the installation of all Perl-Fu scripts if any of the required modules (Gtk, PDL, Data::Dumper, Parse::RecDescent) are not detected by the configure script or, more exactly, by Makefile.PL. Parse::RecDescent is used only by the script-fu to perl-fu converter, AFIAK. I get Data::Dumper installed as part of perl-base. If there's a perl distro without that, it probably won't be terribly useful for developing perl based scripts (guessing). In any case, if Parse::RecDescent is affecting running of any plug-ins, I'd call that a bug. If Parse::RecDescent is not needed for "normal users", i.e. those who do not have to use scm2perl or scm2scm, then maybe the Makefile.PL should not complain about it. The Gimp configure script does not complain if perl is missing, although it is required for developers who want to use the pdbgen. But this is a minor issue. As for Data::Dumper, it is indeed part of the default perl installation, but I think that some versions older than 5.005 had it as an option only. I do not know which versions exactly, but I know that I had to install the Gimp on some systems that had an old (and probably buggy) version of perl without Data::Dumper. As far as PDL and Gtk goes, I'm in agreement that it shouldn't install those scripts with those dependencies uless those packages are detected. gimptool should be able to install them later for users wishing to upgrade later - its the way everything else in gimp works. I'm glad to see that someone agrees... :-) perlotine: the gtk perl module is required to open a dialog window, running with default values (perl_fu_perlotine) perlotine: No horizontal or vertical guides found. Aborted. at /usr/lib/gimp/1.1/plug-ins/perlotine line 176. (ERROR) This error anyway is legit - you need guides to run perlotine! It would tell you so in a dialog box, but its not availble for lack of Gtk. In this case, I think the commandline is pretty clear. That's right. Sorry, that was a bad example. I should try that script again with some guides defined. Were the color related PDB errors pre or post Gimp-Edit-Fill changes? I captured most of these errors yesterday just after installing gimp-1.1.18 and before re-applying my gimp_edit_fill() patches. So these come from an unmodified 1.1.18 distribution. -Raphael
patch for gimp_edit_fill, part 2
I just uploaded the second part of my gimp_edit_fill patches to ftp.gimp.org. As soon as it is moved out of the incoming directory, you should be able to get it as gimp-quinet-000310-0.patch. This second part fixes the Script-Fu scripts so that they are compatible with the new interface to gimp-edit-fill. The full list of changes is described in gimp-quinet-000310-0.patch.README. Besides the simple updates to the scripts, I also fixed a couple of minor bugs, such as scripts that were not saving/restoring the active colors, or logo scripts that were using the active colors without allowing the user to specify them as parameters to the scripts. The only exception is the text-circle script that I left unchanged (using only the active colors). I also changed the interface to the coolmetal-logo script: instead of only having a "seascape" toggle that allows to choose the gradients "Horizon_1" or "Horizon_2", I added a gradient selector because there are more than two gradients that give good results with that script. For the carved-logo script, I added a padding parameter because it can be useful to have more space around the text if you want the background texture to tile correctly. I included a script of mine in the patch, called alien-neon-logo. Feel free to remove it if you do not like it (by the way, how can I make sure that it is sorted correctly in the menus?) I did not test or modify the scripts that were not affected by the gimp-edit-fill changes. Maybe I will do that later. I did not modify the Perl-Fu scripts either, because I am unable to test them on the computer that has my development environment. But it should be reasonably easy to update them semi-automatically. -Raphael
Gimp version number in $prefix/lib/gimp/* path names?
Does it make sense to keep on using the version number (1.0, 1.1) in the path for the $prefix/lib directory when it is not used for the files in the $prefix/share directory? Currently, all (binary) plug-ins and modules are stored in the directory $prefix/lib/gimp/1.1/plug-ins (which should probably be "libexec" and not "lib") and $prefix/lib/gimp/1.1/modules. The previous version of the Gimp used .../lib/gimp/1.0/... All other files are stored in $prefix/share/gimp, without any version number. This includes the gimprc file and the scripts, among other things. The original idea for using the version number in the path to the plug-ins was to allow future versions of the Gimp to co-exist in the same $prefix if possible. But it just does not work. You have to use a different $prefix or to change at least the path to $prefix/share if you want this to work, because the files that are installed in $prefix/share/gimp cannot be used by the old version of the Gimp. First, you would loose all scripts that are overwritten by the newer ones (with an incompatible API) and second, the old gimp would be confused by the new gimprc, which contains some options that are not understood by version 1.0 and sets the paths to use the 1.1 plug-ins and modules. So if the old and new versions cannot co-exist in the same $prefix anyway, why do we use the version number in the libdir? Or, alternatively, why don't we add the version number in the datadir? By the way, what will happen to the ~/.gimp-1.1 user directory when version 1.2 is ready? Will this be renamed to ~/.gimp or ~/.gimp-1.2 or ~/.gimp/1.2? -Raphael P.S.: I identified this problem when I tried to start an old version of the Gimp in order to check why the "Frosty" script was not giving the same results as in 1.0. If anybody knows why this logo script does not produce the same effects as it used to create, please tell me...
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Sat, 11 Mar 2000, Marc Lehmann [EMAIL PROTECTED] wrote: I just wanted to note that the suggestion of Raphael is based on assumptions that were either never true, or were true many months ago. Before all of you second his suggestions I would really appreciate it if people looked at the current situation. (I mean: think first!) Marc, it is unfortunate that you are replying in a defensive mode as if my message was a personal attack, because this is not the case. I tried to be as objective as possible and I took the time to check what I was talking about. Maybe I over-argumented my suggestions, but this is because a similar proposal that I sent several months ago was rejected because you said that all my claims were FUD. At that time, some of my assumptions were wrong and some other were right but my suggestions were ignored as a whole. Once bitten, twice shy. So I was more careful this time. I recently installed a new hard disk in my PC, so I decided to check everything on a "clean" system. I installed SuSE 6.3 (including perl, but not Gtk-Perl) and I downloaded, compiled and installed the latest versions of glib, gtk+ and the Gimp. First, I installed these packages with the versions 1.2.6, 1.2.6 and 1.1.17, respectively. Last week, I installed the versions 1.2.7, 1.2.7 and 1.1.18, respectively. So the current situation is: if you do not install the required Perl modules (especially Gtk.pm), most of the scripts do not produce any useful results. Besides, even if they would work, the pop-up messages warning the user about the missing module are not very friendly and lead the user into thinking that the Gimp is half-broken because the menus are cluttered with entries that generate warnings. Disabling all perl-plug-ins because somebody didn't want to check the facts is, for me, a very big decision that should not be made lightly. I agree, but this is _not_ what happened. I suggested to skip the installation of most Perl scripts if their prerequisites were not satisfied. The fact is that most of them do not work without Gtk-Perl and even if some of them would work, running only with the default arguments is not very useful. Running with the default parameters means that the user has no way to change how the script works (of course), has no way to guess what the script could be doing by looking at its parameters and cannot use the help to get additional information (the latter is annoying for newcomers). No script will show up in the menu if it depends on something not installed. For PDL, the scripts won't be installed in the first place. This is only partially true. Most of the scripts depend on Gtk. Currently they do not require it (i.e. it is optional) because they are supposed to be able to run without it by using only the default values, but this does not really work: all of them generate warnings, most of them crash, and their usability is limited. If you prefer, you can re-phrase my suggestion in the following way: all scripts that can use Gtk should _require_ it and should not be installed if Gtk is not present during the "configure" step. The scripts that have no user interface and no dependencies on other modules can be installed if they are useful. I sincerely hope that you will not consider this message as a personal attack. I am not trying to blame you for anything (I repeat that the Perl scripts do work fine on a system that has all required modules). I am simply reporting the fact that if you install the current version of the Gimp on a clean system that has Perl without the optional modules, the user will get a bad impression because many entries in the menus will either not work at all or will not produce useful results. So I am suggesting a solution, which is to disable the installation of anything that would appear to the user as being broken. This does not necessarily mean to disable everything. 1. If PDL is missing, no scripts depending on it will be installed. I don't see why all the majority of scripts not using PDL should also be disabled. OK, then you could just skip the installation of those scripts, and install those that have all their dependencies satisfied. 4. Gtk is a major problem. I feel that an effect running with (sane) default arguments is better then no script at all. It costs just the same mouse-clicks to use these scripts. If people disagree then this is the place to discuss it. That was my main argument. If Gtk is missing, the user will get many warnings (one pop-up every time they try to use a Perl script) which gives the impression that the Gimp is broken. After the warning, most of the scripts crash anyway. You could of course try to fix these crashes, because some of them look like real bugs in the scripts, but my message was not intended as a bug report... Even if the bugs are fixed, I think that it would be better to skip the installation of those scripts if they cannot have a user interface (besides
Re: running ldconfig
On Sun, 12 Mar 2000, Marc Lehmann [EMAIL PROTECTED] wrote: On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: 1. libtool should make sure that the libraries are found anyway (unless moved). ld.so.cache is only that, a cache Well, then gimp.m4 does the wrong thing, since after I install a new version of the Gimp I can't use gimp.m4 within autoconf to test for Ah, now I see the problem. Hmm... I guess shared libraries are still largely unexplored for the many ways to do it "right" :( Hmmm... Strange, because it works for me. Does that happen with the latest version of the Gimp, or with a version older than 1.1.17? Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". But "Elf" and "ldconfig" are not too related to each other. Yup! I have an elf-based Solaris system that does not know anything about ldconfig... :-) However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). First, I would like to be sure that it happens with the latest version of the Gimp. I just checked the source for 1.1.17 and 1.1.18, and both of them are distributed with a version of libtool that includes the following on Linux systems: finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir' This is run immediately after installing each library in $libdir. So at least the recent versions of the Gimp _do_ run ldconfig as part of "make install" and you should not have any problems. On the other hand, maybe you are having a problem with ld.so.conf, not with ld.so.cache. The latter is updated by ldconfig, but the former can only be modified by hand. I think that it would be wrong for a tool to attempt to modify ld.so.conf automatically, because the order of the directories is important and some modifications could break the whole system. -Raphael
Re: fu ?
On Tue, 14 Mar 2000, FUJITA Yuji [EMAIL PROTECTED] wrote:
1. Does anyone know what "fu" is ?
I mean "script-fu", "perl-fu" or some kind of these names.
I think that it was a pun on "kung-fu". Not sure, though.
2. What is the biggest barriar to support 16bit depth in the GIMP ?
I'm just reading xcf.c or tile.c and their related stuff and
am in distress.
Many parts of the code assume that an image channel has exactly 8 bits.
For example, all paint operations (brushes, bucket fill, transforms...)
work on 8 bits. Changing that is already a huge amount of work. But
this also applies to all plug-ins: they will have to be re-written in
order to take several bit depths into account.
Maybe you should have a look at Gimp16 project ("Hollywood"). I do not
know the current status of the project (it looks like nothing happened
recently) but the Gimp16 homepage is at:
http://film.gimp.org/
-Raphael
Re: running ldconfig
On Tue, 14 Mar 2000, Robert L Krawitz [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Raphael Quinet) Yup! I have an elf-based Solaris system that does not know anything about ldconfig... :-) It's happened with at least 1.1.17 and 1.1.18. The fact that you're using Solaris explains why you don't have a problem. Hmmm... I should have said that I _also_ have an elf-based Solaris system. My development machine at home is a PC running Linux (based on SuSE 6.3, as I described in another message). I did not have any problems on my Linux system, but this is probably because I am so used to running ldconfig after installing anything that I did not even remember that I had to use it. ;-) All that ldconfig -n does is create the links. It doesn't update the cache. ld.so (at least on Linux) needs the cache: You are right, I should have thought about why libtool uses the "-n" option. I think that libtool runs "ldconfig -n" because this is the only option that can be used safely, since it does not require more permissions than the ones for installing the libraries. Libtool already prints a message telling the user to run "ldconfig" or "ldconfig -v" after installing something, so any user who watches the installation process should know what to do. The Gimp Makefile (not libtool) could have an additional call to "ldconfig" or "-(PATH="\$PATH:/sbin" ldconfig) /dev/null" immediately after calling "$(LIBTOOL) --mode=install". But the installation rules in the Makefiles are generated by autoconf/automake and it could be a bit tricky to hack them. -Raphael
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
On Tue, 14 Mar 2000, Simon Budig [EMAIL PROTECTED] wrote: Marc Lehmann ([EMAIL PROTECTED]) wrote: This might work for python, but it will not work for perl. It will find the first perl in your path (which is often perl4), not the perl gimp was configured with. Are there really multiple different executables named "perl" (not "perl4" or so!) in your path? So when you work in your shell you always execute version 4 of perl, when you invoke "perl"? I suppose that Marc meant that the person running a Perl-Fu script might not the the person who has configured and installed it. It is likely that the one who configures the Gimp has set his path correctly (in order to be able to run configure without errors) but it can happen that another user has a broken path, with old tools listed first. In that case, the user would get a different version of perl than the one that Gimp was configured with. I think that the only way to guard against users having a broken path is to hardcode the location of the perl executable in the scripts. Actually, this should also be done for python because using "env" will create exactly the same problems. Just to give you an example, there are several versions of Perl in my path on one of the systems I use at work: $ /usr/bin/perl -v This is perl, version 5.003 with EMBED built under solaris at Nov 10 1996 13:23:19 + suidperl security patch ... $ /opt/local/bin/perl --version This is perl, version 5.004_04 built for sun4-solaris ... $ /Local/bin/perl --version This is perl, version 5.005_03 built for sun4-solaris ... There are also some older versions of Perl available, but fortunately they have been renamed (e.g. perl4, oldperl) so that they are not used by default. When I configure the Gimp, I always have /Local/bin first in my path. But this is not the case for all users: some of them have /usr/bin or /opt/local/bin first, so they will have problems if they try to execute the Perl-Fu scripts with perl 5.003 or 5.004. This problem can be solved by hardcoding the path to the perl executable in all scripts during the configure step. -Raphael
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Sun, 19 Mar 2000, Marc Lehmann [EMAIL PROTECTED] wrote: On Mon, Mar 13, 2000 at 05:01:56PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: [...] So the current situation is: if you do not install the required Perl modules (especially Gtk.pm), most of the scripts do not produce any useful results. This is a bug that was easily fixed once I was told about it. If you had filed a bug report on the gnome bugtracker, you would have been more than right to complain (I cannot read it as often as I wished), but as it seems you kept quiet until lately. OK, I should have used the bugtracker. Actually, I had a quick look at it some days ago (before sending my previous message) and I saw a few open bugs that were related to Perl scripts. I did not look at them (my connection was much too slow) and I though that they were reporting errors similar to the ones I saw, so I assumed that the problems were "well known". Well, I guess that I should double-check before I assume some things... [...] You could of course try to fix these crashes, because some of them look like real bugs in the scripts, but my message was not intended as a bug report.. I saw that, and I think this was very unfortunate :( OK. I should have spent a bit more time to make a complete bug report out of my message, instead of simply including the output from the crashes as an example. I spent some time testing all Perl-Fu scripts yesterday, so now I can send you a better bug report. [...] I would guess reporting bugs in any way (I'd prefer mail on gimp-developers or personal, to not clutter the list, but I understand the need to scan the gnome bugtracker very well!) would help the situation much more than asking for removing of plug-ins from the installation. Just let the maintainer decide wether he can fix it, or wether the script should be disabled, and bring the topic up when the maintaier (for whatever reasons) does not do it. For example, when I was away and a release needs to be made, disabling most or all of gimp-perl would be very viable :) I have just send a better bug report to the bugtracker, hoping that it will help you to fix the bugs in the scripts. However, I see that the form on Xach's site wraps the text in a very ugly way, so my nicely formatted bug report is now very difficult to read (#7732). I will send a copy of the bug report to you by private e-mail. ... when this is clearly not true. I believe that I understand the situation very well and I thought that my previous message contained enough explanations to make this clear. However, I still don't believe you... ;) I didn't meant to insult you in any way, I just wrote what I thought (and mostly still think). This is my opinion. If I wrote it in an insulting way, let me apologize. It was not what I intended. Well, I still think that I understood the situation quite well. ;-) The difference between you and me is mostly a matter of opinion. I consider that running the Perl-Fu scripts with the default values when there is no Gtk is a bad thing (because of the warning box, because it is difficult to guess what the script will do without seeing its parameters, because there is no help, because some scripts disable the undo on the image and because of the crashes that will hopefully be fixed). So that's why I consider that installing these scripts when Gtk is not present is a bug, or at least a disservice to the user. I understand that you disagree and you would prefer to install them anyway. Well, we can at least agree to disagree... Please, read my message again. This is _not_ what I suggested and I think that Sven and the others understood my message correctly. You did wrote this, whatever you really meant to write. And since you also wrote verbosely about your reasoning (which was based on "facts" which were wrong), I came to the conclusion that you lack a good enough understanding of the situation. Well, I still don't understand why you think that my message was based on incorrect facts. I just re-read the first message that I posted in this thread, and I don't see any incorrect facts. You may think that the _conclusion_ is incorrect because I suggest to disable the installation of the scripts using some optional modules (e.g. Gtk) when these modules have not been downloaded from CPAN (even if the scripts can run with some default values when Gtk is not there). You may also think that it was wrong for me to suggest to disable the installation of "any (or most of the) Perl-Fu scripts" if the required modules are missing, but this is because most modules use Gtk (and, as I wrote before, they should be considered as requiring Gtk because they do not work well with the default values -- even if the bugs are fixed.) I mentioned "most" as an alternative to not installing "any" scripts, simply because it is easier to skip the installation of everything du
Re: Getting patches
On Fri, 24 Mar 2000, "Ben Fowler" [EMAIL PROTECTED] wrote: [...] On my machine, I have gimp-1.1.15. If I choose to update it, I need a patch 1.1.15 - current level. So far as I can tell, only patches for previous level - current level are archived. I'm not sure that it would make sense to keep all old patches for the development versions (labeled "unstable"). Sometimes, the patches are rather big and it would be useless keep more than a couple of versions around because downloading all the patches from version 1.1.x to the current version could take more time than downloading the latest source package. Note that if you really want to access the old patches, I think that at least one of the mirrors of ftp.gimp.org does not delete the old files (or keeps them for a while before deleting them). I don't remember which one it it (or if it is still working), but maybe there is a chance to find the old patches somewhere. -Raphael
1.1.19 bugs and questions about pixmap brushes
Yesterday, I downloaded and installed 1.1.19 on a "clean" system. I found a number of bugs and I just reported them to the bug tracker. Here is the list, in order to avoid duplicate bug reports and more frustrations for those who are not aware of these bugs: - #8148: gimp cannot be built because gimp-perl depends on "msgmerge". - #8149: select by color crashes immediately - #8150: gimp crashes when loading an invalid brush - #8151: some layer names disappear in the layers dialog The bugs #8148, #8149 and #8151 are new to 1.1.19, because they were working fine in 1.1.18. The bug #8150 is not new and has probably been there for a long time because I was able to repeat it with some older versions of the Gimp that I still have. Known workarounds: - #8148: Configure the Gimp with "configure --disable-perl". - #8149: Do not use "Image/Select/By color" until the bug is fixed. - #8150: Be careful when installing new brushes. ;-) - #8151: click on the missing layer names. Sometimes they appear. One problem that worries me a bit is that the Gimp crashes immediately when loading an invalid brush. As you can see if you read the bug report #8150, you can create an invalid brush easily by putting random stuff in a file, naming it with the extension .gbr, .gpb or .gih and storing it in your ~/.gimp-1.1/brushes directory or in the system-wide brushes directory. What happens then is that the Gimp crashes as soon as you click on the "refresh" button in the brushes dialog. It will also crash immediately when starting, so you will not be able to start the Gimp until you delete the file. Of course, putting garbage in a brush file is not a very sensible thing to do and I could expect some problems when the Gimp tries to load the file. Well, in an ideal world the Gimp would report and error and ignore the brush instead of crashing. If I have the time, I will have a look at the code, add some safeguards and submit a patch. But it is unfortunately easy to create an invalid brush by using incorrect parameters in the gpb plug-in (which handles the .gpb and .gih formats). I have to admit that I discovered this bug by trying to save a pixmap brush without understanding the meaning of all parameters in Save/GIH. After I saved my test brush, I clicked "refresh" in the brushes dialog and the Gimp was gone. So my question is: could someone explain what these parameters mean and how to save a .gih brush in the correct format? Specifically, I have a set of layers that were originally grabbed from a .GIF animation and I would like to save them as a pixmap brush, so that I can follow a path with that brush and get some nice effects. I tried various tricks with the guides, with the number of cells in the .gih save dialog and so on, but I did not manage to get the effect that I wanted. I only managed to crash the Gimp... :-( Understanding how the thing is supposed to work would help me to fix the bug and to add proper safeguards in the code (both when saving and when loading pixmap brushes). Thanks in advance, -Raphael
Re: single-instance gimp? (using gnome)
On Wed, 29 Mar 2000, Federico Mena Quintero [EMAIL PROTECTED] wrote: This should really use a CORBA interface and register some sort of singleton factory object for images or other GIMP services. (Look at how singleton applications work in GNOME; the Midnight Commander or the Panel are good examples). YES! This is the right thing to do. But not for 1.2, unfortunately. In the past, I was reluctant to any dependencies on GNOME, because I did not really understand what the CORBA stuff in the gnome-libs was supposed to do. Like many other people, I feared that GNOME would creep on my system and slowly take over my desktop or some of my applications. Well, over the last year I discovered that it was not the case and that it was possible to install some GNOME libraries wihtout installing all the things that I did not need (limited bloat). I also checked that GNOME would co-exist peacefully with all the other things that I had on my machine. So I do not object to (and I would even encourage) the introduction of some bits of GNOME in the GIMP, because some libraries (libart, the new HTML widget, and all the component stuff) would be very useful and would avoid the duplication of efforts. For example, using CORBA to allow the GIMP to run only in a single instance would be nice. Also, it would be very useful to re-write the GIMP plug-in interface to use the GNOME component model, especially for the file plug-ins. I already mentioned during GUADEC that the GIMP file plug-ins could be used in Nautilus (or other applications) for generating thumbnails and previews. Many exotic file formats are supported by the GIMP and the plug-ins could be re-used in other applications. But this will not happen before 1.2, because it would require significant changes in the code. So let's keep this in mind for the next major release... Oh, by the way, I think that the "single instance" feature should be an option. Sometimes I really want to have two copies of the GIMP running side-by-side on the same machine (but not often, so the default should probably be to have only a single instance). -Raphael
Re: 1.1.19-installation fails
On Sun, 2 Apr 2000, Marc Lehmann [EMAIL PROTECTED] wrote: [...] Unless somebody comes up with a better solution, I'll try the following (Without any understanding of what I do): if @MSGFMT@ is != "" and != "no" then just assume MSGFMT is valid, and that msgmerge is somewhere in the path. Otherwise, just suppose @MSGFMT@ a msgmerge are not available. Ahhh... Now I think that I understand why gimp-1.1.19 cannot be built unless you disable Perl (see bug #8148). The problem is that if you find "msgfmt", you also assume that "msgmerge" can be found somewhere in the path. Unfortunately, many systems have msgfmt but do not have msgmerge. This is the default under Solaris (at least for Solaris 2.5.1, 2.6 and Solaris 7) and under SuSE Linux (unless you install the dev rpm that contains msgmerge). I think that msgfmt is more or less standard, but msgmerge is not. You only get the latter with GNU gettext, not with the other versions of gettext. Please add separate tests for msgfmt and for msgmerge. This would probably solve bug #8148. -Raphael
Updating the gimp_tips.txt file (Tip of the day)
I just saw that Austin Donnelly has filed a bug report (#8312) about the fact that the tips file is outdated. Two months ago (Fri, 18 Feb 2000), I posted a message to this list, suggesting some cleanups and pointing out the tips that are obviously obsolete. Earlier on the same day, there was a message by Ar't (Artur Polaczynski) saying that he was opening a page to collect new tips. Well, unfortunately the page has been empty since then. Does this mean that nobody cares and that I can simply go on and modify the file as I want? ;-) I hope that some people on this list have some ideas about tips that could be added to that file (and replace the old ones). It would be very nice if some of you could spend a few minutes and send their top 5 (or top 10) tips for the future gimp-1.2. They don't even have to be nicely formatted: I'm just interested in collecting new ideas so that I can organize them later and put them in gimp_tips.txt. Please send your tips to me or to the list. Thanks in advance. -Raphael P.S.: I would also be interested in some replies to my previous message about the pixmap brushes. Any information that could help me to fix the bugs in the current code would be welcom.
Re: 1.1.19-installation fails
On Thu, 6 Apr 2000, "William L. Sebok" [EMAIL PROTECTED] wrote: Marc Lehmann [EMAIL PROTECTED] says: The problem is that gettext itself does the detection (and so the only solutioon would be to rpelace the gettext.m4 macros by our own versions). I only get the results. You mean the gnu version of gettext itself does the detection of msgmerge. The problem is that the gnu version of gettext (and msgfmt) is not the only such version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. Hmmm... What he meant is slightly different, but close... When running the "configure" script, it runs some tests to detect what is on your system. Some of these tests are derived from the contents of the file aclocal.m4 that you can find in the top-level directory of the Gimp sources. The file aclocal.m4 is assembled (when the package is rebuilt) from a collection of *.m4 files provided by various packages. One of them is gettext.m4, which contains the tests for checking if gettext is present on your system. The problem is that the tests are verifying if your system has a working version of "msgfmt", "xgettext" and some other tools, but it does not check for the presence of "msgmerge". So it is wrong to assume that "msgmerge" is present if the tests for gettext are successful. Some Linux distributions as well as all versions of Solaris come with "msgfmt" but not with "msgmerge". I think that the only solution is to add a new test with AC_PATH_PROG or something similar in configure.in. -Raphael
Re: Thing for Tips and Re: [new stuff for gimprc]
On Sat, 15 Apr 2000, [EMAIL PROTECTED] (Guillermo S. Romero / Familia Romero) wrote:
[...]
Regarding what Sven said about this taking too much memory, i think
that there are _a lot_ more users using the Gimp for small images
(like web things etc.), and so perhaps Gimp should be tailored to
them to start with. Just IMHO :o)
Well, yes, that is true. Then 15 should be OK, IIRC I have been running with
a higher number (20 or more, maybe 100 sometimes, sorry but the info is in
another computer), doing small images with few memory (for today standards
for picture retouching, 64MB) but as you said, it was for web and such so
most of undos where just a pencil dot here and there, when doing hi-res I
lowered it to 5 or 10.
Who was reviewing the tips and trick phrases? This thing is a good one if
not already included ("You can choose how many undo levels, look in ...").
I am currently taking care of the tips. I will add one about the
number of undo levels. Thanks for the suggestion. I also take this
opportunity to thank those who have already e-mailed me some new tips.
Keep them coming!
Regarding the default number of undo levels, I think that 5 is OK. I
would not mind if the default was increased to 10, but I would
certainly not like to have it set to anything larger. If the default
number is too large, we would probably get many complaints from users
reporting that the Gimp uses way too much memory and disk space.
-Raphael
Re: can I create WBMPs in GIMP
On Mon, 17 Apr 2000, "Matthew Luchak" [EMAIL PROTECTED] wrote: You might think this a lazy question but I can't find any info on a WBMP plug-in for The Gimp - perhaps I'm blind. Hopefully this can restore your vision: http://registry.gimp.org/detailview.phtml?plugin=wbmp -Raphael
Re: gimp_ui_init @ 8bpp
On Wed, 26 Apr 2000, Michael Natterer wrote: [...] So the best thing is probably to remove install_cmap from gimprc and have only a min_colors options. But don't we have to tell plugins if the Gimp app installed a colormap? Or can we leave this decision to the plugin's GdkRGB instance? IMHO, telling the plugins if the Gimp app has installed a colormap will not help much (as long as our goal is to reduce colormap flashing between the app and the plugins) because if the app did install a colormap, you cannot be sure that the plugins will use exactly the same one. This is even more tricky when the app uses a non-default X visual, because some plugins do not choose the same visual. Here is a bit of context: one of the machines on which I test the Gimp is a Sun box running openwin in a mode that supports both 24 bpp and 8 bpp visuals simultaneously. The default visual (root window) uses PseudoColor (8 bits with a colormap) but some applications such as the Gimp, XV or Netscape select the "best" visual for their windows, which is TrueColor (24 bits). Here are some exceprts from xdpyinfo: name of display::0.0 version number:11.0 vendor string:Sun Microsystems, Inc. vendor release number:3600 [...] screen #0: dimensions:1280x1024 pixels (361x288 millimeters) resolution:90x90 dots per inch depths (3):1, 8, 24 root window id:0x37 depth of root window:8 planes [...] number of visuals:16 default visual id: 0x20 visual: visual id:0x20 class:PseudoColor depth:8 planes available colormap entries:256 red, green, blue masks:0x0, 0x0, 0x0 significant bits in color specification:8 bits [...] visual: visual id:0x2d class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits Using a PseudoColor visual (0x20) as the default allows me to run legacy X applications, while the more recent applications select a TrueColor visual automatically. So when the Gimp starts, it uses a 24 bpp visual. Until recently, there was a problem with some plug-ins such as "Filters/Map/Map Object" and "Filters/Light Effects/Lighting Effects" which did not use the same method as the main app for selecting the visual and colormap. As a result, these plugins were starting with the PseudoColor visual, which gave some ugly colormap flashing and reduced the quality of the previews. Well, unfortunately the problem is even worse with 1.1.20: I just tried these two plug-ins in order to check if they got better with the new code, but they crash. Most plugins work fine, but the two mentioned above crash shortly after opening their window. The crash seems to happen when they try to display the preview, and generates the following error: Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 653 error_code 8 request_code 72 minor_code 0 I haven't analyzed this in detail yet (so I haven't submitted a bug report yet) but according to Xproto.h, the request code 72 is the code for XPutImage. I suspect that these two plugins are now opening their window with the correct visual, thanks to the changes done by Mitch, but unfortunately there is some old broken code that creates the preview with a bit depth taken from the default visual instead of the current one. So... Hmmm... All this verbosity was about this: we should not only ensure that the plugins are using the same colormap as the main app, but this should also be done for the visual. I don't know if this info should be transmitted over the wire or if some part of libgimp should ensure that all plugins make the same choices in the same way, but it should be consistent. Side note: IMHO, min_colors is better than install_cmap. But maybe there could be a problem if some other application allocates or releases some colors while the Gimp is running: if the number of available colors is just around the threshold, the plugins could take different decisions about the colormap depending on when they are started. That would be a bit strange. -Raphael
Re: Gimp now requires Glib 1.2.7?
On Tue, 2 May 2000, Pierre Rochefort [EMAIL PROTECTED] wrote: I got the sources out of CVS and tried to compile. I have Glib 1.2.6 installed and it used to work fine (up until this morning). Has the requirement changed in regards to Glib? Yes. The current version of the Gimp requires glib-1.2.7 and gtk+-1.2.7. It is very likely that the final release will require gtk+-1.2.8 (not released yet) because some dnd bugs have been fixed recently in gtk. -Raphael
Re: Gimp 1.1.21 build fails under Solaris because of Linuxisms
Oops! I forgot the second part of my patch. The problem with SA_NOMASK is also present in app/main.c: --- app/main.c~ Mon May 1 19:43:09 2000 +++ app/main.c Tue May 2 17:49:05 2000 @@ -334,15 +334,15 @@ /* Handle some signals */ - gimp_signal_private (SIGHUP, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGINT, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGQUIT, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGABRT, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGBUS, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGSEGV, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGPIPE, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGTERM, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGFPE, on_signal, SA_RESETHAND | SA_NOMASK); + gimp_signal_private (SIGHUP, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGINT, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGQUIT, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGABRT, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGBUS, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGSEGV, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGPIPE, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGTERM, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGFPE, on_signal, SA_RESETHAND | SA_NODEFER); #ifndef __EMX__ /* OS/2 may not support SA_NOCLDSTOP -GRO */
Gimp 1.1.21 build fails under Solaris because of Linuxisms
I just downloaded 1.1.21 and I tried to compile it under Solaris. The build breaks early while compiling libgimp, with the following error: gimp.c: In function `gimp_main': gimp.c:202: `SA_NOMASK' undeclared (first use in this function) gimp.c:202: (Each undeclared identifier is reported only once gimp.c:202: for each function it appears in.) make[2]: *** [gimp.lo] Error 1 make[2]: Leaving directory `/Local/build/gimp-1.1.21/libgimp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Local/build/gimp-1.1.21' make: *** [all-recursive-am] Error 2 Fortunately, I have access to a Linux box from which I could see what this mysterious SA_NOMASK was supposed to be. A comment in the file /usr/include/asm/signal.h says: [...] * SA_ONESHOT and SA_NOMASK are the historical Linux names for the Single * Unix names RESETHAND and NODEFER respectively. */ The file libgimp/gimp.c uses the correct SA_RESETHAND together with the obsolete SA_NOMASK instead of SA_NODEFER. Because of this, I suppose that it is impossible to compile the Gimp on any UNIX-like system except for Linux. The patch, appended below, is trivial: simply replace all occurences of SA_NOMASK with the correct symbol SA_NODEFER. This solves the problem under Solaris, at least. But maybe it would not be more appropriate to add some #ifdef HAVE_SA_xxx in the code, together with some extra tests in configure.in. Note: I am reporting this to the list because I am not sure if the Gnome bug tracker and Xach's bug report form are working or not. On Friday, I tried to report a bug (about drawing straight lines in different views of the same image) but I did not get the usual e-mail confirmation and my bug report was probably lost. Can anyone confirm that the form and the bug tracker are working? -Raphael - --- libgimp/gimp.c~ Mon May 1 19:43:17 2000 +++ libgimp/gimp.c Tue May 2 17:14:12 2000 @@ -199,21 +199,21 @@ * has been built with MSVC, and the user has MSVC installed. */ gimp_signal_private (SIGHUP, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGINT, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGQUIT, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGBUS, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGSEGV, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGPIPE, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGTERM, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGFPE, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); #endif #ifndef G_OS_WIN32
Perl-Fu plug-ins in 1.1.21
I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of them abort with the following error displayed on the console: ** ERROR (recursed) **: could not find handler for message: 65536 aborting... And this message is displayed in a pop-up box: [/path/to/script]: the gimp is using a newer version of the plug-in protocol than this plug-in. Marc, I suppose that you are aware of this and that you can fix it? I suppose that this was a consequence of the recent changes in the wire protocol. Hi Mitch! ;-) But I also noticed that something else has changed in the Perl-Fu scripts: in the previous versions that I tried (under Solaris), these scripts were always registered at the bottom of the menus, instead of being mixed with the C plug-ins. Now it seems to be the contrary: the Perl-Fu scripts are listed first in each menu, followed by the usual C plug-ins. This is very distracting. Would it be possible to avoid this? I would prefer to have the Perl-Fu scripts separated from the C plug-ins. Either by adding a separator in the menus, by adding a little mark next to their names, or by creating a separate Perl-Fu menu similar to the Script-Fu menu. I am asking for this on the list because I expect that many developers have different opinions about the placement of Perl-Fu scripts (or Python-Fu). I think that the Perl-Fu scripts "feel" different from the C plug-ins and it would be nice to know beforehand if an entry in a menu is mapped to a C or Perl plug-in. They behave slightly differently (e.g. undo is not always supported, there is a delay of a couple of seconds before the plug-in starts) and their parameters dialog have a different layout compared to most C plug-ins. I suppose that some of these differences (e.g. the Gimp-Perl logo in the dialogs) were introduced on purpose to make these scripts stand out from the others, but then why should they be mixed? I'm not asking for a vote or anything like that, but I would like to hear some opinions... (no flames please) -Raphael
Re: Perl-Fu plug-ins in 1.1.21
On Wed, 3 May 2000, Marc Lehmann [EMAIL PROTECTED] wrote:
On Tue, May 02, 2000 at 08:15:44PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote:
I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of
them abort with the following error displayed on the console:
** ERROR (recursed) **: could not find handler for message: 65536
aborting...
This happens to any plug-in that doesn't get recompiled when a protocol
bump occurs. Recompiling the perl plug-in would fix that.
Well, for some reason it didn't, that's why I reported the bug.
I extracted gimp-1.1.21.tar.gz in a new directory and built everything
from there. Then I removed everything from the previous installation
of the Gimp in ${prefix}/lib/gimp and ${prefix}/share/gimp and I did a
"make install".
That's why I am surprised to get this problem: I double-checked that I
had no old files in the plug-ins directory before reporting this
strange bug. The only files that are in the plug-in-path came from a
fresh install of 1.1.21. I also re-did a "make" and "make install" in
the source tree to be sure that I was not dreaming. :-)
Marc, I suppose that you are aware of this and that you can fix it?
If you give me a log-in on your machine I could fix it ;)
I could give you a username and password, but that would not help you
because the firewall blocks everything. :-) Even I cannot log in from
home. But if you want to come and say hello, I can give you my work
address and a roadmap of the area. ;-)
Err... Seriously, do you or anybody on this list have any idea of
what could be causing this strange problem? Can anyone report a
successful or unsuccessful installation of 1.1.21 with Perl enabled?
My setup is:
Solaris 2.6
perl5.005_03
PDL-2.003
Parse-RecDescent-1.70
Gtk-Perl-0.6123
glib-1.2.7
gtk+-1.2.7
gimp-1.1.21
being mixed with the C plug-ins. Now it seems to be the contrary: the
Perl-Fu scripts are listed first in each menu, followed by the usual C
plug-ins. This is very distracting.
Hmm... I wonder how the order in the menus is being worked out by the
Gimp? Registration order? Alphabetical? Being able to control the sort
order in some sensible way is highly desirable indeed, but will definitely
not happen in 1.2 (IMHO it's very difficult).
What happened in your case might have been that all the C-plug-ins
(that were reinstalled) registered below the existing plug-ins and the
perl-plug-ins (which you haven't reinstalled) moved to the top.
Unfortunately, this is not what happened. As I said, all the plug-ins
and scripts came from the new 1.1.21 package. I just checked a second
time by deleting my ~/.gimp-1.1/pluginrc and the Perl-Fu scripts
register again before the C plug-ins. This appears to be new,
although I do not know when this behavior was introduced because the
previous version (1.1.20) had another problem with the Perl-Fu scripts
and they crashed before registering.
a menu is mapped to a C or Perl plug-in. They behave slightly
differently (e.g. undo is not always supported, there is a delay of a
couple of seconds before the plug-in starts)
This describe the behaviour of a subclass of all perl scripts. _Some_ C
plug-ins behave the same, btw, as well.
If you look at earlier discussions of this and related points you'll see that
a seperate menu hierarchy hardly makes sense.
The same arguments apply to Script-Fu as well, however there is still
a separate menu hierarchy for these scripts. But maybe a separate
menu hierarchy is not the best solution...
OTOH, I'd be all for some visible indication in the menus itself (although
I am not 100% of wether that makes sense ;) It does not have any
drawbacks, however).
I don't know if it makes sense, but I would like to have some kind of
indication before 1.2 is released. I was hoping that some people on
this list could reply with good suggestions...
for a vote or anything like that, but I would like to hear some
opinions... (no flames please)
This has been discussed many times on this list already...
I know, but the final release of 1.2 is just around the corner now and
several things have changed since the last time these things were
discussed.
Also, I have the feeling that many people (not you, of course) do not
care too much about the Perl-Fu scripts and do not even test them. I
am sure that I am not the only one who is worried about the overall
consistency of the user interface, but I am surprised by the lack of
comments about Perl-Fu... Where are the "many eyeballs" that ensure
that "all bugs are shallow"?
-Raphael
Installing a pre-built pluginrc in the users' .gimp directory [patch]
I frequenty install the latest version of the Gimp on several
multi-user systems (Solaris and Linux). One thing that is frequently
reported by new users is that it takes a long time to start the Gimp
for the first time. I explain that it has to query all plug-ins once,
which is slow because of the heavily loaded NFS server and network,
but it is faster on subsequent runs.
This morning, I realized that it does not have to be that slow: a
pre-built pluginrc file could be installed each user's directory and
the first run will be much faster (the difference is not so big on a
single-user system, but it is significant when every executable has to
be fetched from the NFS server and run locally). Even if some
plug-ins are updated or removed later, the consistency checks that are
already done on the pluginrc should ensure that everything is OK.
Included below are two simple patches that could solve this problem.
The first one is an addition to the user_install script: if there is a
pluginrc file in the ${prefix}/share/gimp/1.1 directory, then copy it
to the user's private .gimp-1.1 directory. If no pluginrc file has
been installed there, then do nothing (some administrators may not
want to run the next step explained below). The installation dialog
already explains what the pluginrc file is used for, so there is
nothing to add there.
The second one is an addition to the Makefile (Makefile.am): a new
target "make install-pluginrc" can be used after "make install". It
will run the Gimp in batch mode and exit immediately, so that a
pluginrc file is created in the administrator's home directory. This
file is then copied into the gimpdatadir in the same way as the other
files.
I added a separate rule instead of extending the "make install" target
because some administrators may not want to start the Gimp from a
priviledged account. In this case, they can start it from another
account and copy the file manually, or simply ignore this step (which
is why the user_install script tests if the pluginrc file has been
created or not).
Does this make sense? If yes, then I could re-submit this patch to
ftp://ftp.gimp.org/incoming/, together with some updated instructions
in the INSTALL file.
-Raphael
--- user_install~ Wed Mar 15 00:18:04 2000
+++ user_installWed May 3 16:07:17 2000
@@ -22,6 +22,11 @@
echo "cp $1/gtkrc $2/gtkrc"
cp $1/gtkrc $2/gtkrc
+if test -r $1/pluginrc; then
+ echo "cp $1/pluginrc $2/pluginrc"
+ cp $1/pluginrc $2/pluginrc
+fi
+
echo "mkdir $2/brushes"
mkdir $2/brushes
echo "mkdir $2/generated_brushes"
--- Makefile.am~Mon Apr 24 20:55:08 2000
+++ Makefile.am Wed May 3 16:46:16 2000
@@ -145,6 +145,20 @@
uninstall-local:
rm -f $(DESTDIR)$(bindir)/gimp-config
+install-pluginrc:
+ @if test -x $(DESTDIR)$(bindir)/gimp; then \
+ echo " Starting gimp in batch mode to create/update pluginrc"; \
+ $(DESTDIR)$(bindir)/gimp --batch '(gimp-quit 0)'; \
+ p=pluginrc; \
+ file=$(HOME)/$(gimpdir)/$$p; \
+ if test -f $$file; then \
+ echo " $(INSTALL_DATA) $$file $(DESTDIR)$(gimpdatadir)/$$p"; \
+ $(INSTALL_DATA) $$file $(DESTDIR)$(gimpdatadir)/$$p; \
+ fi; \
+ else \
+ echo "Please run 'make install' first."; \
+ fi
+
.PHONY: files populate checkin release
files:
Proposal for new gimp_tips.txt
Here is a new version of gimp_tips.txt that could be used for the next release. Thanks to those who sent me some very useful suggestions! Please have a look at this file and tell me if anything should be added or removed. Some of the things that have changed: - New comment for translators, suggesting to keep the english version of the tips as comments in the translated file. It would be easier for someone who does not speak that language to check that the file is up-to-date or to check if some new and useful tips have been added in the translated version. Maybe this explanation could go into a README file, now that the tips are in a separate directory? - I removed some of my old FIXME comments as well as the tips refering to the old (pre-1.x) version of the Gimp. - The tips suggesting to flatten an image before saving it are not needed anymore because the Export feature works well. - Several new tips have been added: drag and drop, usage of the Channels and Paths, ... I am including the full file here because it is not too big (7 Kb) and it is smaller and more readable than a diff. I hope that nobody will complain... Please send your comments! -Raphael --- # This is a list of tips for the GIMP. Every time the GIMP is # started, one tip will be selected from this file and will be # displayed in the "Tip of the day" dialog. # # - Lines starting with '#' are comments. # - Blank lines or comments separate two tips (they are not ignored). # Multiple blank lines are treated as one. If you want to have a # blank line in a tip, put a space or tab in it. # - Text will appear in the dialog as it is in this file. This is # done on purpose in order to have more freedom in the layout of the # tips than with automatic word-wrapping, but this also means that # you have to avoid excessively long lines in this file. # - Tips should be concise: 3 lines or less. # - Advice for translators to other languages: keep the original tips # as comments before the translated tips. It will be easier for # other people to check for changes or additions. # # Tips in this file have been contributed by Zachary Beane, Mo Oishi, # Raphael Quinet, Sven Neumann, Carey Bunks and other people on the # gimp mailing lists and newsgroup (comp.graphics.apps.gimp). # # The first tip should be a welcome message, because this is the # first thing that a new user will see. # Welcome to the GIMP ! Nearly all image operations are performed by right-clicking on the image. And don't worry, you can undo most mistakes... # Tips for beginners start here # (for people who are not familiar yet with layers and image formats) # You can get context-sensitive help for most of the GIMP's features by pressing the F1 key at any time. This also works inside the menus. The GIMP uses layers to let you organize your image. Think of them as a stack of slides or filters, such that looking through them you see a composite of their contents. You can perform many layer operations by right-clicking on the text label of a layer in the "Layers, Channels and Paths" dialog When you save an image to work on it again later, try using XCF, the GIMP's native file format (use the file extension ".xcf"). This preserves the layers and every aspect of your work-in-progress. Once a project is completed, you can save it as JPEG, PNG, GIF, ... The layer named "Background" is special. You can't add transparency or a layer mask to it. To add transparency, you must first "add alpha" to the layer by right-clicking in the layers dialog and selecting "Add Alpha Channel". Most plug-ins work on the current layer of the current image. In some cases, you will have to merge all layers (Layers-Flatten Image) if you want the plug-in to work on the whole image. Not all effects can be applied to all kinds of images. This is indicated by a grayed-out menu-entry. You may need to change the image mode to RGB (Image-Mode-RGB), add an alpha-channel (Layers-Add Alpha Channel) or flatten it (Layers-Flatten Image). # Tips for intermediate users start here # You can drag and drop many things in the GIMP. For example, dragging a color from the toolbox or from a color selector and dropping it into an image will fill the current image or selection with that color. When using a drawing tool (Paintbrush, Airbrush, or Pencil), Shift-click will draw a straight line from your last drawing point to your current cursor position. If you also press Ctrl, the line will be constrained to 15 degree angles. The file selection dialog box has command-line completion with Tab, just like the shell. Type part of a filename, hit tab, and voila! It's completed. You can reassign shortcut keys on any menu by bringing up the me
Re: Proposal for new gimp_tips.txt
Posting a new version of the gimp_tips file caused some quick replies with new tips. Thanks to Austin Donnelly, Andy Thomas and Garry Osgood who sent some proposals. Here is a short unidiff (diff -U 0) of the file, compared to the version posted yesterday. If there are no more comments on it until Monday, then I will submit a patch so that the translators can start working on it. -Raphael --- /home/quinet/gimp_tips.txt~ Thu May 4 18:22:59 2000 +++ /home/quinet/gimp_tips.txt Fri May 5 13:06:13 2000 @@ -50,4 +50,4 @@ -The layer named "Background" is special. You can't add -transparency or a layer mask to it. To add transparency, you -must first "add alpha" to the layer by right-clicking in the -layers dialog and selecting "Add Alpha Channel". +The layer named "Background" it special because it lacks transparency. +This prevents you from adding a layer mask or moving the layer up in +the stack. You may add transparency to it by right-clicking in the +"Layers, Channels and Paths" dialog and selecting "Add Alpha Channel". @@ -68 +68 @@ -a color from the toolbox or from a color selector and dropping it into +a color from the toolbox or from a color palette and dropping it into @@ -116,0 +117,4 @@ +If you stroke a path (Edit-Stroke), the current drawing tool and its +settings are used. You can use the Paintbrush in gradient mode, the +Clone tool with a pattern or even the Eraser or the Smudge tool. + @@ -129,0 +134,3 @@ +If your screen is too cluttered, you can press Tab multiple times +in an image window to hide or show the toolbox and other dialogs. + @@ -155 +162 @@ -Download and install them. Some font servers also allow you to use +Download and install them. Some font servers allow you to use @@ -166,0 +174,5 @@ + +If some of your scanned photos do not look colorful enough, you can +easily improve their tonal range with the "Auto" button in the Levels +tool (Image-Colors-Levels). If there are any color casts, you can +correct them with the Curves tool (Image-Colors-Curves).
Re: Proposal for new gimp_tips.txt
I should have waited a bit more before sending my previous mail, because I did not see Sven's reply on time... On Fri, 05 May 2000, Sven Neumann [EMAIL PROTECTED] wrote: [...] Well, dragging does work, but using the icons as buttons instead of a drag target is much faster and easier. You'll probably want to change this to: A Floating Selection must be anchored to a new layer or to the last active layer before doing other operations on the image. Use the New Layer or Anchor Layer buttons in the "Layers, Channels and Paths" dialog, or use the menus to do the same. OK. You can save a selection to a channel (Select-Save to Channel) and then modify this channel with any paint tools. Use the "Channels" tab in the "Layers, Channels and Paths" dialog to toggle the visibility of this new channel and to perform various operations on it. Huh? This is misleading. The Channels tab does not toggle the channels visibility. That sentence needs to be rewritten. Here is another version: You can save a selection to a channel (Select-Save to Channel) and then modify this channel with any paint tools. Using the buttons in the "Channels" tab of the "Layers, Channels and Paths" dialog, you can toggle the visibility of this new channel or convert it to a selection. I think that it is important to mention how to toggle the visibility of the channel masks, because the channels that are created with Select-Save to Channel are not visible by default. This can be a good thing for experienced users, but confusing for new users. This is even more confusing because the new channel becomes automatically active, and you cannot draw in the image anymore. By the way, I wrote "Using the buttons..." but this assumes that the user understands that the eye icons are buttons, even when they are not there (not visible). If someone can provide a better wording that fits in 4 lines or less, please tell me... -Raphael
Re: EPIPE
On Wed, 10 May 2000, Michael Natterer [EMAIL PROTECTED] wrote:
Michael Natterer wrote:
Austin Donnelly wrote:
[ two mails i totally agree with ]
I'm about to commit some code which should bring the signal
stuff into a sane state. The ChangeLog entry is quite verbose
and should explain how I tortured the code.
Um, 1 minute later I found a bad bug. No commit today :(
I don't know if this is relevant (I haven't seen the code that you
wanted to commit), but here are some general comments about signals
and when they are usually triggered in programs similar to the Gimp...
- SIGHUP, SIGINT, SIGQUIT, SIGTERM: usually triggered by the user or
by the system shutting down. They can be delivered at any time.
- SIGPIPE: an attempt to write() or send() something on a socket has
failed because the other party has closed the connection. This
signal is usually triggered from within the system call, which is
often called from inside a high-level function such as printf().
Since most versions of printf() are not re-entrant, it is usually
a bad idea to call printf() or any stdio function in the signal
handler.
- SIGSEGV: just say "Oops!" or "Eek!". Some bug in the code has
corrupted the memory. Usually happens when trying to dereference a
NULL pointer or a pointer that has been overwritten with garbage.
This also happens quite often inside printf() or sprintf(), for
example when you are printing some debugging messages (or error
messages) and you did not think that some arguments may be NULL.
For this reason, it is also a bad idea to call any stdio functions
inside the handler for this signal.
- SIGBUS: mostly a variant of SIGSEGV. Happens on many processors
when you are trying to access some unaligned data. Again, this is
usually due to pointer corruption.
- SIGILL: one some processors that do not deliver SIGBUS in all cases,
you can get a SIGILL if a pointer to a callback function was
overwritten with garbage. If the pointer is still referencing some
area inside a code segment (so that you don't get a SIGSEGV) but not
pointing to the start of a valid instruction, you will get the SIGILL.
By the way, the Gimp does not catch this one. Why?
- SIGFPE: usually comes from a division by 0, although some other
errors (overflow, invalid operand) can also occur. This is usually
triggered while executing a floating-point operation, although some
processors or OS's can delay the signal.
- SIGABRT: usually triggered by the application calling abort() or by a
user who wants to get a core dump from a running process. It can be
caught by an application that wants to perform some specific cleanup
tasks, but in most cases it should not be caught by a generic error
handler. I don't understand why the Gimp maps this to the generic
gimp_fatal_error() function???
- SIGCHLD or SIGCLD: a child process died. This signal can be
delivered at any time. Some systems do not provide a reliable way
to know how many processes exited (if they do not support SA_NODEFER
or if their waitpid() or wait3() calls are broken), so it is usually
better to simply set a flag in the signal handler (without calling
any wait*() function) and to check the status of the children outside
the signal handler, until some wait*() function reports that there
are no more dead processes. For example:
while ((pid = waitpid (-1, status, WNOHANG)) 0)
{ ... /* check WIFEXITED(status) and other things */ }
In most of the applications that I wrote, the signal handlers do
nothing directly: they only set a flag that is checked by the main
loop (in an idle function for GTK+ apps, or after poll() or select()
for applications that use low-level calls). I define one flag for
each signal (got_sigchld, got_sigterm, ...) and a master flag that
tells if any of the signal-specific flags have been set. Sometimes I
also use counters instead of boolean flags, but on some systems the
counters are not reliable (especially if there is no SA_NODEFER) so
most of the time they are meaningless.
In one application that wanted to catch SIGSEGV, SIGBUS, SIGILL and
SIGFPE, I created a handler that uses a direct call to write() on an
fd that was previously obtained from fileno(stderr) (this fd is saved
early so that the write() call can work even if the FILE *stderr is
overwritten with garbage). Doing this is safe, AFAIK.
In most cases, I ignore SIGPIPE (or I only increment a counter for
debugging purposes) because the best way to deal with this is to check
the return value of the write() or send() calls, or to check if a
read() returns 0 later.
Just my 0.02 Euro. But you probably knew all of this already...
-Raphael
Re: Solaris - Help!
On Wed, 10 May 2000, Anton Enright [EMAIL PROTECTED] wrote: I'm trying to get Gimp 1.1.21 to work correctly on Solaris 7 I've compiled the code fine this morning, and apart from the Error below it runs fine: gimp: shmat failed...disabling shared memory tile transport This is very common under Solaris and this is not a cause for concern. The problem is that the default configuration of Solaris (all versions so far) sets a very low limit on the total amount of shared memory (shm) that can be allocated by a process. The Gimp exceeds this limit while starting, but this is not a problem because it reverts to another method that is a bit slower but does the same things anyway. If you want to get rid of these error messages, you can do two things: - start the Gimp with --disable-shm and --disable-xshm. - edit /etc/system on your machine and increase the values for shm. I think that there is some GIMP or GTK+ FAQ that explains this. The Problem is that, anytime I click on the text button, then type in some text, nothing happens, the image reappears without any text whatsoever. I am running the Gimp on Solaris 2.6 and Solaris 7 but I did not see any problems. The text tools work for me (both the regular one and the dynamic text tool). Note that by default, no font is selected so you have to click on some font name before the text tool can be used (the dynamic text tool shows the default font name as being "application", which does not exist so you have to select another one). Note that I compiled under Solaris 2.6, so maybe there are some differences (especially if you use the 64-bits mode). It would be interesting if you could provide a bit more infos about this bug: - what parameters did you give to "configure" - did you compile with gcc, Sun's cc, or some other compiler? - in 32-bits or 64-bits mode? - did you try all of the available fonts, and do they have the same problem? - does this happen with the dynamic text tool? You can reply to me directly or to the list. I will try to help if I can. But note that I will only read my e-mail every second day during this week and the next one. -Raphael
Re: EPIPE
On Thu, 11 May 2000, Michael Natterer [EMAIL PROTECTED] wrote:
Raphael Quinet wrote:
[...]
- SIGCHLD or SIGCLD: a child process died. This signal can be
delivered at any time. Some systems do not provide a reliable way
to know how many processes exited (if they do not support SA_NODEFER
or if their waitpid() or wait3() calls are broken), so it is usually
better to simply set a flag in the signal handler (without calling
any wait*() function) and to check the status of the children outside
the signal handler, until some wait*() function reports that there
are no more dead processes. For example:
while ((pid = waitpid (-1, status, WNOHANG)) 0)
{ ... /* check WIFEXITED(status) and other things */ }
This is what currently happens (ok, it happens in the handler, but WNOHANG
*should* be absolutely safe).
No, actually it is not safe on all operating systems: as I wrote
elsewhere, you cannot always rely on SA_NODEFER. This means that in
some cases, you could miss a SIGCHLD signal that occurs while you are
still inside the handler but after the last test on waitpid(). If
this happens, the main app will not see that one of the plug-ins has
died (until another one dies and the handler collects the status for
both). That's why it is safer to make the tests outside the signal
handler. Otherwise, you could have a race condition on some systems
(very seldom, but still...).
[...]
The usage of SIGCLD is strongly discouraged by Stevens and some Solaris
document I fould recently. But Gimp uses SIGCHLD anyway.
And here is an excerpt from /usr/include/sys/signal.h on Solaris 2.6:
#define SIGCLD 18 /* child status change */
#define SIGCHLD 18 /* child status change alias (POSIX) */
So it does not make much of a difference under recent versions of
Solaris, at least... :-) But they still say in some docs that the
behavior of SIGCLD might change in future releases, so the POSIX
version should be used in new programs.
In one application that wanted to catch SIGSEGV, SIGBUS, SIGILL and
SIGFPE, I created a handler that uses a direct call to write() on an
fd that was previously obtained from fileno(stderr) (this fd is saved
early so that the write() call can work even if the FILE *stderr is
overwritten with garbage). Doing this is safe, AFAIK.
Yep, write() is safe. Gimp uses g_print() which is not really safe, but
then we call g_on_error_query() which definitely does a bit more than
what's allowed :)
Yes... I wrote a few months ago that I would change that and implement
some kind of --enable-stack-trace option, but I never took the time to
do it.
From glib/gerror.c:
/*
* MT safe ; except for g_on_error_stack_trace, but who wants thread safety
* then
*/
Note that being MT safe is not enough. For the 4 signals that are
listed above, you can usually expect that your memory is already
corrupted. So if you want to minimize the risks of crashing
recursively inside the signal handler, you should avoid using
variables as much as possible. A handler for SIGSEGV is a good place
for paranoia...
The other signal handlers do not need so much defensive programming.
Being MT safe is usually enough.
killall -SIGGIMP ps
:-)
-Raphael
Re: EPIPE
On Thu, 11 May 2000, Marc Lehmann [EMAIL PROTECTED] wrote: [...] What could be the case, however, is, that gimp itself does not reset it's signal handlers when it execs the plug-ins. If this is the case, then this bug (not restoring signal handlers to their default) might cause many other subtle problems. The libgimp code could try to set the signal handler to SIG_DFL before executing the code of the plug-in. Another solution is to save and re-install the old signal handler. We may even want to support some kind of chain of signal handers: the new signal handlers installed by the Gimp should call the ones that were installed before. But then we have to support the systems that have SA_SIGINFO and those that do not have it (this is not part of POSIX). The systems that have SA_SIGINFO are using extended prototypes for the signal handlers, so some #ifdef's will be necessary if we want to do that in the right way. I could contribute some code if you want, because I already did that in some other projects. [...] I thought the last time this was discussed we agreed that, in the release, the signal handling code that causes frustration and endless loops will be disabled by default? Most of these signals have very sane default actions (like SIGPIPE). Hmmm... In the last discussion, I said that I would implement a compile-time and a run-time option for choosing this, because some people (including myself) do like the option to have a stack trace (when it works). But I did not take the time to do it. If you kick me enough, I will do it... :-) -Raphael
Re: EPIPE
On Thu, 11 May 2000, Michael Natterer [EMAIL PROTECTED] wrote: Raphael Quinet wrote: No, actually it is not safe on all operating systems: as I wrote elsewhere, you cannot always rely on SA_NODEFER. This means that in some cases, you could miss a SIGCHLD signal that occurs while you are still inside the handler but after the last test on waitpid(). If this happens, the main app will not see that one of the plug-ins has died (until another one dies and the handler collects the status for both). That's why it is safer to make the tests outside the signal handler. Otherwise, you could have a race condition on some systems (very seldom, but still...). We don't use SA_NODEFER any more. And AFAIK the delivery of SIGCHLD has nothing to do with cleaning up zombies. This is why we loop around waitpid() because POSIX explicitly says that signals arriving close together may be merged by the kernel. The delivery of SIGCHLD does not clean up the zombies: this is done by calling waitpid() or any wait*() function. But the call to waitpid() will be triggered by a SIGCHLD, and there is a potential race condition. I will try to explain this in a slightly different way: regardless of the setting of SA_NODEFER, you cannot ensure that you will get one SIGCHLD for every dead process. Some kernels merge the signals that arrive close together, and some of them mask the signal while the corresponding handler is being called (some systems will re-deliver the masked signal immediately after the handler returns, but this is not always the case). Now, consider the following scenario for a race condition: * The Gimp starts two plug-ins * plug-in 1 dies * SIGCHLD delivered, handler called * inside the signal handler: * - waitpid() returns the status of the first process * - waitpid() returns 0 and the while() loop ends * plug-in 2 dies (before the signal handler returns) * SIGCHLD cannot be delivered * - the signal handler returns * The Gimp continues and the status of second plug-in is never collected, so this creates a zombie. Although it is rather unlikely that a context switch happens in the signal handler just after the while() loop and before returning, it can and will happen. If you are sure that all kernels of the systems that Gimp supports will re-deliver the second SIGCHLD signal immediately after the signal handler returns, then there is no problem in the scenario described above: the handler will be called a second time and will collect the status of the second plug-in. But I do not think so; that's why I suggested to call waitpid() outside the signal handler, because then you avoid the race condition. Yes... I wrote a few months ago that I would change that and implement some kind of --enable-stack-trace option, but I never took the time to do it. Now it's there :) We just have to convert the remaining g_print() to write() and the handler will be totally safe if enable_stack_trace == FALSE. Hmmm... I don't know how you have implemented it (I cannot look at the CVS code), but I was thinking of having more options for --enable-stack-trace, both for the configure option and for the command-line option: - "never": disable the stack trace and use the default signal handlers - "query": ask the user, as we are doing now. - "always": always call the debugger without asking any question (useful if stdin does not work, but stdout is still OK) - "wait": always wait 30 seconds, without asking any question (this does not use stdin or stdout and gives some time to the user if she wants to attach a debugger to the process) If the code is compiled or run with the "never" option, then the signal handlers would never be installed. The configure option would set the default value for this flag, but it would always be possible to override it with the command-line option without recompiling. The default for the code in CVS and for the unstable tarballs should be "query", and the default for the stable releases could be "never" or "wait". We should probably re-add the reentrancy guards in the fatal handlers and just do a brute force exit() if it's called recursively (which can only happen during the stack trace because that's the only case where the signals are unblocked in the handler). Another option would be to set the signals to SIG_DFL as soon as the fatal handler is called. Since the default behavior for these signals is to kill the program, this would prevent the endless loop without requiring a special flag. On Fri, 12 May 2000, Michael Natterer [EMAIL PROTECTED] wrote: [...] So ignoring SIGPIPE in the app causes it to be ignored in children, too. To avoid the need of resetting the signal we could just connect it to a dummy handler and let exec() do it's job of resetting it. Well, as I wrote above and in a previous mail, there is a conve
New version of gimp_tips.txt
I uploaded the gimp_tips patch to ftp.gimp.org a few days ago, but apparently it has not been moved out of the incoming directory yet, and not comitted to CVS. Maybe some of you would like to have a look at the updated file, so I have put it temporarily on this page: http://www.gamers.org/~quinet/gimp/gimp_tips.txt This is only a temporary location and I will delete it a few days after the next release. But in the meantime, you can have a look at it and maybe send more suggestions... -Raphael
Is Add alpha channel really necessary?
I just saw an article in comp.graphics.apps.gimp (in the thread with the subject "White balance tool?") that starts describing a method with these words: "use the color picker on the 'white' color, duplicate the background layer, delete the original, add a layer..." I had to read that twice to understand what he was trying to to. Why does he duplicate the background layer and then delete the original immediately afterwards? Well, the reason is simple: this is the easiest and fastest way to add an alpha channel to the background layer. If you haven't assigned a shortcut key to "Layers - Add Alpha Channel", then it is faster to click on the buttons to duplicate the layer, re-select it, and click on the trash can. So although the "right" way to add an alpha channel to the background layer is to use "Layers - Add Alpha Channel", it looks like many users prefer to rely on a side-effect of some other features that are easier to use and understand. Even if this is ridiculous from a developer's point of view (think about the waste of CPU cycles and memory to duplicate and then delete the tiles), it makes sense for the users. And this probably shows that there is a problem with this concept (as Marc mentioned in a recent message). Why do we need "Add alpha channel" anyway? I understand that if you are working only with single-layer RGB images (not RGBA), it is better to have only the R,G,B components in order to save memory and processing time. But as soon as there is more than one layer in the image, is there any reason to keep the background layer as RGB instead of promoting it automatically to RGBA? Why do we need to have a Tip of the Day that tells the user to add an alpha channel, instead of doing this automatically? It should be easy add an alpha channel to the background layer as soon as a second layer is added to the image. Is there a reason why this should not be done automatically? I think that it would make things easier to understand for the user. Making the background layer "special" is not very intuitive. For example: create a new image, draw something in the background layer. Then add a new layer and draw something there. Now make a selection and use Edit-Clear. If you do that in the new layer, this makes the selected area transparent. If you do that in the background layer, it fills that area with the background color... until you select "Add Alpha Channel", of course. But you have to read the tips in order to know that. It would be better to make all layers behave in the same way. Promoting the background layer automatically would ensure that an RGBA image has only RGBA layers, while an RGB image has only one RGB layer (this could also make some code simpler, by removing some tests on the layers' type). What do you think? I would even go as far as removing the "Add Alpha Channel" option from the menus, and suggest that the prefered method to add transparency to an image that has only one layer is to add a new layer, even if it is deleted immediately. This is not worse than the method used now by some users (duplicate and delete the original) and I think that it would be more intuitive to some users. -Raphael
Re: Is Add alpha channel really necessary?
On Tue, 16 May 2000, Jens Lautenbacher [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Raphael Quinet) writes: I would even go as far as removing the "Add Alpha Channel" option from the menus, and suggest that the prefered method to add transparency to an image that has only one layer is to add a new layer, even if it is deleted immediately. This is not worse than the method used now by some users (duplicate and delete the original) and I think that it would be more intuitive to some users. I would say, simply make a layer by default have alpha always... I know I know it's more memory for that 0.001 % of cases where people start with one background layer and stick to one the whole time, without using alpha Hmmm... No, I think that it makes sense to create single-layer images without alpha. If you are working mostly with image formats that do not support alpha (i.e. JPEG, BMP, PPM, PCX) or if you are not interested in having transparency anyway, then you probably want the Gimp to behave as most of the old painting programs behaved: no layers, no transparency, and "clearing" an area means to fill it with the background color. It also saves some memory if you are using the Gimp to do some color corrections or simple retouching on huge images (e.g. your photo collection or some scanned images). But on the other hand, as soon as you start working with multiple layers, then you need to work with transparency (and to understand the concepts involved). That's why I would promote the background layer to RGBA when you add a second layer. I still haven't found a good reason to keep the background layer "special" when the image contains multiple layers. If the only reasons are historical or to copy the features of some well-known commercial program, then we could have this as an option in the gimprc (but IMHO the default should be to promote the background layer automatically). -Raphael
Re: Is Add alpha channel really necessary?
On Tue, 16 May 2000, Jens Lautenbacher [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Raphael Quinet) writes: I still haven't found a good reason to keep the background layer "special" when the image contains multiple layers. If the only reasons are historical or to copy the features of some well-known commercial program, then we could have this as an option in the gimprc (but IMHO the default should be to promote the background layer automatically). One reason is the same as you gave for the single layer case: clearing means filling with a choosen background layer. So having a stack of layers with a dedicated background layer in a dedicated color makes sense, as clearing on the upper layers will clear to alpha, while it will clear to the background color on the background layer No, this is precisely what I consider to be counter-intuitive. IMHO, "clear with bg color" only makes sense if you do not understand or are not interested in the concepts of layers and transparency. So this can be good if you are mostly working with "flat" image formats. But if you start working with layers and transparency, then I would prefer to have a consistent behaviour for "clear": it should always make the selected area transparent, in all layers. If you really want "Edit-Clear" to reveal some color when you use it in the background layer of a multi-layered image, you always have the opportunity to add another layer below the one that was your background. This is probably easier to understand than having some special properties on one layer. (Anyway, in that case I would prefer to simply use "Edit-Fill with BG" or to drag the background color into the selection.) On Tue, 16 May 2000, Alan [EMAIL PROTECTED] wrote: May I make a humble suggestion. Change File-New to allow users to select a Fill Type of either Background w/o alpha Background w/ alpha Then users can select what they want to begin with. Flatten and Add Alpha Channel can still exist as is in the Layers menu. No automatic behind-the-scenes switching need be done. Power users have full control and newbies can simply select Background w/ alpha if they wish. This would not solve the most common problem which is: load an existing JPEG image, add a layer to it, then be confused because you cannot lower this layer below the background layer or because "Edit-Clear" and the Eraser tool behave differently on the two layers. Note that I definitely do not want to remove the "Flatten Image" option because it is very useful: as Carey Bunks said in a previous message, the user must be able to choose when and how an image is flattened before saving it. -Raphael
Tiny patch for the psp plug-in.
While following Adrian's nice tutorial on Gimp Image Pipes, I tried to load some PSP Tubes and see if I could convert them to Gimp's GIH format, using gimp-1.1.21 under Solaris (sparc). All of them failed with the error "PSP: Unrecognized block id ...". This comes from a missing conversion from little endian format to big endian. All integer values from the header are correctly converted, except for the block id. The patch is small, so instead of reporting a bug to bugs.gnome.org and/or submitting the patch to ftp.gimp.org, I am including it below. This is against gimp-1.1.21 (the one I have at work for the moment, until I find the time to install 1.1.22). I quickly checked the Changelog using Bonsai and I did not see any recent changes to that plug-in, so I assume that the patch is still valid for 1.1.22. -Raphael --- plug-ins/common/psp.c~ Mon May 1 19:43:17 2000 +++ plug-ins/common/psp.c Thu May 18 17:12:55 2000 @@ -536,7 +536,7 @@ *total_len = GUINT32_FROM_LE (len); } - return id; + return GUINT16_FROM_LE (id); } static gint
Request for new, high-quality, brushes (and maybe patterns too)
Except for the vines and green pepper, the latest version of the Gimp ships with basically the same set of brushes as version 1.0. Even the gimp-data-extra package does not contain anything that demonstrates the power of the pixmap brushes or pipes. It would be good to add two or three high-quality brushes to the default brushes shipped with version 1.2. There should be no more than two or three new brushes (no bloatware), if possible showing different features of the pixmap brushes/pipes: orientation, sequence, and so on. Of course we can add even more brushes and patterns in the corresponding gimp-data-extras package, but the default distribution should be reasonably small. There are many pages containing nice PSP tubes, for example: http://bart.northnet.com.au/~robrow/tubes/downloads.htm http://www.cablevision.qc.ca/renlev/tubes.html But we cannot convert them to Gimp brushes without violating some copyrights or some of the limitations that they put on redistribution. So we should try to create our own copyright-free brushes. By the way, I think that the current gimp-data-extras contain too many "abstract" brushes and patterns. It would be nice to have some good images of stones, leaves, wood, flowers, grass, sky, fur,... that are scanned directly from Mother Nature. I have just started doing that myself, but I would be good if several of us could do it so that we could have a nice collection. Some of the PSP tubes are good examples of the kind of high-quality stuff that we should distribute with gimp-1.2 (some are bad examples too; just ignore them). I am not sure about how to coordinate this effort and how to select the best brushes and patterns (we need only the best stuff in the distribution). Any suggestions? If nobody volunteers, maybe I could collect the submissions (by e-mail?), put them on some web page and then wait for comments, but I would only do that as a last resort because being behind a firewall prevents me from setting up some automated process. That's why I am asking here for ideas and volunteers instead of posting a request directly on the gimp-users list or in comp.graphics.apps.gimp. I would be nice to do that before 1.2 is released. -Raphael
Re: installation in non-standard location / configure bug
On Mon, 29 May 2000, Marc Lehmann [EMAIL PROTECTED] wrote: On Sun, May 28, 2000 at 06:46:43PM -0400, Warren Hedley [EMAIL PROTECTED] wrote: Also, configure ignores the perl executable argument specified in the --enable-perl option (see configure line above, for example), The --enable-perl option specifies the perl prefix to install the pelr modules, not the perl executable path. Specifying a file will be disastrous. I think that the option should be named "--enable-perl-prefix" instead of the shorter "--enable-perl", in order to avoid confusion. This would be more consistent with the other options, and longer names are not a problem because they are not used very often anyway. The help string should then be changed to "--enable-perl-prefix=PFX". If someone wants an option to specify the path to the perl executable, then it should be "--with-perl=...". Maybe adding the "--with-perl" option would make people think twice before making incorrect assumptions? -Raphael
Feature idea: rotate brush while following a path
Well, it looks like I will not be able to attend the GIMP Developers Conference at the end of this week (too bad - I really wanted to be there), so here is an idea that could be discussed: there could be an option to rotate a brush automatically according to the local tangent of the path that the brush is following. To make it even nicer, the user should be able to specify what is "local": how many pixels should be taken into account for calculating the angle. This would be very useful with pixmap brushes/hoses/whatever you call them: if your brush is an arrow and you select Edit-Stroke on a circle, then the arrows would follow the circle without having to specify multiple cells with different angles in the brush itself (of course it should still be possible to use the existing "orientation" parameter in the brushes that have it). Another example would be an animated brush containing several frames of a person walking, and you want to draw this along a curved path. I actually tried to create a brush like that, including 15 frames in 8 possible orientations, but 8 is not precise enough and the 120 cells already take more than 1 Mb. Being able to rotate the brush dynamically would be a way to trade CPU cycles for memory (besides the fact that it would provide more precise rotations than 45 degrees steps). Another crazy thing that I tried to do (when I saw some people asking if there was a way to draw text along a path) was to create a script that would let you enter a text string, then dynamically generate a brush that would contain all the letters as individual cells. Then you could draw freely with this brush and see the letters appearing along the path. Unfortunately, it does not really work because all letters are facing straight up (unless I include several versions of the letters in the brush, but that takes way too much memory). Being able to rotate the brush dynamically would solve the problem. This would be an ugly hack for putting text on a path, but that could help some users until the text tool is re-written. -Raphael P.S.: If I have the time, I will also write down some of my ideas about how "active layers" could work. The user would be able to associate some PDB calls with a layer so that it would be possible to have a "shadow effect" layer that is updated when the "object" layer is modified. Or a "blur" layer that blurs the layers below.
Re: The undo stack does not record some changes in layer attributes
On Wed, 07 Jun 2000, Sven Neumann [EMAIL PROTECTED] wrote: [quoting Austin Donnelly [EMAIL PROTECTED]] I would be very unhappy if changing the layer opacity from 100% to 50% would eat up a dozen or more undo-steps since each value_changed signal from the slider triggers an undo which causes another undo-step fall off the end of the undo queue. Oh, sure - that's clearly a bad idea. I was thinking of only pushing the undo when you release the slider. That doesn't help those using the keyboard to nudge the slider though. [...] This would not really solve the problem anyway, even if you are using the mouse. Often I play with layer modes and opacity in order to get the effect that I am looking for. So I click on the slider, then select something in the modes menu, then move the slider again, and so on... It would not be a good idea to save all these individual changes on the undo stack, because there are too many of them and I am not interested in saving the current state of the image until I start some painting operations. I still believe that it is a bad idea to waste undo steps for operations that don't save any shadow tiles. How hard would it be to change the undo system so that the number of undo steps is calculated only from "real" undos? What about the idea of merging consecutive changes to the layer attributes into one? Here is my proposal: save and restore all layer attributes (opacity, mode, keep trans, visibility) together with any operation that is currently put on the undo stack. This means that if you do anything that starts an undo step (e.g. painting in the image), the current attributes of all layers are saved on the undo stack. After finishing your painting operation, you can modify the visibility or mode of any layer and nothing will be saved on the undo stack... until you start another undoable operation and then the current layer attributes are saved again at the same time as the new undo step is created. Later, if you undo the last operation, then the image is restored and simultaneously all layer attributes are reset to the values that they had before. I think that such a behaviour would be acceptable to the users. It would also fix the bug that I described earlier and that is affecting the undo-aware scripts, because undoing the changes to the image would also restore the layer attributes to a sane state (as they were before the script was called). The annoying problem with the current code is that if you perform several operations on an image, then change the attributes of some layer, then undo some of all of these operations, you get an inconsistent result: the tiles of the image are as they were before you applied all these operations, but the layer attributes are still in the same state as after the last operation. This is not easy to explain to the users... -Raphael
Compilation and installation instructions
We all know that the usual "configure; make; make install" procedure
does not work exactly as advertised for versions 1.1.x, especially if
the user installing the package is not the same as the one building
it. Some of these problems have been mentioned by Michael J. Hammel
two weeks ago ("install issue over NFS").
If you follow the instructions given in the INSTALL file, here is how
you are supposed to build and install the Gimp:
As the "build" user:
% ./configure (using --prefix and other options as necessary)
% make
As the "install" user:
% make install
But this does not work (the installation fails), for the following
reasons:
- Due to some strange hacks in libgimp/Makefile, the libgimp library
requires that you use "make" twice in order to have its dependencies
satisfied (the "evil hack" mentioned in that file does not seem to
work for me, although I am using GNU make). So the build fails if
you try "make install" and the "install" user has no write access to
the build directories. To solve this problem, you have to type
"make" twice before attempting to install.
- The Perl plug-in rebuilds the gimp-perl.pot~ file every time (not
only once as in the previous case) because of a dependency on a
"force" target in plug-ins/perl/po/Makefile. So you get the same
problem as above during "make install". But typing "make" twice is
not enough to solve the problem, so you must edit the Makefile and
remove the dependency if you want "make install" to succeed.
- The Perl plug-in incorrectly uses the installed header files instead
of using the ones coming with the package. This means that although
everything can be compiled and installed, the Perl scripts will fail
(lots of unresolved symbols) if anything has changed in libgimp.
The only solution is to build and install everything once, then
rebuild and re-install the Perl plug-in with the newly installed
headers.
I don't know the exact reasons why these hacks were put in the various
Makefiles and I did not understand the explanations that were posted
until now, so it would be hard for me to fix these bugs. If this is
not going to be fixed before 1.2, we should at least insert some
comments in the INSTALL file so that people who are trying to install
the Gimp using non-priviledged accounts have a chance to succeed.
Here are the steps that should be followed in order to install a
working version of gimp-1.1.x:
As the "build" user:
% ./configure (using --prefix and other options as necessary)
% make
% make (this rebuilds libgimp and re-links the gimp app)
As the "install" user:
% make install
As the "build" user:
% cd plug-ins/perl
% make clean
(edit po/Makefile and remove the "force" dependency for gimp-perl.pot)
% make (this builds the plug-in using the installed headers)
As the "install" user:
% make install
This is more complex than what the INSTALL file says, but this works
for me (using Solaris 2.6, compiling over NFS) and I think that this
is the simplest way to get a working Gimp under these conditions.
Another option is to configure with "--disable-perl" and then the only
unusual thing that you have to do is to type "make" twice instead of
once before starting "make install".
I don't know if I should try to fix the Makefiles or just mention
these kludges in the documentation (in the INSTALL file), but
something should be done before 1.2 is released. Of course, fixing
the Makefiles would be the best solution but this is probably not so
easy, especially if I do not understand the reason why these hacks
were inserted in the build system. Could anybody enlighten me?
-Raphael
Re: Compilation and installation instructions
Minor correction to my previous post: the library that is recompiled twice is libgimpi.a (note the "i"), not libgimp.a. The file libgimpi.a is created in the directory (top)/libgimp/, not in (top)/libgimp/.libs/ as the other libraries under libtool's control. -Raphael
Re: Compilation and installation instructions
On Sat, 9 Sep 2000, Marc Lehmann [EMAIL PROTECTED] wrote:
On Thu, Sep 07, 2000 at 06:13:07PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote:
the user installing the package is not the same as the one building
it. Some of these problems have been mentioned by Michael J. Hammel
two weeks ago ("install issue over NFS").
AFAICR this was stricly perl-related. Since Sven hacked the
perl-po-process into using the "standard" mechanism now it *should*
work. Could anybody re-run the test to verify that this indeed works now?
I cannot get the latest CVS version (firewall problems) but I will
test again as soon as 1.1.26 is out. Anyway, the problems with
libgimpi.a are not specific to Perl and the CVS Changelog from Bonsai
does not mention any recent changes to the corresponding files, so I
assume that this part is still broken.
- Due to some strange hacks in libgimp/Makefile, the libgimp library
requires that you use "make" twice in order to have its dependencies
satisfied (the "evil hack" mentioned in that file does not seem to
work for me, although I am using GNU make).
Does this only happen on parallel builds or on normals builds as
well? I only gte problems when doing parallel builds (there is a
still-open-bug-report about the latter problem).
I suppose that you are refering to this bug that you reported in May:
http://bugs.gnome.org/db/11/11900.html
My problem happens on normal builds: "make" with no arguments. This
is GNU make 3.78.1 running on Solaris 2.6. I have seen the same
problem happening under several versions of Linux (also running GNU
make) and other version of Solaris, so I think that the bug affects
almost everybody. Actually, I would like to know if there is anybody
who does *not* have this problem.
Here is how to test it:
- Get a clean source tree (extract the released .tar.gz file in an
empty directory or do a "make distclean" if you are using CVS).
- Run "./configure" with your favourite options. But do not use the
option "--disable-static" because the bug is probably related to
the static libraries.
- Type "make" once.
- Type "make" a second time. If *anything* is rebuilt (specifically,
libgimp/libgimpi.a and app/gimp), then you are affected by the bug.
- The Perl plug-in incorrectly uses the installed header files instead
of using the ones coming with the package. This means that although
This comes up again and again, however, this bug has been fixed many many
many months ago.
I am sure that the bug was still there in 1.1.24 (released at the end
of June), because all Perl scripts crashed with a dynamic linking
error (missing symbol) due to the changes in libgimp. I don't know if
it is still in 1.1.25 because the Gimp header files didn't change much
since the previous version so I didn't see any errors when I installed
the new version over the old one. Do you know if the bug was fixed
between 1.1.24 and 1.1.25?
the Makefiles would be the best solution but this is probably not so
easy, especially if I do not understand the reason why these hacks
were inserted in the build system. Could anybody enlighten me?
AFAIK, at least the libgimp hacks come from the fact that libtool has had
(and still has) various bugs and design problems, and also has problems on
various platforms.
As I said in my previous message, I am willing to help fixing these
bugs, but I currently do not understand what problems the libgimpi.a
hacks are trying to solve. Is there any reason for that or is it just
because it worked once and nobody dared touching it later?
The (former) perl-po problems come from the fact that libintl doesn't
support perl, nor can it be configured without serious hacking to support
perl. What was recently done was to screw standalone po-support for perl
and make it a "only when built inside the gimp tree"-feature, so that, at
least for gimp-1.2, there are chances of working properly, at the cost of
not being able to upgrade until I reinvented the old mechanism again.
Well, it's a pity to break one of the two options, but I think that it
is better to get the compilation inside the Gimp tree working properly
even if it means that the upgrade would be a bit more difficult.
-Raphael
Re: Gimp 1.1.25 not working with gtk+-1.2.8 on SPARC
On Sun, 24 Sep 2000, "Dr. David Kirkby" [EMAIL PROTECTED] wrote: I've built, gimp-1.1.25 on my Sun SPARCstation 20, using the following pieces of software and hardware. [...] Gimp then builds okay, but crashes on startup. Debugging under gdb-4.18, shows it seems to be looking for a source file gtkbindings.c which I see is included in the source for gtk-1.2.6. My installation has a binary distribution of gtk-1.2.8. I compiled gimp 1.1.25 under Solaris 2.6 on a Ultra1 without any problems (except for the Perl Makefile, but you solved that already). It works fine for me, and I get no crashes or errors on startup. Note that I downloaded and compiled glib-1.2.8 and gtk-1.2.8 from the sources. I have never used the pre-compiled versions from the Sunfreeware site, so maybe you should consider compiling them yourself and see if it makes a difference. If you are interested, here are my installation instructions for Solaris 2.6. I install everything under /Local. Feel free to choose another prefix that suits your environment. Also, the "make dvi" steps are optional and require that you have teTeX or another TeX package. The lines that start with [su] mean that you should execute these commands as root or as the user that owns the installation directories (important if you are doing that over NFS). * glib-1.2.8 (sources: ftp://ftp.gtk.org/pub/gtk/) ./configure --prefix=/Local --with-threads=solaris make make check [su] make install make dvi [su] cp docs/*.dvi /Local/doc-dvi/ * gtk+-1.2.8 (sources: ftp://ftp.gtk.org/pub/gtk/) ./configure --prefix=/Local make [su] make install make dvi [su] cp docs/*.dvi /Local/doc-dvi/ * PDL-2.003 (sources: http://www.cpan.org/authors/id/KGB/) perl Makefile.PL make test [su] make install (note: many of the tests failed under Solaris, but it seems to work anyway) * Parse-RecDescent-1.70 (sources: http://www.cpan.org/authors/id/DCONWAY/) perl Makefile.PL make test [su] make install * Gtk-Perl-0.6123 (sources: http://www.cpan.org/authors/id/KJALB/) perl Makefile.PL make test [su] make install * gimp-1.1.25 (sources: ftp://ftp.gimp.org/pub/gimp/) ./configure --prefix=/Local make make [su] make install cd docs make dvi [su] cp *.dvi /Local/doc-dvi/ cd .. (note: it is necessary to type "make" twice before "make install" because libgimpi.a is only built correctly on the second pass - see bug #24077) Hope this helps... -Raphael
Bug with most File-Save plug-ins
OK... Since the bug tracker seems to have lost the bug report that I wrote last week and I don't want to re-type it until I am sure that it will not be lost again, I will post a description of the problem here... Almost all File-Save plug-ins that are designed for single-layer file formats (i.e. almost everything but .XCF) will save the current layer (drawable) and ignore any other information from the image. In some cases, you could loose some of your work because of that. The following things are ignored when the current layer is saved: 1) canvas size 2) layer offset 3) layer mask (or layer itself, if a mask or a channel is selected!) 4) layer opacity This bug exists in all versions of the Gimp, from 0.99.x to 1.1.27. The first part of the problem (canvas size) was reported in #23610 (http://bugs.gnome.org/db/23/23610.html) but this bug is assigned to "gimp-1.0", that's why I wanted to submit a more detailled report for the current Gimp. Most of the time, the bug (or design problem) will not be visible because the "Export" feature will hide it: if the source image contains several layers, flattening it will make the resulting drawable equal to the visible image. The "Export" feature will also be triggered for a single-layer image with alpha if the output format does not support transparency. But in all other cases (e.g saving as GIF, TIFF or PNG, or saving an image without alpha as JPEG), then some information will be lost. Problems: 1) Ignoring the canvas size means that the saved file may contain some areas that should not be part of the visible image. This is the problem reported in bug #23610 for gimp-1.0.4. 2) Ignoring the layer offset has the same effects as ignoring the canvas size: some parts of the layer may be outside of the canvas and should not be saved. Try this: load a file, then change the canvas size or move the layer with the move tool. Save as GIF or JPEG and load the resulting file. You will still see the original layer. If you save as PNG and re-load, the layer offset will be saved but the layer will not be clipped to the canvas size (the result is confusing). 3) Ignoring the layer mask (or ignoring the layer data if the mask or a selection channel is selected) is the most dangerous part of this bug: you could loose some data if you do not see what went wrong and you do not have a copy of your source image in .XCF format. Try this: create or open an image, then add a layer mask and draw something in it. Then save the image using a format that supports transparency (so that "Export" is not triggered) such as PNG, GIF or TIFF. Depending on what was selected when you saved, the file will only contain the layer data without the mask, or only the mask (or selection channel) but not the image. Oops! You have lost half of your work... 4) Ignoring the layer opacity is a lesser problem. But if you open a PNG image with transparency and move the opacity slider in order to make it more transparent, you could expect that the result would be correctly saved in a new PNG file, but it is not. The result will be identical to the original image because the layer opacity was ignored. Playing with transparency could become more frequent when more web browsers support PNG with alpha (correctly). All these effects are related to the same design problem: most of the File-Save plug-ins see only the current drawable and ignore the other parameters of the image. This is even worse when you correlate this with bug #25272 (http://bugs.gnome.org/db/25/25272.html): the .xvpics thumbnails are generated from the visible image, not from what gets saved in the file. So you may save your image and think that everything went well when you see the thumbnails, but the contents of the file are actually different. What is the best way to fix these problems? I don't know. Some changes could be done in the main app, and some others in the plug-ins. For example, the PNG plug-in is the only one (AFAIK) that saves the layer offset because the file format supports this feature (but it should also consider the canvas size). The other plug-ins could clip the layer to the canvas, but then the "Export" feature should also be triggered for non-transparent file formats if some areas are transparent because they are within the canvas but outside the layer boundaries. The most dangerous error is described in (3) and also as an example in bug #25272: you could loose some of your work if a layer mask or a channel mask is saved when you thought that the current layer would be saved. I don't know how to prevent that... Maybe there could be a warning if you attempt to save anything that is not the current layer (but then we should also add an option in the gimprc to disable the warning, and we are in feature freeze...). At least, it would be nice to have a warning if a channel mask is going to be saved (i.e. a channel is
Re: bug in patch-1.1.27-1.1.28
On Thu, 19 Oct 2000, "Uwe Koloska" [EMAIL PROTECTED] wrote: to save some download time ;-) I tried to upgrade from 1.1.27 to 1.1.28 with the patch file. I found some minor problems; some files are incorporated in their final form and not in the ini-form: [...] Another minor thing: the new splash screen is not included in the patch. Maybe it is better to leave it out of the patch anyway, because the splash screens tend to grow bigger and bigger with every release... -Raphael
Re: bug in patch-1.1.27-1.1.28
On Fri, 20 Oct 2000, Tuomas Kuosmanen [EMAIL PROTECTED] wrote: On Fri, Oct 20, 2000 at 09:28:52AM +0200, thus said Raphael Quinet: Another minor thing: the new splash screen is not included in the patch. Maybe it is better to leave it out of the patch anyway, because the splash screens tend to grow bigger and bigger with every release... Hmm.. my digicam does 2048x1536.. wait until I do a nice photo splash! Why are the latest ones so huge anyway? The resolution on the photos they contain is pretty low and crappy anyway, would look better if it was scaled to half I guess.. And use the gimp-freetype plugin if you want to have small sized readable text :) OK... I will create a new splash screen during the week-end. It is easier to create an image than to work on the open bugs, and I am feeling lazy for the moment, so... :-) Also, I had started working on a new splash screen two months ago and maybe I could finish it this time. It has the same size as some of the earlier ones, and it features Wilber and... err... let's call her Wilma. Did we have a vote on her name when I created the Valentine's day splash screen? I'm glad to see that the ratio of gimp-related mails versus spam has increased today! -Raphael
Re: GIMP help docs
On Mon, 6 Nov 2000, [EMAIL PROTECTED] wrote: On 6 Nov, Sven Neumann wrote: If you want me to change the helpbrowser, I need a detailed list of the changes that are necessary. just the changes we talked about: Removal of the HTML navigation bar and using the supplied links in this bars for the buttons in the helpbrowser. Hmmm... Looks like we need a couple more beta releases before 1.2. ;-) But I am wondering... What's the point in maintaining a Gimp-specific help browser? I routinely compile the Gimp on several machines (shared or private, running Solaris or Linux, and located in different countries ;-)) and the most common configurations are: * Basic system or KDE system that has Glib, GTK+ and some other libraries but no GtkXMHTML library. On these systems, the help browser is not built so everybody uses Netscape for the help pages. * Gnome system (using HelixGnome or the version of Gnome supplied with the Linux distro) that has many packages installed, including GtkXMHTML but also the Gnome help browser. I have never seen a system that had GtkXMHTML installed and did not also have the Gnome help browser. Wouldn't it be easier to use it if it is availble, and to stop maintaining the Gimp-specific help browser? There could be a compile-time option (or install option) that installs the appropriate version of the help files depending on the help browser used (regular HTML browser like Netscape, or Gnome help browser). -Raphael
Re: signal handler problems in screenshot plug-in
On Tue, 07 Nov 2000, Sven Neumann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Raphael Quinet) writes: I think that the best way to fix the screenshot plug-in is to add this before the call to fork(): gimp_signal_private (SIGCHLD, SIG_DFL, SA_RESTART); (don't forget to #include libgimp/gimpsignal.h) This seems to work fine (at least under Linux). I'm only wondering why the gz, bzip2 and mail plugins do work under Solaris then. Or is this not the case ? Alas, these plug-ins have been broken under Solaris since a couple of months. I thought this was reported in the bug database, but apparently it isn't. That should have been a "grave" bug, at least. And the fix is exactly the same as for the screenshot plug-in: - make the code safer by checking the return value of waitpid, as described in my followup to #27786, - include libgimp/gimpsignal.h, - call gimp_signal_private (SIGCHLD, SIG_DFL, SA_RESTART) before calling fork(). A quick grep shows the list of plug-ins that call waitpid() in an unsafe way (do not check the result) and are affected by the race condition between the system call and the signal handler: - plug-ins/common/bz2.c (twice, for loading and saving) - plug-ins/common/gz.c (twice, for loading and saving) - plug-ins/common/mail.c - plug-ins/common/screenshot.c - plug-ins/common/url.c (twice, with ifdef/ifndef __EMX__) The print plug-in also calls waitpid, but it uses it only for its blocking effect and not for collecting the status of the child, so this plug-in is safe. It looks like all plug-ins authors copied and pasted the same code, because the same structure and the same argument names are used in all plug-ins. But this code was wrong: it was unsafe since the begining in 1.0.x, and broken when the new signal handlers were installed. It's a pity that the problem was not detected and fixed earlier (I am partly to blame for that, because I knew the problem and I did not check if it was reported in the bug database - I just told my users to avoid compressing files until the bugs were found and fixed). Anyway, I just fixed these five plug-ins and the patch should be in the incoming directory of ftp.gimp.org in a few minutes. Regarding bug #27786, I don't know if it is still open or not. I do not see any crashes under Solaris 2.6, but maybe Solaris 8 is still affected by the bug that was originally reported by Austin Donnelly. Could someone test this, as I don't have access to a Solaris 8 machine right now? -Raphael
test program for waitpid/sigchld problems
Included below is a small test program that checks how the OS behaves
when a child process exits while the parent is blocking on waitpid()
and has a SIGCHLD handler installed (which also calls waitpid, and
thus could steal the status if the signal handler is called before
the first waitpid returns).
Currently, I only tested this under Linux (2.2.13, 2.2.14), Solaris
2.6 and IRIX 6.5. Linux and IRIX give priority to waitpid(), Solaris
gives priority to the signal handler. That's why several plug-ins did
not work under Solaris.
If you are running another UNIX-like system (*BSD, HP-UX, AIX, etc.),
it would be nice if you could compile and run the following code and
report what it says. The code does not depend on glib, gtk or any
other libraries, so it should be easy to compile it on any system.
-Raphael
#include signal.h
#include sys/types.h
#include sys/wait.h
#include unistd.h
int pid;
int sig_pid = ;
int sig_status = ;
int main_pid = ;
int main_status = ;
static void
sigchld_handler (int signum)
{
sig_pid = waitpid (pid, sig_status, WNOHANG);
}
int
main (int argc, char *argv[])
{
int ret;
struct sigaction sa;
struct sigaction osa;
printf ("installing signal handler...\n");
sa.sa_handler = sigchld_handler;
sigfillset (sa.sa_mask);
sa.sa_flags = SA_RESTART;
ret = sigaction (SIGCHLD, sa, osa);
if (ret 0)
{
printf ("cannot set signal handler, bye!\n");
exit (-1);
}
printf ("forking...\n");
pid = fork ();
if (pid == 0)
{
sleep (1);
_exit (100);
}
printf ("waiting for child %d to exit...\n", pid);
main_pid = waitpid (pid, main_status, 0);
printf ("child %d has exited\n", pid);
printf (" sig_pid = %d\n", sig_pid);
printf (" sig_status = %d\n", sig_status);
printf (" main_pid = %d\n", main_pid);
printf (" main_status = %d\n", main_status);
if (sig_pid 0)
{
if (main_pid 0)
printf ("no child status (fork failed?)\n");
else
printf ("waitpid got the status before sigchld handler was called\n");
}
else
{
if (main_pid 0)
printf ("sigchld handler was called before waitpid (no status)\n");
else
printf ("you seem to have a very interesting OS...\n");
}
}
Re: test program for waitpid/sigchld problems
On Wed, 08 Nov 2000, Ludovic Poitou [EMAIL PROTECTED] wrote: Here's the results I got with your test program on Solaris 8, OSF1, HP-UX, AIX. [...] Results on Solaris 8: sigchld handler was called before waitpid (no status) [...] Results on OSF1- V4.0 True64 - alpha sigchld handler was called before waitpid (no status) [...] Results on HP-UX B.11.00 E 9000/715 sigchld handler was called before waitpid (no status) [...] Results on AIX 3.4 sigchld handler was called before waitpid (no status) On Wed, 08 Nov 2000, Jarda Benkovsky [EMAIL PROTECTED] wrote: FreeBSD 3.4-STABLE: sigchld handler was called before waitpid (no status) IRIX 6.5 IP22: waitpid got the status before sigchld handler was called Thanks Ludovic and Jarda for these very interesting results! According to these results, the signal handlers of the plug-ins are compatible with the following systems: - Linux 2.2.x - IRIX 6.5 But since May (when the signal handlers were changed, if I remember correctly), the five plug-ins "screenshot", "gz", "bz2", "mail", and "url" had no chance to work well on the following systems: - Solaris 2.6 and 8 - OSF1 - HP-UX 11.x - AIX 3.4 - FreeBSD 3.4 ... and there was no bug report about this in the database! Maybe we should all do our "mea culpa" and test a bit more seriously especially on non-Linux platforms, now that 1.2 is just around the corner. By the way, could someone who works on the OS/2 port have a look at the __EMX__ part of the code in plug-in/common/gz.c? If possible, after applying gimp-quinet-20001108-1.patch.gz that I uploaded to ftp.gimp.org. That code looks very suspicious to me. It contains a call to sleep(2) instead of using waitpid() for getting the output of the child process. The four other plug-ins are using waitpid() as expected. If the call to sleep() is the only way to get gz to work, then the four other plug-ins should be changed (with some comments explaining the problem). If the other plug-ins work, then why is there such an ugly hack in gz.c? -Raphael
Re: Gimp + Solaris + i18n
On Fri, 10 Nov 2000, David Monniaux [EMAIL PROTECTED] wrote: I compiled Gimp under Solaris with --with-included-gettext. Trying to run it with LANG=fr... does not yield anything translated. Nevertheless, Gimp seems to load the translation file (seen in strace). Has anyone else noticed this behavior, or is it my setup? I compiled Gimp 1.1.29 under Solaris 2.6 without the included gettext (I have GNU gettext 0.10.35 installed in my path, and "configure" is happy with it). I had never tried to set LANG=fr under Solaris, so I just tried to see if I had any problems. Well, I got the answer in less than 2 seconds... csh setenv LANG fr csh gimp gimp: fatal error: Segmentation Fault gimp (pid:15480): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0xef560cb8 in g_on_error_stack_trace (prg_name=0xec24 "gimp") #1 0xef560ba8 in g_on_error_query (prg_name=0xec24 "gimp") at gerror.c:133 #2 0x801d4 in gimp_fatal_error (fmt=0xef30e916 "Segmentation Fault") #3 0xdf2a4 in gimp_sigfatal_handler (sig_num=11) at main.c:464 #4 signal handler called #5 0xef29c2c4 in key_2_text () #6 0xef29c188 in dcgettext_u () #7 0xef29ba0c in gettext () #8 0x343f8 in make_initialization_status_window () at app_procs.c:373 #9 0x34970 in app_init () at app_procs.c:502 #10 0x33c40 in gimp_init (gimp_argc=0, gimp_argv=0xeb20) at app_procs.c:138 #11 0xdf238 in init () at main.c:430 #12 0x140228 in user_install_verify (user_install_callback=0xdf220 init) #13 0xdf1fc in main (argc=1, argv=0xeb1c) at main.c:396 It crashed before opening any windows. I tried "truss" to see the list of system calls that are done before crashing, and I see that it crashes soon after opening and mmap'ing ".../lib/locale/fr/LC_MESSAGES/gimp.mo". So it does open the file, but it crashes immediately afterwards. -Raphael
active layers (was: Onion Skinning for GIMP/GAP)
On Fri, 10 Nov 2000, "wolfgang hofer" [EMAIL PROTECTED] wrote:
For painting Animations it can be useful
to see the previous or next frame(s)
more or less transparent.
Here are 2 Variants A) and B) how to implement such features in GIMP.
[...]
B) OnionLayer is a new 'special' layertype,
known to the GIMP core app.
GIMP offers a PDB Interface
- gimp_image_add_onionlayer(image_id, src_image_id,
OnionPosition,
OnionRevers,
OnionOpacity,
OnionMode)
(do we need a special PDB interface for remove ?)
GIMP should display the OnionLayer like any other Layer,
but set to ReadOnly. (if possible)
The Display of image_id colud be updated on
every change of src_image_id
as long as src_image_id is valid.
[...]
This looks very similar to the concept of "active layers" or "shadow
layers" that I explained some time ago on this list. Other proposals
have been discussed as well, using different or similar names ("action
layers", "plug-in layers") and doing different or similar things, so
it is a bit difficult to remember what each proposal is about (because
the similar names are confusing but the underlying concepts are
sometimes different). The concept that I am refering to is the
following:
- You could add an "active layer" to an image. This layer takes as
parameters the name of a PDB function, plus some other parameters
such as references to other layers or layer groups (the layer groups
are planned for 2.0, I think).
- The references to other layers can be relative (N layers above or
below the current one) or absolute (layer number X in the stack).
- The "active layer" cannot be edited by the user.
- The layer shown or hidden, its opacity can be changed like a normal
layer, and it can be moved up or down in the stack (as long as the
contstraints of the relative references are respected).
- When you create the layer or whenever one of the referenced layers
changes, the PDB function associated with the "active layer" is run
(taking its input from the other layers) and the result is stored in
the tiles of the "active layer".
- It is possible to disable the automatic updating of the "active
layer" and to switch to manual updates for performance reasons.
Originally, I was thinking about using layer references inside the
current image only, because then you can save all parameters of the
active layer into the XCF file and they would have no dependencies on
other files.
But your proposal for "onion layers" looks like a natural extension of
this concept, if you allow an "active layer" to reference some layers
in another image. These layers with external dependencies could not
be saved in the XCF file (or we would have to come up with a very
clever mechanism for maintaining the dependencies between images) but
that would be enough for what you want to do with them. In this case,
the PDB function would be a simple copy of the referenced layer.
There are some plans to implement something like this for 2.0, so we
could start thinking about the details as soon as 1.2 is out.
-Raphael
Re: test program for waitpid/sigchld problems
On Wed, 08 Nov 2000, Michael Natterer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Raphael Quinet) writes: Maybe we should all do our "mea culpa" and test a bit more seriously especially on non-Linux platforms, now that 1.2 is just around the corner. Nope, it's just me with the "mea culpa" thing. The gimp_signal_private (SIGCHLD, gimp_plugin_sigchld_handler, SA_RESTART); call is just to restart system calls interrupted by SIGCHLD. The signal handler does nothing more than removing the zombie. But as all plug-ins which fork() also want to fetch waitpid()'s return values K I know that you added that "feature" to the code, but it was working well under Linux at that time, so everything looked OK for you. The "mea culpa" should be for all of us who saw the problem on the non-Linux systems and never reported it. Five plug-ins (including "gz" and "screenshot", which are used quite often) were broken for six months (!) on non-Linux platforms and nobody reported the problem to the bug database. Some problems with the screenshot plug-in were reported on this list during the summer, but that's all. As I wrote, I am partially to blame because I knew about the problem for at least two of the plug-ins mentioned above. But the fact that such a serious bug was ignored for such a long time does not make me feel confortable about the testing on non-Linux platforms. And the list of systems on which the Gimp was broken is larger than I thought. Here is the list of systems on which waitpid() could not return any status for the child processes, thanks to Ludovic Poitou, Jarda Benkovsky, David Brownlee, David Edelsohn, Mike Turk, Tomas Ogren, JaromÃr Dolecek, Ignatios Souvatzis, Martin Husemann and Christian Biache who sent me their results by e-mail: - Solaris 2.5, 2.6, 8 - SunOS 4.1.1, 4.1.4 - OSF1 V4.0 - HP-UX 10.20, 11.00 - AIX 3.4, 4.2, 4.3.2, 4.3.3 - FreeBSD 3.4 - NetBSD 1.4.1, 1.4.2, 1.5_BETA (m68k), 1.5_BETA2 (arm32) - LynxOS 2.5.0 The only systems that are reported to work are various versions of Linux 2.2.x and IRIX (5.3 and 6.5). Windows was not really affected by this problem, because the code is not the same on this platform. Looking at the list of platforms that were partially broken for several months does not make me feel good, that's why I sent the message quoted above. Thanks to all who reported the results of the test program. -Raphael
Re: [gimp-devel] Thanks for tablet Testing [Re: Tablet Testing Needed]
On Tue, 14 Nov 2000, Simon Budig [EMAIL PROTECTED] wrote:
Garry R. Osgood ([EMAIL PROTECTED]) wrote:
[does GTK handle the XInput-devices and the "normal mouse" in the same way?]
At present, we know that is not entirely true in two mixes of hardware.
However, the manner in which they are untrue appears essentially the same.
I have, however, just read Raphael's well-documented response, and he
is seeing quite different things. I need more time to reflect on his
mail, but his results suggest that 10498 does have hardware
dependencies. I think a sensible fix is not immediately forthcoming.
I wrote a small program to monitor the extended XInput-Events, it is
attached. For my Artpad II it shows a strange thing: If I press the "right"
Pen-Button when pressing the Pen on the tablet, each motion event is
surrounded by proximity in and proximity out events for the
eraser side of the pen. This is probably a bug in the XFree-driver
or a bad tablet-protocol. There is a strange comment in the Driver
source (The Artpad II speaks the Wacom 4 protocol, Intuos Wacom 5:
if (common-wcmProtocolLevel == 4
!(common-wcmFlags GRAPHIRE_FLAG)) {
/* The stylus reports button 4 for the second side
* switch and button 4/5 for the eraser tip. We know
* how to choose when we come in proximity for the
* first time. If we are in proximity and button 4 then
* we have the eraser else we have the second side
* switch.
*/
Maybe there is a bug in the XFree86 driver with this assumption?
I haven't tried the test program yet (I will try this evening), but
this assumption in the driver looks suspicious.
This special case for the ArtPad II would explain why the problems
seen in the Gimp are hardware-dependent. I think that #10498 occurs
because of a combination of two things:
- A bug in GTK+ (in the interaction between XInput and the core
pointer) breaks the semantics of the pointer grab, so the
application (Gimp) receives some events that should never occur
while the pointer is grabbed.
- For the ArtPad II under XFree86, another bug in XFree shadows the
GTK+ bug and causes other strange things to happen.
If this theory is correct, then the Gimp 1.2 should require a new
release of GTK+. :-(
Some code in GDK could check if the pointer is grabbed and ignore the
XInput events that should be masked during that time. Or maybe it
should put these events in a special stack or update an internal
button mask, in order to avoid spurious events later (getting a
GDK_BUTTON_RELEASE for a button that was ignored while the pointer was
grabbed). I haven't checked the code, so I don't know if this is easy
to do or not (I don't even know if the bug is really there).
The XInput-related bugs can be more serious than what is reported in
#10498. I wrote yesterday that I never saw the marching ants problem
with my ArtPad II, but that I would test what happens when the stylus
and eraser and mapped to different tools. Well... the results are not
pretty. I mapped the stylus to the rectangular selection tool, and
the eraser to the clone tool. Then I started dragging the selection
with the pen and I pressed the button on the side of the pen. The
current device switched to the eraser (oops!) and the current tool
switched to the clone tool (double oops!) although the Gimp had
probably not received a BUTTON_RELEASE. Even worse, moving the pen
with the button pressed caused the tool options dialog to flicker
quickly, meaning that it was constantly switching between the two
tools (probably once for each motion event). During all that time,
the pen (button 1) was pressed.
I repeated this test a couple of times (also with other tools) and it
did not take long before I got an assertion failed in the undo code
and all undo info for my image was lost. I did not write down the
error message, but this is probably irrelevant because the fix must be
introduced in other parts of the code (maybe in GTK+) before it has a
chance to affect the undo stack.
There is a workaround for the disappearing marching ants (duplicate
the image) but there is probably no workaround for a broken undo
stack. Until the bug is fixed, the only solution is to be very
careful and to avoid pressing the pen button while you are dragging a
selection or doing anything else that involves a pointer grab. Yuck!
-Raphael
Re: GDK and XInput
On Sun, 19 Nov 2000, "Garry R. Osgood" [EMAIL PROTECTED] wrote: I have attached a patch to gtk+-1.2.8/gdk/gdkinputcommon.h that modifies gdk_input_common_find_events() so that it will simply select device-specific event classes, given an event_mask of GDK__MASK values, without imposing relationships among events. Ants march. I no longer see diversionary menus fly in my face, and gimp otherwise seems to work well on the SGI's and the Linux laptop. I'd appreciate it if any sufferers of #10498 could try it out and see (1) if #10498 goes away and (2) brand new strangeness does not arise in gimp or other applications. Post feedback/problems here. I'd like to submit this (or something very much like this), 2000-11-22, to the GTK+ crew. I tested this patch yesterday with my Wacom ArtPad II and as I expected, it had no effect. The problem with the ArtPad II (at least with the XFree86 driver) is that it generates proximity in/out events that switch between the pen and the eraser when the pen is down and the side button is pressed. This causes the Gimp to switch to a different tool and this messes up the undo stack, among other things. Since this ArtPad II bug shadows the GTK+ bug that you have fixed with your patch, I have not seen any changes in the Gimp or any other application that I tested. More testing is needed, by people who have another type of tablet. Your patch looks good and should probably go into gtk-1.2.9 if it does not break anything (alas, I cannot test this). If this fixes #10498 for everybody except the ArtPad II users, then it may be better to close #10498 and open a new bug report that deals with the ArtPad II. What do you think? By the way, while testing what happens when the Gimp switches between different tools while you are dragging the selection, I managed to get some strange results besides the usual corruption of the undo stack and the vanishing marching ants: I had the rectangular selection tool active (as seen in the toolbox and the tool options dialog) with the context cursor of the blend tool. The pen was configured to use the selection tool, and the eraser was configured to use the blend tool. Dragging the pen with the side button pressed caused the Gimp to switch between the two tools very quickly (because of the dozens of incorrect proximity in/out events) and when I stopped, the cursor was not matching the current tool. And the image was corrupted with no chance to undo this mess, but this is usual... ;-) -Raphael
Re: [gimp-devel] Menus, shortcuts, and internationalization
On Tue, 12 Dec 2000, Simon Budig [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: On most software packages (not for Linux, though), the "underline" action keys are generally organized well enough so that it's quicker to push that key instead of moving the mouse. For laptop users this is true especially since most laptop mice don't have as much control as standard desktop mice. If you ever tried to pick a menu item from a 1024x768, 10" laptop screen , using a kludgy input device like a touchpad or one of those pointing sticks, you would appreciate the ability to push a key instead of moving the mouse. Dont argue with speed: Pressing Alt-F + x to exit a program is definitely more complicated than pressing Ctrl-Q. This goes double for nested menus. (As a sidenote: I dont think, referring to bad equipment does help us much in this case. Everybody, who touches up photos on a 10" LC-Display with a touchpad and expects a seamless workflow is nuts. You could also expect Gimp to run smoothly without restrictions on a text-terminal... :-) Although I don't like timecop's style and arrogance (timecop, please change your style if you expect more constructive replies), I think that he has a good point. The example with Alt-F + X may not be the best, but the idea of allowing all menu entries to be reached by a sequence of keys is good (not that I would implement it, but still...) I do not think that I am totally nuts, and I do use the Gimp from time to time on a laptop that has a small screen and a crappy trackpoint. Of course I only use it for simple things (mainly web-quality images, not high-res photos), but it works reasonably well. I do the more serious editing on my PC at home when I want a better quality, but the laptop is sufficient for quick and dirty work. And indeed, I have wished several times that I could use the keyboard to access some of the plug-ins. And I do not know any better solution than the one that timecop is proposing, because the current way to assign shortcuts to menu entries is limited by the total number of keys that are available (multiplied by the number of modifiers) and it would be impossible to remember all of these unique combinations anyway. I believe you are missing the point. Nobody is complaining about general shortcut keys. Things like Ctrl+L are never going away. This has nothing to do with the issue I am talking about, which is putting accelerator keys on menu items to allow faster navigation once the menu is already open. You are talking about using Alt-F to open the File-Menu. Since you have to invoke the Image-File Menu to be able to save images the general shortcut "Alt-F" would be lost for normal operations. (like repeating the last plugin). This is something that should have been mentioned earlier, and it is a pity that timecop sent his inflamatory mail instead of calming down and trying to find the root causes of the problems that he described. The shortcuts in the Gimp lack some consistency in the way they use the modifiers. Alt and Ctrl are used everywhere in the menus and the combinations of letters and modifiers were more or less chosen on a first come, first serve basis (plus some influence from other programs). Some other programs stick to the (MS?) guideline: use Alt for opening the menus, and Ctrl or Ctrl-Shift for invoking some action directly without opening the menus. Using the Alt key for opening the menus (toolbox menu or image menu) would mean that the (very useful) Alt-F shortcut would have to go. It would have to be re-assigned to some Ctrl-key combination. A lot of other shortcuts would have to be replaced, but in the end I think that the final result could actually be easier to use for everybody. Please do think about it for a minute instead of throwing the idea away because of timecop's arrogance. I tried to think about the pros and cons, and I think that a more consistent way of assigning the shortcuts could help in the long run. Anyway, this is a major change that should definitely not go into 1.2, but maybe it should be considered for 1.3/1.4. [...] So you tell me that you would like to grab for the mouse to right click for the menu and then reach for the Keyboard to navigate through the menus and think that this is more optimal than a direct shortcut on the keyboard? I don't think that his idea of requiring a right-click in the image for opening the context menu and _then_ using the keyboard is a good idea. Instead, I would prefer that Alt-F opens Image-File directly, and so on for the other entries in the context menu. If you pointer is over the toolbox and not over an image, then it would open the File menu in the toolbox. [...] I imagine most of you *hate* the Win95 key that you get for free on most keyboards (all of them now, actually) - but why not put it to good use? Why not make it open the gimp's right click menu? Because Gimp already uses
Re: [quinet] Menus, shortcuts, and internationalization
On Thu, 14 Dec 2000, [EMAIL PROTECTED] wrote:
This one covers a lot of things I previous mentioned in a bit better tone.
Quoting comes from Raphael Quinet's post #12115.
Wow, finally a person who understands my concerns, and is actually an
active gimp developer, so that things could really change :)
Calling me an "active gimp developer" is a bit too optimistic I
wish I had more time to fix the bugs that I have detected and to write
the code for the cool features that I am dreaming about. But I am
still waiting for Santa to give me more than 24 hours in a day. As a
result, it can take a long time for me to write some code or to submit
patches that I have already written but not thoroughly debugged, as
you can see here: http://advogato.org/person/neo/ (Hi Sven! ;-)
And the recent mention of the "Alpha to Logo" scripts in another mail
reminded me that I have to do something about the missing ones...
Although I don't like timecop's style and arrogance (timecop, please
change your style if you expect more constructive replies), I think
I have been trying. Unfortunately after my initial tone was severely
misinterpreted, it's difficult to get anywere, heh.
It should not be hard to understand why your initial tone was
"severely misinterpreted". Read it from the point of view of a
developer who has worked hard to bring the gimp where it is today and
who does not see any smileys or hints of humor (or modesty) in your
message. The initial impression is often hard to correct. Ah well,
let's all be a bit more tolerant. And let's hug and dance around
Barney... :-)
that he has a good point. The example with Alt-F + X may not be the
best, but the idea of allowing all menu entries to be reached by a
sequence of keys is good (not that I would implement it, but still...)
There shouldn't really be a question of implementation - the GUI toolkit
should probably take care of this much better than anything else. The
Yes, this is definitely something that should be done at the GTK
level. Alas, GTK has not been designed with enough attention on the
keyboard support. This reduces the usability and accessibility of
many applications (GNOME). Each application should be able to
customize the shortcuts as necessary ("let the users/developers
choose"), but GTK should at least provide better defaults. If an
application does not create its own shortcuts, GTK should assign them
automatically to all menu entries. For example, unless told
otherwise, GTK could automatically underline the first non-conflicting
letter of all menu entries that do not have a shortcut.
only issue I can see here is from focus switching between image/toolbox,
but that can probably be taken care of, too. Especially things like handling
key presses once the menu is open should absolutely not be handled by the
application. Take a look at how standard menus operate on Windows/Mac
whatever, and come up with a consistent solution to use in GTK. One thing
that is already overlooked at this point, is things like handling multiple
accelerator keys on the same menu - it should cycle through available choices
instead of doing what it's doing now - firing off the first available choice.
In the situation where cycling is enabled, user needs to press enter after
the selector is positioned on the correct menu. This is a worst-case
scenario - in a properly thought-out application, these conflicts should be
minimized. The only place where this kind of issue could come up is on the
filters menu where (well placed) stock plugin underline conflicts with some
outside user-installed plugin.
Again, take a look at the "other" toolkits doing it - specifically QT and
Windows.
Yes. I have to admit that Qt has a better design when it comes to the
accessibility issues (it has other drawbacks, though). And Windows too.
The difference is obvious if you disconnect the mouse from your computer
and you try to do anything complex involving several applications under
GNOME, KDE and Windows. In many GTK applications, you are stuck as some
point and your only hope is that you window manager has some Alt-arrow
key combinations for moving the pointer around or some key for closing
the offending window. It is also important to keep in mind that the
keyboard support is not only an issue for those who have no mouse (a
minority, even among those with disabilities) but also for those who do
have a mouse but want to navigate the menus faster using the keyboard.
One thing that should probably be disallowed, and might make a number of
people upset, is assigning "dynamic shortcuts" combinations to just single
letters. Therefore, either a new method for assigning toolbox shortcuts
needs to be created, or those need to be static, and not configurable. I
think, dynamic shortcuts should be limited to Ctrl+xxx and Ctrl+Shift+xxx
only, for two reasons, all keyboards are guaranteed to have those keys,
Shift-xxx and single-letter combos
Re: RFC: The future of The GIMP
Small addition to my previous message: Basically, what we need for distributing the source code of the plug-ins is a mechanism similar to CPAN, except that it should rely on a tool or plug-in distributed with the Gimp and not on Perl. It could also be extended for fetching binaries, but this is a low-priority feature IMHO. -Raphael
Re: gimp patch 1.1.32-1.2.0 [Also: Re: cmon guys, no patch from 1.1.32 to 1.2??]
On Wed, 10 Jan 2001, [EMAIL PROTECTED] wrote: On 9 Jan, Christopher Curtis wrote: They do; if we started now to switch over to deltas then quite a few people would complain about that. I definitely see the point, I'm behind a very narrow pipe as well so I prefer patches, too, but what is even more comfortable than patches is CVS, because they don't suffer from the problems patches do and are much easier to get and more complicated to mess up the source. This is not true for everybody. For example, I usually access the Internet from work and I use a laptop, ZIP, CD-R or floppies to transfer files to my PC at home. A firewall prevents me from accessing anything that does not use FTP, HTTP or SMTP. This means that I can easily download patches and bring them home, but I cannot use CVS. Note that the absence of binary files in the patch files can also be considered as a feature for the weakly-connected users: the patches are much smaller because they do not contain the latest splash screen or brushes that is included in every new version. This saves half a megabyte for every download. I don't see a public rsync server for gimp, cvs or otherwise. Perhaps this might be an acceptable option for people with modest bandwidth capabilities. There are anonymous CVS servers for the GIMP. Two days ago, I installed a new modem on my home PC because I thought that after having spent several years working with semi-obsolete released versions of the source code, I should get the bleeding edge and use CVS from home (no firewall problems). So I tried to get the latest gimp from the anonymous CVS server(s). Unfortunately, none of the three addresses mentioned for anoncvs allowed me to get any files. One of them failed because of a server configuration problem, another one could be reached but did not respond, and the last one was apparently offline because it could not be reached at all (no ping). I hope that the situation is better for the non-anonymous CVS server. I would be glad if anyone could give me the IP address of an anonymous GNOME CVS mirror that works reasonably well for European users. -Raphael
Re: Re: FreeImage
On Mon, 15 Jan 2001, Martin Weber [EMAIL PROTECTED] wrote: I am no GPL expert, but I think it is compatible to GPL, but it does not have a plugin interface. [Lourens Veen [EMAIL PROTECTED] wrote:] But is the license GPL compatible? And is it as flexible as the current plugin system? [Martin Weber [EMAIL PROTECTED] wrote:] There is a very very fast (faster than Photoshop) image loader called FreeImage: http://home.wxs.nl/~flvdberg/ With small adoptions it also runs with Linux. I had a quick look at the FreeImage license, and I am not sure that it could be GPL-compatible. The license is available in text format from: http://home.wxs.nl/~flvdberg/freeimage-license.txt and in HTML format from: http://home.wxs.nl/~flvdberg/intro.html#license The spirit of this license is similar to the GPL, except that it has some sections specifically addressing the patents that could protect this code. Some things make me think that it could have problems with the GPL: 1) The sections on patents. It specifically states in sections 2.1.b, 2.2.b and 3.4 that the initial developer (Floris van den Berg) or other contributors may have current or future patents on the algorithms or interfaces used in the program. The rights granted on these patents are granted "solely to the extent that any such patent is reasonably necessary to enable You to Utilize the [code] and not to any greater extent that may be necessary to Utilize further Modifications or combinations." This is probably not compatible with the GPL, which forbids you to include any discriminations against the free usage of the code. 2) Section 3.1 states that "You may not offer or impose any terms on any Source Code version that alters or restricts the applicable version of this License or the recipients' rights hereunder." This basically prevents you from changing the license, and I think that some parts of the GPL could be considered as additional restrictions. 3) In section 3.2, the minimum amount of time during which the source code must be offered to anybody who did not get it together with the binaries is shorter than the one required by the GPL. 4) The indemnification clause in section 3.6 seems suspicious to me, and contrary to the "no warranty" of the GPL. 5) Section 3.7 is similar to the virus-like feature of the GPL: the license must be applied to any larger work containing the covered code. Since both the GPL and the FreeImage license state that all of their requirements must be fulfilled by any package including the covered code, and since these licenses seem to have incompatible requirements, I doubt that we can use any of the FreeImage code. So I think that we have no other choice than to stay away from the FreeImage code. Especially if any part of it is covered by some patents. In that case, we should not even look at the code, in order to be sure that we are not involuntarily including any patented stuff in the Gimp. Unless someone who is more qualified than me in legal matters can certify that the FreeImage license is GPL-compatible, we should not use any part of it. -Raphael
How to get access to the new bug database?
Since the GIMP/GNOME bug database has moved to bugzilla.gnome.org, the administrative options have changed. On the old bugs.gnome.org, it was possible for me to change the status of some bugs easily, but now I cannot change the status, affected OS, priority and other features of the bugs. I have been through the list of GIMP bugs and I know that some of them could be changed from UNCONFIRMED to NEW or NEEDSINFO. I also spotted several of them that could be set to "All OSes" instead of "Linux". Or some suggestions for enhancements (including some that I originally reported) that could be set to "Low" priority. I would like to help and keep the bug database up-to-date, but unfortunately Bugzilla does not let me change these options. Since the Bugzilla home page does not mention any contact address, I am sending this slightly off-topic request to this list. If anyone know who to ask, please tell me. Thanks. -Raphael
testers needed for bugs #22567 and #50867
It looks like some strange things are happening in the Gimp (any version since 1.1.x) if you create an image of size 1x63 or similar sizes. Some of these effects (related to the tile management, IIRC) had been discussed on this list in the past, but the strange thing is that some people (Seth, Marc) do not seem to be affected by #22567 while others get some strange errors with exactly the same version of the Gimp. This is apparently independent of the operating system, X display or window manager used because I could reproduce #22567 on different platforms. Please read the comments on the following pages and see if you can add any useful information. If you can find two configurations (software versions, compilation options, environment variables, window manager, or some other settings) in which the bugs appear or do not appear, that would probably help to track down the source of the problems. I already tried to include as much information as I could find in these bug reports: http://bugzilla.gnome.org/show_bug.cgi?id=22567 http://bugzilla.gnome.org/show_bug.cgi?id=50867 Feel free to add your own comments to these bug reports... Bug #22567 generates a GTK+ warning when you undo a resize. Bug #50867 can apparently crash 1.3.0 if you run some plug-ins (with version 1.2.1 it generates many GTK+ warnings but otherwise it works). -Raphael
