Re: RUN_WITH_LAST_VALUES
On Friday, 16 Feb 101, Miles O'Neal wrote: Robert L Krawitz said... | |Under what circumstances is RUN_WITH_LAST_VALUES intended to be used? |Is it something I should be particularly concerned with in the print |plugin, or would dropping it be reasonable? It's for when you want to rerun a plugin withoout having to mess with the values. For instance, Filter - repeat last. Does it make sense for printing I don't know. Where's the printing equivalent of Gilter-Repeat Last ? Its just that: Filter-Repeat Last. If the last thing you did was print, then it prints again. I've been meaning to find a way to update the menu item to include the filter name so you can get a better idea what will happen, eg: Filter-Repeat Last (blur IIR) or something. Austin
Re: RFC: unified system of PaintObjects (long)
On , 9 Feb 2001, Jens Lautenbacher wrote: Therefore I propose to completely rewrite everything that can be considered a "PaintObject" into a generic provider form, where the paintcore for each operation asks the provider for it's data. It would be nice to be able to use loadable modules to implement new "providers", so that the first cut can ignore natural media, but then (eg Raph?) can add them later as a module. Basically, make it a nice harness for the people playing with watercolour simulators etc to use. Austin
Re: View shrink factor
On Saturday, 10 Feb 2001, David Monniaux wrote: Exactly which functions handle the low-level actual enlargement or shrinking of display? I'd like to write MMX versions for them. I modified the original code to handle non-integer scale factors. It lives in image_render.c I'm not sure how much use an MMX version will be, given the large variety of platforms GIMP runs on. Keeping two version of the code (ASM + C) in sync is also a bit of a nightmare. (Just my 0.02 Euro's worth) Austin
Re: Logarithmic histogram
On Monday, 5 Feb 2001, Jay Cox wrote: Linear, Log, and sqrt are all common ways to scale histograms for display. Perhaps we should make it an option in preferences (or in the histogram display itself). sqrt() - I haddn't thought of that. That sounds plausibly like what Photoshop is using. I might have a play with that. Austin
Re: [BUG] font ... not found on some images, works on others
On Thursday, 8 Feb 2001, Frank de Lange wrote: [fonts work on some images, but not others] Check both image's resolution: they're probably different. If you ask the text tool for text in a particular "point size", then it needs to scale it so it comes out at the right size for the image's resolution. If you ask for text sized in terms of "pixels", then it won't get scaled, and you'll probably get the results you expected. New images (by default) are close in resolution that of your screen, so the distinction between points or pixels is minor. Maybe the text tool should default to selecting pixel sizes, not point sizes? Too many people get confused. Austin
Re: Logarithmic histogram
On Sunday, 4 Feb 2001, Roel Schroeven wrote: I noticed in the source code that the histogram widget uses a logarithmic scaling. Is there a reason to do it that way, as Photoshop et al. seem to use a linear scaling. I just checked the CVS history; we've been using a log y axis (ie pixel count) ever since the histogram widget was writen. Jay Cox checked in the initial rev (including log scale) in March 1999. I've played around a bit with gimp looked at some web-based tutorials for histogram use in photoshop, and while I agree that gimp's log axis graphs don't look very similar to photoshop's, I don't think photoshop just uses raw counts. They also scale their data, but a little less aggressively than by a log scale. Austin
Re: problem with gtk+ colorselector
On Sunday, 4 Feb 2001, Nick Lamb wrote: What does the GTK+ selector bring to the party anyway? Nothing: it's a "demo" piece of code showing how to interface your colour selector to the GIMP module API. The point being that there is no actual colour selector code there, since it's all in GTK, so the module API is clearer. It's useful to programmers, not artists :) You can always check the "load inhibit" button in the module browser, if you don't like it. Austin
Re: incorrect mask handling in histogram calculation
On Saturday, 3 Feb 2001, Roel Schroeven wrote:
In gimphistogram.c there is a function to calculate the histogram for a
subregion, declared as follows:
gimp_histogram_calculate_sub_region (GimpHistogram *histogram,
PixelRegion *region,
PixelRegion *mask)
In that function we have this code snippet:
if (mask)
{
gdouble masked;
src = region-data;
msrc = region-data;
I would think that msrc ought to be a pointer into the mask data instead
of the region data, like this:
msrc = mask-data;
Yes, this is indeed a bug.
However, its not quite that simple.
The histogram code is used by a number of other tools: as part of the
histogram tool (Image/Image/Histogram...) but also as part of the
Levels tool (Image/Image/Colors/Levels...), the Threshold tool
(Image/Image/Colors/Threshold...) , and the Equalize tool
(Image/Image/Colors/Auto/Equalize).
All except the histogram tool care about the current mask (ie
selection), since they restrict themselves to only operating on that
part of the image.
The histogram tool always gives the full histogram for the current
layer, ie it ignores the current selection.
So, fixing this bug means that the Levels tool, the Threshold tool,
and the Equalise tool will all also change their behaviour: currently
they use a histogram of the entire layer, but restrict their changes
to the current selection. Fixing the bug means that the histogram
will only be calculated for within the selection too. Is this the
desired behaviour?
Austin
Re: Chilliware and GIMP
On Wednesday, 24 Jan 2001, Scott McDaniel wrote: Unfortunately, one of the responses was a tad over the top, and I felt I needed to reconfirm our request... Yes, we understand the license; yes, we also understand that Gimp CAN be distributed freely, however, we chose to be courteous and ask the developers also, as some folks like to know where there software is showing up. Attached below are the 3 different responses we garnered from our request to you guys...if there is someone in charge there, I would like to offer the same courteous question: "Do you mind if we include Gimp and its sources on our CDROMs?" The Gimp is developed co-operatively, so there's no single person in charge. Yosh [EMAIL PROTECTED] is the person who decides when to make releases, and so is probably the closest we have to an official spokesman. I apologise for the second message you quote: I don't think it is representative of the majority view of the developers. You are most welcome to distribute The Gimp on your CD, so long as you abide by the terms of the GNU Public Licence (GPL). In brief, this means ensuring that the source code is available, either directly on the CD or by giving a URL for where the code can be found. See the file "COPYING" at the top of the Gimp source code distribution for the full details. Thank you for being courteous in letting us know you intend to distribute The Gimp. Austin
Re: Suggestions for gimp
On Saturday, 6 Jan 2001, Orson Jones wrote: As I was reading 'Grokking the GIMP' I came up with some ideas. Unfortunantly, I don't have the skills/knowledge to implement these myself, So I hope I can describe them well enough that you can figure out what I'm thinking. If I still don't make sense, I can make some illustrations to help explain them. Select Within Adds to the selection everything that is fully contained within the selection (An option for this) Leave large areas unselected (checkbox with slider for minimum large size) See my pre-Christmas post of a patch to add a "tighten selection" item to the selection menu. Austin
Re: Submitting Patches
On , 8 Jan 2001, Sven Neumann wrote: A short patch like this one can always be sent through this list. But I'd prefer if you could redo the patch, because of the following reasons: - it reverts a change in the preferences dialog. You obviously didn't cvs update before creating the diff. - it changes some autogenerated code (the files ending in _cmds.c). The changes have to performed in the directory tools/pdbgen/pdb on the .pdb files. You could help us by providing a new patch. Sent it to the list again or upload it to ftp.gimp.org. It might be an idea to put info like this in the HACKING file, so we don't need to keep repeating it. Austin
Re: suggestion for gimp 1.3 and later
On Wednesday, 13 Dec 2000, Rebecca J. Walter wrote: "Guillermo S. Romero / Familia Romero" wrote: [EMAIL PROTECTED] (2000-12-13 at 0057.14 +0100): I think it would be a good idea to add a grid function like some other Are you speaking about something like the Perl scripts that create a grid and remove guides? i ran one of those to make a grid of guides, but it would be nice to have a grid that isn't the same as guides. If you just want a visual aid, how about using Image/Filter/Render/Pattern/Grid... ? You can put it on a separate layer, and adjust the opacity to just have them showing through. It won't do your snapping though. Austin
Re: Fw: Bug#34849: Confirmation (initial_sub_region:: error :: src-w * (src-bytes + 1) 521)
On Monday, 11 Dec 2000, Paul E.C. Melis wrote: Hi, I wrote about the "initial_sub_region:: error :: src-w * (src-bytes + 1) 521" bug/message to this list some time ago, and now it appears somebody has submitted a bug report to the bug list about it (which I should have done myself in the first place, I guess). That somebody obviously entered the subject line by hand, because now it reads " 521", instead of "512", but thanks anyway :-) However, the automated confirmation message sent to me from bugs.gnome.org (see below) says the report did not include a Package: line. I attempted to reassign the report to package gimp, but everything I send to either control@, request@, [EMAIL PROTECTED] is failing to arrive there. Do you need special permission to do this stuff? I scanned most of the help on bugs.gnome.org but couldn't find anything there about it. Also, I have no way of accessing the ticket with this number, the bugs site can't find it :/ Am I too wait before it appears somewhere? Sorry - my fault. I submitted the bug report on your behalf, and forgot to add the Packages line. I'll fix the typo in the title, and reassign it to gimp for you. Austin
new 1.1.x release please?
Please Yosh, can we have another 1.1.x pre-1.2 test release? There are a bunch of bugfixes that have gone into 1.1.29 and it would be nice to get another release candidate out. Austin
Re: idea: tighten current selection
On Tuesday, 5 Dec 2000, David Bonnell wrote:
On Wed, 6 Dec 2000, Austin Donnelly wrote:
...
Probably the easiest way would be to use select by colour, but that
would catch other stuff that was a similar colour.
Could change "Select by Colour" to only select pixels within the current
selection if there is one, or the entire image (or layer) if there
isn't an active selection.
With this, you could lasso the general area the text is in, then go
Image/Selection/Tighten to get just your text.
That would certainly be a very useful tool.
Oops. I accidentally implemented it.
Patch against 1.1.29 attached below.
It needs some work:
o The algorithm to find the start point for the seed fill is pretty
dumb: it picks the topmost image pixel in the selection, and flood
fills from there. Plus its a really inefficient implementation of
this brain dead algorithm.
o No PDB access functions.
o No help file.
o No way to tweak edge detection threshold
o No way to set sample merged, so it only works on the current layer
(These last two are because it has no UI. I don't think it should
have a UI since it's supposed to be quick and just do the right
thing. Mostly it does.)
If anyone feels like playing with it, let me know how you get on.
I think it's pretty cool (but then I'm biased).
Austin
--- commands.c~ Mon Oct 30 01:33:11 2000
+++ commands.c Wed Dec 6 17:05:24 2000
@@ -390,6 +390,19 @@
gtk_widget_show (shrink_dialog);
}
+
+void
+select_tighten_cmd_callback (GtkWidget *widget,
+gpointer client_data)
+{
+ GDisplay *gdisp;
+ return_if_no_display (gdisp);
+
+ gimage_mask_tighten (gdisp-gimage);
+ gdisplays_flush ();
+}
+
+
void
select_grow_cmd_callback (GtkWidget *widget,
gpointer client_data)
--- commands.h~ Mon Oct 30 01:33:11 2000
+++ commands.h Wed Dec 6 17:25:14 2000
@@ -52,6 +52,7 @@
void select_feather_cmd_callback (GtkWidget *, gpointer);
void select_sharpen_cmd_callback (GtkWidget *, gpointer);
void select_shrink_cmd_callback (GtkWidget *, gpointer);
+void select_tighten_cmd_callback (GtkWidget *, gpointer);
void select_border_cmd_callback (GtkWidget *, gpointer);
void select_grow_cmd_callback (GtkWidget *, gpointer);
void select_save_cmd_callback (GtkWidget *, gpointer);
--- gimage_mask.c~ Mon Oct 30 01:33:14 2000
+++ gimage_mask.c Wed Dec 6 18:06:40 2000
@@ -22,6 +22,7 @@
#include "floating_sel.h"
#include "gdisplay.h"
#include "gimage_mask.h"
+#include "fuzzy_select.h"
#include "gimprc.h"
#include "layer.h"
#include "paint_core.h"
@@ -478,6 +479,55 @@
edge_lock);
}
+
+void
+gimage_mask_tighten (GImage *gimage)
+{
+ Channel *mask;
+ Channel *shrinkage;
+ GimpDrawable *drawable;
+ gint x1, y1, x2, y2;
+ gint x;
+
+ g_return_if_fail (gimage != NULL);
+ drawable = gimage_active_drawable (gimage);
+ g_return_if_fail (drawable != NULL);
+
+ mask = gimage_get_mask (gimage);
+ g_return_if_fail (mask != NULL);
+
+ undo_push_group_start (gimage, MASK_UNDO);
+
+ channel_push_undo (mask);
+
+ /* if there was no selection, then assume the entire image was selected */
+ if (channel_is_empty (mask))
+ channel_all (mask);
+
+ /* Pick a point within the selection from which to start the seed
+ * fill. */
+ channel_bounds (mask, x1, y1, x2, y2);
+ x = x1;
+ /* XXX FIXME: seriously costly loop: should do pixel iteration
+ * ourselves */
+ while (x x2 channel_value (mask, x, y1) 128)
+ x++;
+
+ /* XXX Need to find some way of presenting the threshold and sample
+ * merged options to the user, without getting in their way. */
+ shrinkage = find_contiguous_region (gimage, drawable,
+ /* antialias */ TRUE,
+ /* threshold */ 15,
+ x, y1,
+ /* sample merged */ 0);
+ channel_combine_mask (mask, shrinkage, SUB, 0, 0);
+ channel_delete (shrinkage);
+
+ gimage_mask_invalidate (gimage);
+
+ undo_push_group_end (gimage);
+}
+
void
gimage_mask_layer_alpha (GImage *gimage,
--- gimage_mask.h~ Mon Oct 30 01:33:14 2000
+++ gimage_mask.h Wed Dec 6 17:29:56 2000
@@ -81,6 +81,8 @@
gint shrink_pixels_y,
gboolean edge_lock);
+voidgimage_mask_tighten (GImage *gimage);
+
voidgimage_mask_layer_alpha (GImage *gimage,
Layer*layer);
--- menus.c~Mon Oct 30 01:33:22 2000
+++ menus.c Wed Dec 6 17:24:42 2000
@@ -285,6 +285,8 @@
"select/sharpen.html", NULL },
{ { N_("/Select/Shrink..."), NULL, select_shrink_cmd_ca
Re: PhotoCD plugin + latest gimp
On , 24 Nov 2000, Philip Armstrong wrote: I've patched the PhotoCD (pcd) plugin xhpcd to work with the latest devel gimp, but had no response from the author. So if anyone wants a copy of the patch, feel free to mail me at [EMAIL PROTECTED] Yes. If it's short, please send your patch to the gimp developer's mailing list (see headers). Otherwise we'll sort something else out. Austin
Re: TGA plugin bugfix
On Friday, 24 Nov 2000, Lourens Veen wrote: About three weeks ago now I found a bug in the TGA loader. I patched it and sent the patch to [EMAIL PROTECTED] I got a reply that it had been forwarded to the maintainer of the plugin, but I haven't heard anything since. So I'm trying the mailinglist. I think Nick Lamb fixed it in CVS: 2000-11-18 Nick Lamb [EMAIL PROTECTED] * plug-ins/common/tga.c: Fix alleged problem with small images This fix will be more widely available when Yosh makes another 1.2 release candidate available. It's been almost a month since 1.1.29 so we're probably due another test release soonish (Yosh?) Austin
Re: PhotoCD plugin + latest gimp
On Friday, 24 Nov 2000, Philip Armstrong wrote: On Fri, Nov 24, 2000 at 10:27:08AM +, Austin Donnelly wrote: On , 24 Nov 2000, Philip Armstrong wrote: I've patched the PhotoCD (pcd) plugin xhpcd to work with the latest devel gimp, but had no response from the author. So if anyone wants a copy of the patch, feel free to mail me at [EMAIL PROTECTED] Yes. If it's short, please send your patch to the gimp developer's mailing list (see headers). Otherwise we'll sort something else out. Alessandro Baldoni [EMAIL PROTECTED] is still maintaining it. I've exchanged some email with him. He says he has his own patches to work with the latest Gimp. Thanks for your help though! Why not take a look at the bugtracker http://bugs.gnome.org/db/pa/lgimp.html and pick a juicy bug to fix: we'd be forever greatful! Austin
Bug severity levels (was: Re: GDK and XInput)
On Friday, 17 Nov 2000, Garry R. Osgood wrote: If no one objects, I would like to elevate #10498 from 'critical' to 'grave.' Through a chain of causuality originating with edit-select not being able to perform a thaw, eventually (sometimes) there is a fatal crash in undo. Not sure why, but grave bugs are the ones that crash Gimp - at least sometimes. This isn't the case. "Grave" bugs are less serious than "Critical" bugs (as the adjectives suggest). "Critical" is for segfault-inducing bugs, and anything else we consider release-critical (ie bugs of this class should not be present in a stable release we make). Austin
Re: GDK and XInput
On Friday, 17 Nov 2000, Garry R. Osgood wrote: [...] In light of an (is it coming? Really?) 1.2 Release The question I have for the group is: 1) Document, warn, but otherwise ignore the problem. It affects users with a certain type of tablet hardware and only when that hardware is being used as an explicit XInput device. Wait for a GDK fix to remove its hidden policy? 2) Make a Gimp level hack in the much-abused event loop to filter button presses that originate from devices when a grab is in effect. (not pretty -- except for possibly being pretty lame)? 3) Re-engineer select tool code to be more robust in button press events (much work here)? Which of these is the best line of action? Do you have other proposals? We would like a new GTK release for one other reason: the g_io_channel handlers needed an new error code, and we supplied TimJ with a patch to implement this. Having this in GTK would mean we can get rid of the mega-evil hack in the Gimp's g_io_channel use. Has that patch gone into GTK yet? With now two reasons for a new GTK release, would the GTK maintainers consider making it? Austin
Re: ANNOUNCE: GIMP 1.1.29
On Tuesday, 31 Oct 2000, Manish Singh wrote: GIMP 1.1.29 is out there. This is a release candidate for 1.2. So scream if you see any major brokenness. Uh, well, there's at least: #17904: rounding error in calculation of selection boundary Subject: gimp; Severity: grave; Reported by: Austin Donnelly [EMAIL PROTECTED]; merged with #22375; 99 days old. #17906: layer move mouse handling not pixel-perfect Subject: gimp; Severity: grave; Reported by: Austin Donnelly [EMAIL PROTECTED]; 99 days old. #25272: [gimp-bug] The thumbnails (.xvpics) do not always match the image. Subject: gimp; Severity: grave; Reported by: [EMAIL PROTECTED]; 41 days old. (and this bug is actually the tip of a can of worms; see the recent discussion on this list) #27786: screenshot plugin on Solaris takes bus error on exit Subject: gimp; Severity: grave; Reported by: Austin Donnelly [EMAIL PROTECTED]; 19 days old. (this one is actually a bit more complex that that, and it probably affects other platforms too, it's just that Solaris feels it particularly badly). I'm pretty sure there's other equally serious bugs: these are just my favourites. On the bright side, I don't think we have any easily-reproducible segfaults in the main application. If anyone knows of any, shout now! Austin
Re: Gimp gimp-1.1.28 (script-fu problem)
On Wednesday, 25 Oct 2000, Jeff Sheffield wrote: the splash screen hangs with the subtitle Plug-ins and the path /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/script-fu another interesting thing that happens is. when I ctrl-C the app I get the following strange output - [jsheffie@kelly bin]$ ./gimp ^[[A./gimp terminated: Interrupt /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/animate_cells terminated: Interrupt --- animate_cells...?? That's presumably the plugin that's currently in the process of being probed when you killed the main application. Make sure you've deleted all the plugin directories before you "make install" so there aren't any old plugins left around. Austin
Re: Off-by-one errors on large images..
On Friday, 20 Oct 2000, Tuomas Kuosmanen wrote: While I have been doing some larger images, mostly 1600x1200 size and bigger, I have noticed that if I zoom the image smaller, I get a lot of one-pixel wide vertical artifacts when I move floating selections around. I think I have had the "view selection" toggled off. Looks like some of the code that cleans up after moving the layer is just sweeping the dust in one pixel too narrow area or something..? There are also some one-pixel-distorting when making icons (small images) and zooming them very large on the screen so that the pixels are huge - the pixel squares distort on the edges when I pan the image around with middle mousebutton. Anyone else experiencing something like this? Yes, sort of. Not quite exactly the same circumstances, but I filed a bug report on something quite similar. The bug tracker's webpage seems to be down at the moment, otherwise I'd be able to give you a Bug# for it. There are a bunch of inconsistencies in the co-ordate transform code that show up as single pixel-wide problems at high zooms (or in your case at low zooms on large images). I've been meaning to look into it, but haven't found the time :( Austin
CVS server still down?
Can anyone actually access cvs.labs.redhat.com? I don't get any replies to my SYNs! Austin
Re: Gimp (plus earlier versions) fail with
On Monday, 2 Oct 2000, Raphael Quinet wrote: On Sun, 01 Oct 2000, "Dr. David Kirkby" [EMAIL PROTECTED] wrote: Thanks to everyone who suggested I increase the amount of shared memory on my SPARC so Gimp would not disable shared memory tile transport. I added this to /etc/system: set shmsys:shminfo_shmseg=64 after a reboot Gimp worked fine. FYI, I have added the following lines to /etc/system on all Solaris machines that I use: # increase shared memory limits (for GTK+ applications) set shmsys:shminfo_shmmax = 0x200 set shmsys:shminfo_shmmni = 0x1000 set shmsys:shminfo_shmseg = 0x100 By default, Solaris has a limit of 6 shm segments per process, 100 in total, and allows a maximum segment size of 1 MB. You can check the current values by running the command /usr/sbin/sysdef. By increasing all of these parameters, I am sure that I can use many GTK+ applications without warnings. Can whoever maintains the FAQ add a question on this to it, please? Also, the build instructions should probably mention this somewhere. Possibly even the configure script should print something if it discovers it's on a Solaris box, and grepping /etc/system doesn't return satisfactory limits. Austin
Re: TODO for 1.2 release
On Monday, 25 Sep 2000, Nick Lamb wrote: 1. VAGUE: Documentation should be "good" (definition anyone?) 2. Critical/ Severe bug reports should be fixed or marked down (bug #s?) 3. VAGUE: Gimp should build out-of-box on lots of systems 99. Find and #ifdef any debug scribble to console 100. Check package files, READMEs, etc. for correctness I agree. In the lists below, I ignore all build problems. There should probably be a separate list of bugs relating to build problems (there seem to be quite a few). I have also skipped over some bug reports to do with plugins. In order of seriousness: A: The gimp core 1) Bugs that cause the main gimp process to crash, or make it impossible to save your work: release CRITICAL. #21269 Bus Error when using paint brush #12582 Crash when 'progressive' selected in jpeg save #12263 Going to "Save As" causes segfault #8150 gimp crashes when loading an invalid brush (which is easy to create) #5878 Xsetpointer change crashes GIMP 2) Correctness problems with main gimp process: GRAVE/CRITICAL. #25272 The thumbnails (.xvpics) do not always match the image. #25266 Load,Crop, then Save results in original (not cropped) image being saved #23601 stand-alone nav window doesn't update on layer info changes #19285 Convolver tool won't operate within 2 pixels of image edge #18913 Brush scaling problems with Size option (pen tablet) #13229 "Magic wand" selects whole image when it's fully zoomed in on. #12754 Crop From Selection, doesn't quite. #10125 "quick" colour picker does not honour "sample merged" #8141 leftover images #7829 merging a layer in dissolve mode makes the layer to look like it was "normal" #6901 Can not continually move a floating selection with a pressure sensitive pointer. #6050 ** WARNING **: wire_read: error for all the plug-ins #5745 module unload needs to be from gtk idle loop #5560 layer dialog disturbing scripts? 3) Problems with presentation: incorrect image refreshes, tool xor dust, and other cosmetic problems: GRAVE. #17904 rounding error in calculation of selection boundary == #22375 GIMP leaves strange (ugly) lines when moving a selection. #21936 Cursor position window doesn't expand after undo #17906 layer move mouse handling not pixel-perfect #16583 "new view" not being updated correctly #10554 Large .jpg not scaled on open #10498 Marching Ants die untimely deaths 4) *** GTK/GDK etc warnings: GRAVE. Most of these arise from failed assertions, and are an indication of some deeper problem. Just because the system stays up doesn't mean it will continue behaving correctly. #22567 window size confused after un-doing resize #15546 some text display problems on HP-UX 5) everything else: NORMAL. B: Plugins -- For plugins, I think we need to take some tough decisions as to which plugins are supported, and which aren't. I don't know how to do this, but others have suggested looking at which are mentioned in the MAINTAINERS file. Once we've decided a plugin is supported, this should mean: 1) All known segfault bugs fixed. #8139 gimpressionist segfaults #7437 Gimpressions crashes 2) Correct, expected behaviour, on all image types. #25968 NL Filter gives strange effects when using alpha 0.5 #25963 Undo of "value invert" on indexed PNG is impossible #12299 NL Filter: shift by one pixel #11828 GIF load fails #10679 Some Scripts mess up the layer stack (Xach Vision) #9156 bug in ifscompose For unmaintained plugins, it depends how much they're used. I suggest running an "adopt a plugin" programme, where people are encouraged to become a plugin "owner", thereby accepting responsibility for its correctness. They should be encouraged to take pride in their plugin. If someone cares about a particular plugin, they will maintain it, otherwise it dies: very Darwinian :) C: Script-fu, perl-fu etc - Check all scripts do something plausible. Hopefully the same as they did under gimp 1.0.4. Maybe this should get a higher priority, but I've never really cared much for the script-fus, and I've never been able to get the perl stuff to work, so I just --disable-perl these days. It may be that some of the bugs I mention above don't exist anymore, or are not reproducible. They should be followed up and eventually closed if the originator can't reproduce them either, or if there's a ChangeLog entry that claims to fix the bug. I'll change the priority of the bugs as I mentioned above. Austin
Re: TODO for 1.2 release
On Tuesday, 26 Sep 2000, Tim Mooney wrote: @@ -2322,6 +2322,7 @@ G_IO_ERROR_NONE, G_IO_ERROR_AGAIN, G_IO_ERROR_INVAL, + G_IO_ERROR_INTR, G_IO_ERROR_UNKNOWN } GIOError; This breaks backwards binary compatibility, since the numeric value of G_IO_ERROR_UNKNOWN changes. I agree it looks nicer, though. See my (very similar) patch attached to the end of this email, which doesn't have this problem. It builds and works correctly in (very) light testing on gimp 1.1.23 and glib 1.2.8 Tor, are there similar changes needed to giowin32.c ? Austin eintr-patch
Re: Code cleanup
On Thursday, 31 Aug 2000, Maurits Rijk wrote: 3) sometimes it's just lack of C knowledge: if (p) free(p); can be simply replaced by just: free(p); I would not assume that it is safe to free() a NULL pointer in _all_ vendor's libc implementations. That's why there are things like g_free() that explicitly make these kind of guarantees. 4) some plugins have obvious memory leaks. Be careful - it is easy to "fix" a memory leak and introduce another bug where some contorted path through the code actually does use the memory. This has already happened a few times within the last year. So my question: is it worth the effort to carefully go through all the code (not only plug-ins) and clean things up? Yes, if done properly. However: 3) during the process we might find further bugs. Yes, but a code walk-through would have the same effect, without potentially adding more bugs: 2) we might break things that work This is the biggest danger right now. A freeze is a freeze! Austin
Re: xpm output: is RGB a legal xpm format?
On Tuesday, 22 Aug 2000, Uwe Koloska wrote: possibly this one is fixed -- for now I am only using 1.1.18 from SuSE 6.4. (I'm checking this with 1.1.25). With this (and possibly later versions) it is possble to save an RGB image to xpm format. I don't know the xpm format, but the xpm code from kde 1.1 isn't possible to load such an not-indexed xpm image. Actually, it is still an indexed image, it just has a large number of colours (my test was a full spectrum gradient and it had around 1300 colours). So two questions: o is it legal to save an xpm image in not-indexed format? No - but gimp produces an indexed xpm. xv and ImageMagic's "display" were both happy with the xpm, and displayed it correctly. Neither use libXpm do parse the files. o is the header of this not-indexed format right? Maybe there is missing the indication for the RGB format I think the xpm is correct. It's possible the KDE code may not be able to handle colourmaps with more than 256 entries. libXpm manages it fine, since this is what gimp's plugin uses to parse the files. Maybe KDE should use libXpm rather than their own routines? Austin
Re: Gimptool in Gimp 1.0.4
On Tuesday, 1 Aug 2000, Marc Lehmann wrote: On Mon, Jul 31, 2000 at 09:29:01PM -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: Any suggestions? Is Red Hat broken, or is it our configure script? Obviously, if gimptool is missing the rpm source (e.g. the distro) is broken, as is the usual case. Most likely the users have not installed the gimp-devel package. Austin
Re: gimptool using --prefix for install?
On Tuesday, 1 Aug 2000, Alexander Skwar wrote: Can I somehow use gimptool to do this? I thought about something like "gimptool --prefix ~/tmp/prefix-dir --install-admin-bin pluginfile", and then gimptool should install "pluginfile" to "``~/tmp/prefix-dir''/usr/lib/gimp/1.1/plug-ins/", (without all those ",' `) but this obviously does not work. So, how can I find out where the plug-ins directory of gimp is? The --prefix idea for gimptool sounds like a good and useful feature. Some work needs to be done on gimptool before 1.2 can release. In particular, we need to be able to use it to automate the building of DLL modules without using a gimp build tree. Does anyone have skills in hacking it? Last time I looked it was a bit nightmarish. If there's no-one better qualified to hack it, then I will. But it won't be pretty :( Austin
Re: Docbook (Help files)
On Monday, 31 Jul 2000, Kevin Turner wrote: [Kevin checks the latest mail. Now it seems we have a help template file in HTML. Okay. Uh-oh, it's under a non .gimp.org domain, Sven will frown about that.] The template includes "-" as a menu path separator. The problem with this is that it suggests actually using "-" literally in the HTML, rather than the more correct "-gt;". Personally, I think anything that makes updating the help text as easy as possible is good. Ideally, there would be a button at the bottom of the help browser labelled "email corrected version" or something, that people could use if they come across typos, wrong, or missing info. Make it totally trivial for people to scratch their itch, basically :) Austin
Re: Bug reports
On Wednesday, 19 Jul 2000, Sven Neumann wrote: Can someone close the following bugs? I have reported this twice to [EMAIL PROTECTED], but no one closed them. #12303, #12302, #12298 Wouldn't it be easier to close them yourself instead of asking other people? Especially since closing them is simpler and less work. You should read http://bugs.gnome.org/server-control.html. But note that the bug tracker seems to be a bit slow currently. The webpages haven't been updated for several days, and yesterday I filed some bug reports that haven't got through yet. Austin
Re: GIF Saving Patch
On Tuesday, 18 Jul 2000, [EMAIL PROTECTED] wrote:
Attached is a patch file for gif.c that fixes a bug that made a dialog pop
up when running noninteractively, which was messing up my scripts.
It was written against 1.1.23 and 3.0.2 of gif.c in plug-ins/common/.
If someone with the right access could run this patch on the source tree
it would probably help someone else out someday.
I've put in the following fix into CVS which should get rid of the
dialog in the non-interactive case.
--- plug-ins/common/gif.c~ Thu Jun 8 18:05:27 2000
+++ plug-ins/common/gif.c Tue Jul 18 21:32:07 2000
@@ -805,7 +805,9 @@
/* Image has illegal bounds - ask the user what it wants to do */
- if (badbounds_dialog())
+ /* Do the crop if we can't talk to the user, or if we asked
+ * the user and they said yes. */
+ if ((run_mode == RUN_NONINTERACTIVE) || badbounds_dialog ())
{
gimp_run_procedure("gimp_crop", nreturn_vals,
PARAM_IMAGE, image_ID,
Austin
Re: undo problems of Image/Colors/ items
On Monday, 5 Jun 2000, Carey Bunks wrote: Yes, I've seen this bug, too. Although it is impossible to undo these operations with C-z, it is possible to undo them by opening the Undo History dialog and explicitly clicking on the preceding strip in the list. After having done this, C-r and C-z work as expected. This might be due to the code which greys out the undo and redo menu options if it doesn't think they're valid. Most likely, this is because the menus aren't being updated after running those tools. Austin
Re: XCF loader for gdk-pixbuf
On Tuesday, 30 May 2000, [EMAIL PROTECTED] wrote: On Tue, 30 May 2000 11:27:37 -0400, Phil Schwan [EMAIL PROTECTED] said: Do you know who all of the copyright holders of that code are? At least myself, Peter, Spencer, and Adam Moss. There are almost certainly others. I can't remember if it was me or Jay Cox which added the resolution property reading/writing code. But if it was me, I hereby give permission for the licence on my portions to be changed to LGPL. Austin
Re: EPIPE
On Friday, 12 May 2000, Marc Lehmann wrote: [1: plugins should have the system default signal handers, not gimp ones] [2: main gimp app should have system default SIGPIPE handler] Point 1: I mainly agree with this. I can't think of a need to hook any signals. Did plugins used to give backtraces when they crashed? I think they did: if so, and people want to keep this functionality, then unfortunately plugins need to hook signals in a similar manner to the main gimp app. However, plugins definitely won't benefit from SIGCHLD handers or ignoring SIGPIPE. If a plugin tried to write to the gimp pipe and gets a SIGPIPE, it's because the main gimp app has died. The plugin should die as swiftly as possible, in this case. Point 2: The main gimp app should ignore SIGPIPE, so that an EPIPE can be generated in a controlled manner to be collected and acted upon by the plugin management routines in plug_in.c With all this vigorous discussion going on, I seem to be a little confused. Can someone (Mitch, Garry?) summarise what the current CVS signal handling situation is, and what changes (if any) are planned? Austin
Re: EPIPE
On Monday, 8 May 2000, Michael Natterer wrote:
Unfortunately this is not the reason why gimp dies on just any aborting
child. Although I 100% agree that SIGPIPE being fatal is the wrong thing
to do. I browsed CVS and Gimp is connecting SIGPIPE to on_signal() since
the beginning of CVS time.
Ok, fair enough. But gimp used to be able to survive its plugins
dying in the past. I'm not sure when this was last working.
There is also an infinite loop using 30% of my cpu time in all cases where
a dying plugin does _not_ kill gimp.
Fvwm2 used to have a bug very similar to this. It turned out to be
trying to do too much processing in some signal hander function.
[Mitch on temp procs not working from plugins]
This seems to be a separate, probably unrelated, bug.
On Monday, 8 May 2000, Tim Mooney wrote:
The SIGPIPE problem is because on_signal is currently treating it as a
fatal signal (see the case on_signal in app/main.c). The on_signal routine
should probably be modified to not treat SIGPIPE as fatal. That should fix
the problem Austin is seeing (that others will no doubt see too). Someone
should investigate the handler in 1.1.19 or earlier, and see what was being
done on SIGPIPE there.
On Monday, 8 May 2000, Tim Mooney wrote:
So why is Austin observing the problem now? I'm not sure.
I'm noting that 2-3 recent bug reports have been related to plugins
crashing (the main reason the bug was filed) but as a side effect, the
main gimp process is also dying. I happened to look into one of these
very briefly, and noted the strange SIGPIPE - on_signal() - SIGSEGV
behaviour.
It does seem
like it's behaving as expected based on the code. The thing to try would
be to use a different signal handler for SIGPIPE, that doesn't terminate
the gimp. Perhaps just ignore the signal and let the plug-in protocol detect
the problem (assuming it can?)?
What happens if we use SIGIGN as the handler for SIGPIPE. That,
combined with using EPIPE from g_io_channel_{read,write}() should give
us everything we need, without needing the overly complex gimp_nanny()
stuff being proposed earlier. Remember: KISS - Keep It Simple, Stupid.
On Monday, 8 May 2000, Michael Natterer wrote:
Nope, it unfortunately has another reason. I can't explain why it used to
work with SIGPIPE being fatal but the diffs of app/main.c show no semantical
changes at all down to CVS version 1.1.
So, maybe we never used to get SIGPIPEs raised before. Maybe we were
just lucky. I still think we need to deal with them properly.
On Monday, 8 May 2000, Tim Mooney wrote:
Austin is also correct that calling printf from the handler is probably
asking for trouble. If a message must be written, some other method should
be found (write *is* ok from a signal handler, but won't using *that* be
fun...).
Hm, I guess printf from a signal handler which aborts the program should be
totally safe
No it is not. Consider a libc implementation where printf takes out a
mutex while appending to the stdio output buffer. If the signal is
delivered while printf has this lock held, any attempt to call printf
again will deadlock. You lose. This situation may occur if you call
_any_ library code you didn't write, so the conclusion is that calling
someone else's code from a signal handler is a very bad idea, unless
you're guaranteed the code is fully re-entrant. Section 10.6 of
Advanced Programming in the UNIX Environment (W. Richard Stevens)
lists the POSIX1 mandated re-entrant functions. Printf, malloc etc
are not in the list, unsuprisingly.
On Monday, 8 May 2000, Michael Natterer wrote:
We should probably ignore SIGPIPE totally and let a more sophisticated
SIGCHLD handler do the work:
- record which processes have been started ("gimp_nanny()")
- on SIGCHLD check if it crashed...
- ...and somehow clean up the plugin's struct and io channels
(and show a proper error message)
The problem with this may be that we need a periodic function doing the cleanup
(just like the shell prints it's "bla exited [SIGwhatever]" message before the
prompt) because we cannot do it from the handler.
OTOH it should be ok to call this cleanup function from two places:
1. whenever read/write from/to a plugin pipe fails.
2. in an idle function.
The "gimp_fork()" and signal handler stuff I proposed during the SIGCHLD
discussion might so the job but it would be much nicer to fix it to work like
before
SIGPIPE indicates a write(2) into the pipe when the plugin has died.
If SIGPIPE is being ignored (or the signal handler returns) then the
write(2) returns EPIPE. If you read(2) from a pipe when the plugin
has died, you get back 0 bytes (ie the usual EOF condition).
Thus, we don't need complex gimp_nanny() schemes. We should SIG_IGN
SIGPIPE. If a write to a plugin causes EPIPE, then we know the plugin
is dead, and we can call some mourn() function to cleanup after it.
If we read from a plugin and get an EOF when we
Re: Bug#10623: [gimp-bug] Signal masks undefined
On Tuesday, 9 May 2000, [EMAIL PROTECTED] wrote: -- Problem description: When compiling, SA_NOMASK is undefined. -- Other comments: Checking a RedHat 6.2 machine indicates this is simply #define'ed from SA_NODEFER. Adding the folowing code to app/main.c and libgimp/gimp.c solves the problem: #ifndef SA_NOMASK #define SA_NOMASK SA_NODEFER #endif Why are we even _trying_ to set SA_NOMASK or SA_NODEFER? SA_NODEFER is a SVR4-ism, SA_NOMASK is as linux-ism, and neither of them are desirable. As far as I understand it, this asked that while the signal handling function runs, the signal being processed is not blocked. This is really quite dangerous behaviour, since the signal handler must now be made reentrant. I don't understand why we're going to quite a lot of trouble to enable a "feature" we really don't want in the first place! Austin
closing bug reports
Please can people put a quick explanation of why they're closing a bug report into the close email. If it's fixed in CVS, a cut-n-paste of the relevant ChangeLog entry that addresses the problem would be cool. Otherwise, just a sentence or two would be enough. Austin
EPIPE
Current gimp (1.1.21) seems to have problems with recovering from any plugin that dies. Things start going wrong when it takes a SIGPIPE while trying to write(read?) to the pipe to the plugin which is dead. Rather than ignoring SIGPIPE, and collecting an EPIPE from the io operation and using this to trigger dead plugin cleanup operations, gimp currently treats SIGPIPE just like any other signal: it's fatal. Unfortunately, while attempting to print out some error message or other, gimp causes a segfault. This might be due to non-reentrant stdio libraries in use, I don't know. According to POSIX, the only thing you're allowed to do is read or write variables of type sigatomic_t. Calling libc funcitions (including printf()) sounds like a recipe for disaster, especially with a non-reentrant libc. This needs some more thought, and I don't have much time right now to look into any more. I'm pretty sure that plugins were correctly cleaned up on their unexpected termination at some earlier stage. The whole point of plugins being separate processes is that a plugin should be unable to cause the main gimp app to crash: if they can then this is a fairly critical bug that should be fixed. Austin
Re: Global Locking for Gimp :-(
On Monday, 27 Mar 2000, Simon Budig wrote: Well - unfortunately this disables "user multitasking" with working on multiple images. Admittedly I dont do this too often, but sometimes it is nice to paint something while waiting for a big image to rotate. (just tested - multiple plugins do work! :-) Is there any chance to do this on an "per image" base without hazzeling too much? I proposed to add per-image locking a while ago, but apparently this wasn't too well liked. I'm can't remember why. There are 2 tricky parts (as far as I can see): A) plug-in.c needs to take out an image lock when starting a plugin operation, and release it on normal (or equally importantly) abnormal plugin termination. B) what happens when acquiring a lock fail? Do you queue the operation up on the lock (hard) or do you fail it (easy)? Austin
Re: Gimp User Installation Dialog.
On Saturday, 25 Mar 2000, Simon Budig wrote: The defaults from gimprc are questionable IMHO. The default imagesize is not specified and defaults to something around 950x760, which is pretty close to my screen resolution. Maybe we should default to something like 300x300 ? The default is deliberately large, non-rectangular, and not a power of 2 so as to provoke as many bugs as possible (eg half-full tiles not being treated correctly, etc). The large size is to provide some incentive for people to optimise screen redraws so we don't get too many. For a proper release, the default size should be made something smaller (256x256 sounds reasonable). Actually, I'd like to make the default resolution something quite different from the screen res. and also non-square, just to make sure people are treating non-square pixels correctly. Eg, 75x150 dpi might be a sensible choice. The default toolbox-layout is IMHO ugly. Should we default to the layout with three columns? Yes. Austin
Re: gimp_image_get_resolution/gimp_image_get_unit/release timetable
On Saturday, 19 Feb 2000, Robert L Krawitz wrote: Pending a general way to scale images separately on X and Y axes, what would be your (collective) suggestions about how to handle an image with different X and Y resolutions? This happens so rarely that I would (for the moment) ignore it. Assume the Y resolution is the same as the X resolution. Yes, this is a bug, but it's what (eg) newsprint does. I need to put proper asymmetry support into newsprint at some stage. The main reason gimp uses separate X Y res is that most file formats include them both, and in order not to lose information it's important to preserve the info. The display code used to update image windows can cope happily with non-square image pixels. Austin
Re: What should I change in Script-Fu scripts?
On Thursday, 17 Feb 2000, Raphael Quinet wrote: 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. Yes. Austin
Re: Some suggestions
On Monday, 14 Feb 2000, Thomas Linder wrote: May well be all three of my suggestions already got discussed: Save Copy As... with its own set of file paramaters including filename This already exists. The menu option is "File/Save as..." Autosave option to save automatically at regular intervalls Shouldn't be too hard to implement, but not while we're in feature freeze. Color History quick select from recent colors, either as popup menu in color section or by creating a new palette (optionally) to be saved - or both perhaps. The can be implemented this as a colour selector dynamically loadable module. Austin
Re: Edit Fill behaviour change?
On Sunday, 13 Feb 2000, Kevin Cozens wrote: So I am not the only one that has the usage pattern with fill listed above. I don't know if its from other graphics programs I have used or just what made sense to me but I expected fill to use the foreground colour. I mean after all, you don't expect the pencil tool to draw with the background colour. Fill in 1.1.15 filled with the foreground colour. Its a bug, out and out, and should be fixed. shift-click in 1.0.x fills with background colour. ctrl-click in 1.1.15 fills with background colour. I suspect its this logic which is missing a "!". For the sake of a 1-char edit, I think we can safely fix it. Won't this be biting scripts etc too? Austin
flatten is too obscure
I just spoke to someone who tried to get rid of the alpha channel on their image before saving it (his gimp was pre-export stuff). It's true that, even though I knew what I was looking for, it took me a while to find the flatten option. The deceiving thing is that while "Image/Image/Alpha/Add alpha channel" exists, the corresponding "Remove alpha channel" is not on the same menu. This is deeply confusing. You have to go to the LC dialog to get the "flatten" option. And only then, if you know what flatten does, will this make sense. I suggest adding a "Remove alpha channel" option to the Image/Image/Alpha/ menu, which just calls the flatten routine. Yes, I know this should be mostly solved with the export stuff, but there are still times when you want to get rid of an alpha channel. Austin
Re: Problems with gimp-1.1.17?
On Saturday, 12 Feb 2000, Sven Neumann wrote: [well known cursor pos overwriting bug] This is not a bug in gimp but in the gtk theme you are using. Therefore it is not our problem. Maybe we should make it our problem. I think that given the number of people who are bitten by this, is there nothing we can do in the gimp to work-around the GTK problem? If only to reduce the number of bug reports. Austin
loading EPS files
Hi,
One problem that people mention on comp.graphics.app.gimp quite
regularly is that gimp says "load failed" on some EPS files.
This happens when the EPS file doesn't have a "showpage" command on
the end of it.
Actually, EPS files probably shouldn't use an explicit showpage, since
they're supposed to be embedded. But users like to be able to just
"lpr foo.eps" and have some output generated, and Adobe's Encapsulated
PostScript File Format Specification (version 3.0, 1 May 1992) says
that showpage is allowed (see page 10, section "Redefining showpage").
So in a bid to reduce the number of confused users, I think gimp
should continue to produce EPS files with a showpage at the end (and
rely on the embedding application to correctly define away showpage).
However, this still leaves the question of how to correctly load an
EPS file. Currently, we just present the file to gs pretty much
verbatim (ie, with no embedding). This works only for EPS files that
have an explicit showpage in them. Some don't, eg those produced by
Aldus Freehand 8 on Mac.
The correct way to get gs to render the EPS file is to provide it with
a prologue, the file itself, then finally an epilogue.
The reccommended code (again from Adobe's EPS standard, pg 17), is:
1 /b4_inc_state save def
2 /dict_count countdictstact def
3 /op_count count 1 sub def
4 userdict begin
5 /showpage { } def
6 0 setgray 0 setlinecap
7 1 setlinewidth 0 setlinejoin
8 10 setmiterlimit [ ] 0 setdash newpath
9 /languagelevel where
10 {pop languagelevel
11 1 ne
12 {false setstrokeadjust false setoverprint
13 } if
14 } if
15 EPS file goes here
16 count op_count sub {pop} repeat
17 countdictstack dict_count sub {end} repeat
18 b4_Inc_state restore
Line 1 saves the memory arena, so it can be later restored by line
18. We don't need this, since we don't need to do further processing
after the EPS file.
Lines 2, 3 save the stack sizes for operand and dictionary stacks, and
lines 16 and 17 then pop any extra crap the EPS left lying around on
those stacks. Again, we don't need that, but could be vulnerable to
malicious EPS files that deliberately popped more than they push. Not
much we can do about that, short of starting with an empty stack.
Line 4 makes sure the EPS file puts any temporary defs into the user
dictionary, rather than any application one in use. We should
probably do this, not so much to protect our dictionary (we don't
care if it gets trashed) but more so that the topmost dictionary is
large enough for the EPS file's use.
Line 5 redefines showpage to be harmless, so the EPS cannot output
stuff at inopportune moments.
Lines 6 to 8 restore the graphics state to the default. gs should
initialise to this anyway, so we don't need this. Lines 9 to 14 to
the same for portions of the graphics state only present in PostScript
level 2 interpreters. Note that "languagelevel" is itself a level 2
feature, hence the rather convoluted way of using it.
In addition to this, we need to add:
4.5 /saved-showpage /showpage where pop /showpage get def
to squirrel away a safe version of showpage before blowing it way,
and:
19 saved-showpage
to actually print the EPS out. This last solves the problem with EPS
files not loading correctly. (Hmm, actually, might need to put the
saved-showpage in a fresh dictionary to make sure that malicious EPS
code can't redefine saved-showpage).
Now, the only question remains how to add this harness code around the
EPS we want to load. The simplest is just to copy the EPS to a
temporary location, sticking the prologue and epilogue on as we go.
This is tedious, since people often want to load large bits of
PostScript, and we don't want the overhead (in terms of both time and
space) of copying the thing.
Luckily, gs allows multiple files to be listed on the command line.
So, where's a good place to put a couple of plugin-specific data
files, namely: eps-loader-prologue.ps and eps-loader-epilogue.ps ?
Austin
(phew)
Re: undo.c [i18n problems]
On Thursday, 13 Jan 2000, David Monniaux wrote: #: app/undo.c:2874 msgid "FS to layer" msgstr "FS vers calque" #. ok #: app/undo.c:2875 msgid "gimage" msgstr "gimage" #: app/undo.c:2876 msgid "FS rigor" msgstr "" #: app/undo.c:2877 msgid "FS relax" msgstr "" What do these options mean? FS is floating selection. I agree, the messages are not exactly very clear. "FS to layer" is what happens when you convert a floating selection into a full, proper layer. "gimage" is a pretty non-descriptive catch-all undo type used in many places, mostly when pushing an entire tile manager on the undo stack. Ideally, we'd go round all the places "gimage" is used, and give a more meaningful undo type (eg paint or fill or whatever). Ditto for "gimage mod" and "paint core". "FS rigor" and "FS relax" are used in pairs to temporarily hide the floating sel and display what's under it (eg during floating selection moves). They should never actually appear as undos by themselves, but as part of a larger group. I don't think there's any need to translate them. In my opinion, floating selections should be taken out and shot, since we now have proper layers. They cause much confusion to users, and require lots of special-case code. Austin
Re: Thanks (Re: Gimp splash images)
On Sunday, 9 Jan 2000, Marc Lehmann wrote: On Sun, Jan 09, 2000 at 05:08:26PM +0100, "Guillermo S. Romero / Familia Romero" [EMAIL PROTECTED] wrote: that means quality loss (original where 256 colors only?), and I am looking Yes, quality loss in many cases... for the PPM, not derivatives. In the files dir I saw a message saying that You can get the ppm files by checking out the relevant cvs revision of that file (tigert's page even mentions the revision numbers) I vote for releasing gimp 1.2 with Tigert's 1.4 "floating balloon" splash screen. Austin
Re: Review and better .......
On Saturday, 13 Nov 1999, Olof S Kylander wrote: The above statements leads to the conclusion that you often need to zoom in out quickly. What's wrong with the "+" and "-" keys? I used them exclusively to control the zoom level, and find it quite convenient. It would be even better if the zoom also panned to center the zoom around the location the mouse cursor is over then the key is pressed. I'm not sure how to go about plumbing that in, though. Austin
Re: Clean up and Re: Help System
On Friday, 12 Nov 1999, Sven Neumann wrote: Here is my list of minor things to clean up and make better (Without breaking the freeze). First the list and then the discussion below it. YES!! I also like the new layout. It seems more consistent. I'm not sure about leaving out all the script-fu's. I'm worried about people complaining that stuff that always used to be there isn't there anymore. Also, is there really a need to group scripts by the interpreter they run under? I don't think so. You wouldn't put shell scripts in /usr/bin/sh-scripts/, but perl scripts in /usr/bin/perl-scripts/, would you, so why make the distinction in gimp? If the script works, a user shouldn't need to know which language it's written in. Austin
Re: Help System
On Wednesday, 10 Nov 1999, Sven Neumann wrote: - Grab GtkXmHtml seperately. This is difficult at the moment, but I was told that the gEdit application offers a seperately bundled one. If gEdit needs GtkXmHtml, and so does Gimp, does this not mean there's a real requirement to make GtkXmHtml a standard part of libgtk? Maybe the time has come to fold GtkXmHtml into the main library. We should talk to the gtk people. Tim, Owen? Austin
Re: [patch] gimp-drawable-get/set-pixel bugfix
On Wednesday, 10 Nov 1999, Tamito KAJIYAMA wrote:
I found a bug that gimp-drawable-get/set-pixel swapped the
specified x and y coordinates when getting/setting a pixel.
Ouch!
gimp-drawable-{get,set}-pixel is such a slow API not many people use
it, I reckon. That's probably why it's taken so long to crawl out of
the woodwork.
--- drawable_cmds.c.orig Thu Oct 7 04:55:27 1999
+++ drawable_cmds.c Mon Nov 8 17:38:15 1999
@@ -1057,7 +1057,7 @@
x %= TILE_WIDTH;
y %= TILE_WIDTH;
This is another bug - if we ever go to non-square tiles this will
break. It should read:
x %= TILE_WIDTH;
y %= TILE_HEIGHT;
Thanks for bringing this to our attention, good work.
Austin
Re: modules cleanup
On Monday, 8 Nov 1999, Asbjoern Pettersen wrote: The GIMP's modules for OS/2 need some extra handling. It's copied into the 3-4 modules C files and it's also not updated. I want to clean up this code. The same problem was occurring on Solaris2. Yosh has now tweaked some of the libtool options so that it should now work. Do these fixes for Solaris2 also fix the problem under OS/2? I suggest to create a new file called modregister.c and put all the "register" things there. Modules have to link the new file. The will be no new features only a cleaner design. I'm all for a cleaner design. Ideally we should be doing the same thing for all architectures, rather than using nasty #ifdefs everywhere. Also, still to be fixed with the module code is a version check as suggested by Tim Janik a long time ago, and unloading modules from the idle loop (which should make the perl module self-unloadable). I'm not particularly happy with the OS/2 solution, it seems a little ugly, but I'm not sure why exactly I don't like it. Austin
Re: Re: Tile Cache Size
[Lots of people writing barking mad things about tile swapping] Look, you're all missing the point. Gimp does it's own tile swapping not because it wants to control the layout on disk. As some of you have pointed out, this is futile. The only reason to swap a tile at a time is to do with controlling how far apart in memory neighbouring pixels are. Consider a very wide image. If it is stored as a large linear array in memory (possibly paged by the OS to an OS-managed swap file), then the common operation of consulting a pixel above or below the current one results in needing to skip a large number of bytes through the linear array. This results in poor CPU cache performance. So, we use a tiled memory layout. Once the data is in a tiled representation in memory, there seems little point in converting it into a linear buffer before writing it to disk. This would certainly take more time than it would to just hand the data to the OS. Now, the size of a tile cache (ie number of tiles we'd like to be able to access as speedily as possible) should be a little over the number of tiles it takes to cover the width of the image. This is so that filters which iterate over every single pixel from left to right, top to bottom, perform better on the horizontal boundary between adjacent strips of tiles. Consider a 3x3 convolution (let's say a blur matrix). When the center of the matrix is at the top of the second row of tiles, the top of the matrix needs to reference the first row of tiles. It is helpful for performance to have this top row available. Which means caching ceil(img_width / tile_width) + 1 tiles. And gentlemen, this is not rocket science. It's what undergraduates are normally taught in their basic "OS Functions" lectures. The gimp is a good example of why application-specific paging control can be a performance boost. Now can we drop this silly subject, please? Austin
