Re: Bug tracker
Nick Lamb wrote: Is there some reason why people who fix bugs from the bug-tracker (and even note that fact in their CVS commit) don't log a close, or even a "probably fixed, please test..." message to the appropriate bugs? If it's just lack of time, I understand but I wondered if there was some other reason...? Nick. I suspect everyone is busy. I also fear the bug tracking system suffers from version latency bloat. A number of bugs that have been resolved are reported again as new items. Many people work with the semi-stable developer's releases, and these lag CVS to varying degrees. And while Xach's form has a link to the current Changelog, it is not always easy to relate terse language in the ChangeLog with observed behavior in a less-than- current developer's releases. Anyway, the following open items, I believe, can be regarded as resolved or near-resolved and I vote for their closure; for the most part they are related to patches I've supplied; I have not been able to reproduced the original behavior since the application of related patches. #2202: MapObject causes gimp to crash drawable_cmds CVS-1.27 Nov 1 1999 (neo) * app/drawable_cmds.c * tools/pdbgen/pdb/drawable.pdb: applied (a modified version of) a patch from Garry R. Osgood [EMAIL PROTECTED] that should fix bug #2202 and problems with the Warp plug-in. Since then I have not been able to reproduce the crash; others are welcome to test. #2261: [gimp-bug] Offset causes Gimp crash #2382: offset sometimes crashes gimp channel_ops.c CVS-1.23 Oct 24 1999 (neo) * app/channel_ops.[ch]: applied a patch from Garry R. Osgood that seems to fix bugs #2261 and #2382 (crashes when using offset). A few more changes made the dialog actually work... Since then I have not been able to reproduce the crash; others are welcome to test. #2414: [gimp-bug] Moving Floating Selections Leaves Artifacts #2879: [gimp-bug] Droppings left when moving floating layer Related to bug was reported by SHIRASAKI Yasuhiro [EMAIL PROTECTED] in #2166: "[gimp-bug] texttool with guides spreads garbage." which was closed by Zach Beane - MINT [EMAIL PROTECTED] at Yasuhiro's request. Upgrade to GTK+ 1.2.5 solved the artifiact problem. I upgraded to GTK+ 1.2.5 and that removed the artifacts I was seeing. I sent a close request to [EMAIL PROTECTED] Seth Burgess submitted #2879; when he upgraded to Gtk+ 1.2.5, his observed artifacts went away as well. #2515: [gimp-bug] Layer mask previews are not updating #3059: [gimp-bug] Renaming Auxiliary Channels (such as saved selections) I believe likely related to #2384 [gimp-bug] Doubleclicking on selection masks/quickmasks doesn't work. channels_dialog.c CVS-1.58 Oct 16 05:50 (mitch) * app/channels_dialog.c: applied gimp-gosgood-991011-0.patch, so double-clicking on the channel widget pops up the attributes dialog again. [EMAIL PROTECTED] reported #2515; in separate e-mail he told me that he was working with a pre-patched version at the time. I do not know if he has upgraded and retested. [EMAIL PROTECTED] reported #3059; I sent e-mail suggesting the connection with #2384 and requested that he check again with a later version; I have not heard from him. Be good, be well Garry Osgood
Re: Modifier keys
Sven Neumann wrote: Hi, well, we already agreed that the modifier keys need some rework. I volunteer to do the job, but I don't want to start hacking before we have discussed the issue and found a suitable solution. So, to start the discussion, here's a list of the current state. Many thanks to Sven Riedel who helped to create this list: snip.. Also, please inform me if this is list is wrong or incomplete. Salut, Sven Nice list. Let's make it messier. There is also the (unwanted) relationship between Preferences Categories/Interfaces/Image Windows. "Disable Cursor updating" which disables all select modifiers as well. [see #2568: [gimp-bug] key modifiers not working for selections with cursor update off] I'm tasking myself to address this bug, probably this weekend. Be good, be well Garry
Re: Tile cache leaking?
Nick Lamb wrote:
Further to my original observations, here is something more detailed:
Gimp is set to ~24M tile cache, on a 64Mb machine with ~64Mb of swap
The TIFF is enormous (see previous post for exact dimensions) and as a
naive RGB array (3 bytes per pixel) would use ~210Mb of space
Stage --- Size of gimpswap
Fresh gimp, no images N/A not yet created
Begin loading TIFF 10Mb almost immediately
50% loaded 98Mb
99% loaded 196Mb (just as TIFF loader exits)
Starts displaying 250Mb
50% complete display 380Mb
100% complete display 508Mb
Then, as tigert says, the Gimp continues to trickle data into the swap
file for some time, but only a few Mb per minute.
The TIFF loader created (by my estimate) 210Mb of tiles. There are now
508Mb of tiles on my disk. What is in the 300Mb of tiles which were NOT
created by the TIFF loader?
Suggestions of how to find out are welcome, but a fix is preferred :)
Nick.
All
I've been observing irregularities in the maintenance of tile accounting
in
tile_manager.c, tile.c tile_cache.c and tile_swap.c. It appears with
Gimp 1.1.13 (To ChangeLog CVS 1.1865) that global state variables
that account for tiles being actively used ("tile_active_count", which
counts those tiles which have been locked through tile_lock(), but
not released through tile_release()) and the number of bytes attributable
to written-but-not-saved-to-swap tiles (cur_cache_dirty) often
become abnormally high. I suspect there may be more tiles being
hoarded in memory than the Gimp needs, but I need to do more
work before confirming these suspicions and placing them on a
technical footing. These I will save for a later post, which will be
slow in coming; this is my first waltz through tile cache and swap code
and there are a good many enchanting interrelationships.
The ballooning of tiles reported in Nick Lamb's post seem approximately
correct, "behaving as designed", from my prospect. Many of you, I gather,
are familiar with the TileManager structure defined in tile_pvt.c and
visible mainly to tile cache and swap internals and kept opaque elsewhere.
I am inclined to think of it as a low-level tile container or "tile set".
These objects can roughly map to higher level constructs like "Layers",
and
"Channels" (i.e., one Tile Manager instance for each higher level
construct extant
in a particular image). The mapping isn't exact; the Gimp image
structure maintains a set of tiles for (1) the selection mask, (a gray
scale
one byte per pixel) (2) a so-called "projection" tile set to receive a
composite
of the individual layer images (1, 3, or 4 bytes per pixel depending on
the
kind of image) (3) and a "shadow" tile set for working image changes
behind
the scenes for subsequent merging with the "real" image. Additionally, the
Undo save set employs one Tile Manager per save set.
The Gimp does not naively fully populate tile sets at the starting gate;
rather
it tends to instance "empty" tiles (no associated image data) so that Tile
Managers
are fully populated with tiles, but the tiles themselves do not get image
data until there
is a real need to save an image component. A tile manager in an undo save
set
will have mostly unpopulated tiles if a painting operation scribbled over
only a
small region.
Even with this "just-in-time" approach in place, certain tile sets
perforce must fatten
to full extent in fairly short order. If "one tile unit" or TU represents
the product
of an image width and height in tiles (sixty four pixels per tile), then
this kind
of accounting seems reasonable for a routine image load:
Image Creation
Selection mask0.25 - 1 TU*
Open File:
File loader populates:1 TU / Layer
Realize Image:
Projection 1 TU
Most any image-wide special effect
Shadow 1 TU
Undo Save sets (guesstimate) 0.1 ~ 1 TU/Save set
*TU size varies in terms of absolute bytes, depending on whether an image
requires 1, 2, 3, 4
bytes per pixel, but the selection mask is always 1 byte per pixel, hence
the range in demand
of a selection mask TU with respect to a full image.
So an internal representation of an image may be on the order of three
times the size of
an on-disk representation in fairly short order. We may not like this
behavior, but there
doesn't seem much that can be fixed to improve it.
On the other hand, there are hooks in the tile manager structure so that
tiles (which are
expensive to image) may be used by more than one tile manager. (TileLink
structure).
Conceivably, a slightly altered copy of a Layer can "mostly" share tiles
with the Layer
it had been copied from. I've not seen any examples of this actually
happening in the trials
I've run this weekend, but these trials have mostly
Re: When will Gimp support JPEG2000
Max Moritz Sievers wrote: Hello, is there a plan to support JPEG2000? In case you do not know yet what JPEG2000 is, here is an article from ZDnet: JPEG 2000 to give the Web a new image Next version of graphics file format might even dazzle the pros. By Luisa Simone, http://www.pcmag.com/ April 22, 1999 10:51 AM PT snipped marketing fluff stuff...> More important, it abandons DCT compression in favor of wavelet compression. Wavelets are mathematical expressions that describe an image in a continuous stream, and so avoid the blocky artifacts associated with DCT compression. Interesting.The article contains a self referential example. This appears to be the wavelet concept stripped of all but the lowest frequency components. But perhaps the chosen basis is wanting; the concept seems blurred by signal cross-talk. This ability to uncompress multiple resolutions on the fly can also pay big dividends in print production workflows. Imagine a single small file, easy to store and transport, that when partially uncompressed is suitable for relatively low-resolution screen display and local proofs, but when fully decompressed contains enough resolution for final output. But for the file to be small, high frequency components in the data set have already been stripped, and these will not be available for further "uncompressing" Representing a data set using any number of possible wavelet bases does not magically fit 1.2 gigabytes of data onto 1.44 megabyte floppy diskettes. Using a wavelet basis to separate data into spatially and spectrally localized "windows" is not inherently a compression technique. It is related to compression techniques in important (but tangential)ways in that using suitable wavelet bases simply allows us to reorder a data set so that information can be readily extracted in terms of how rapidly it it changes relative to other information in the data set. If we present such reordered information as a serial stream, in low-to-high frequency order, this gives rise to compression tactics where one can "cut-off" the data flow at a point where the upstream data are at higher resolutions than what the downstream agents (printers, whatever)can readily reproduce. If we're particularly smart about choosing the correct basis (somewhat dependent on the nature of the data set), then the cut-off point can be at a juncture where most of the data are still upstream, and the downstream agents have reproduced something with fidelity no better than what they are capable of producing anyway. snipped marketing fluff stuff...> Plug-in possibilities JPEG 2000 does have one drawback: The specification won't be finalized for another year... snipped marketing fluff stuff...> Which answers your question. Without established specifications in the public domain, its manifestly difficult to write a plug-in that has a prayer of being compatible. And as as an open source initiative, any of the proprietary solutions Ms. Simone is essentially marketing for these companies is not an option for Gimp. with regards Max Moritz Sievers. Ithink wavelets are an extraordinarily interesting field of study and there is a wealth of useful ways they can be applied to things Gimpish, in a public, open source kind of way. Whether in fact wavelets in general (or JPEG2000 in particular)find their way into Gimp depends on whether advocates feel compelled to write something useful (preferably post-freeze ;). Iinvite you to do so yourself, but mildly suggest you equip yourself with information sources that preserve a few more octaves of frequency components than what Luisa Simone feels her readers are capable of understanding. Start with Amara's Wavelet Page and follow the links from there. Be good, be well Garry Osgood
Clone Tool Source Cursor
Hi, all
To address bug #2184: [gimp-bug] Clone tool samples "sample from"
cursor,
creating artifacts, I'd like to change the cursor behavior in
(what I think) is an unobtrusive way.
When the sampling cursor and destination cursor are within one brush
width
of one another, I'd like to supress the generation of the sample cursor.
Currently the sampling cursor is displayed at all times between button
presses and
releases, even when the two cursors are in close proximity to one
another.
#2184 reports that when this is the case, artifacts are generated.
1. The artifacts arise from the original design of the sampling cursor.
It is not
a hardware cursor, but generated through gdk_draw_lines() writing
directly to
the window. These lines simply invert the hardware colormap, so that
subsequently
overwriting these lines is the same as not writing them at all.
2. The original design depended on maintaining a correct phase among
(a) overwriting
the sampling cursor to make it "disappear" (b) writing clone pixels,
then (c) writing
the sampling cursor in its new location, making it "reappear" (a), (b),
and (c) would
then repeat on each mouse motion event.
3. Extensive modifiations and improvements to gdisplay_flush() and
related functions
have effectively changed this sequence to (a)(c)(b), the actual writing
of clone
pixels are buffered and their writing to screen are deferred. This does
not give rise
to artifacts when clone pixels writes are quite far from the sample
points. The erasing
(a) and rewriting (c) strokes flash the sampling cursor off, then on, in
a pointless
but unobtrusive way. But when clone pixels write very near to the sample
point,
(b) partially overwrites the image created by (c), a partial
"untoggling" of inverted
pixels occurs. The next, so-called "erasing" step (a) properly reverts
uncloned pixels,
but improperly inverts cloned pixels. This leaves a partially written
sampling cursor
behind, an artifact.
4. Since artifact generation occurs when the sampling and "real" cursor
almost coincide,
It seems to me that simply supressing the generating of the sampling
cursor is a more
effective means of dealing with bug #2184 than attempting to restore a
delicate phase
relationship through gdisplay buffering code. This alteration does
change user
interface semantics, so I wanted to query the group before committing
the change.
The attached patch is a not-fully-tested implementation that illustrates
the approach.
It is intended to be applied to gimp/app/clone.c, CVS version 1.34
[1999, Nov 17 04:37]
Awaiting opinions, or suggestions to alternate approaches.
Be good, be well
Garry Osgood
--- gimp/app/clone.c Wed Nov 17 04:37:39 1999
+++ gimp/app/clone.c-patch Fri Dec 17 20:37:08 1999
@@ -287,7 +287,6 @@
{
offset_x = src_x - dest_x;
offset_y = src_y - dest_y;
- first = FALSE;
}
src_x = dest_x + offset_x;
@@ -299,6 +298,8 @@
}
draw_core_pause (paint_core-core, active_tool);
+ if (!(paint_core-state GDK_CONTROL_MASK) first == TRUE)
+first = FALSE;
break;
case INIT_PAINT :
@@ -324,10 +325,15 @@
case FINISH_PAINT :
draw_core_stop (paint_core-core, active_tool);
if (clone_options-aligned == AlignNo !first)
- {
- src_x = orig_src_x;
- src_y = orig_src_y;
- }
+{
+ src_x = orig_src_x;
+ src_y = orig_src_y;
+}
+ if (clone_options-aligned == AlignNo)
+{
+ offset_x = 0;
+ offset_y = 0;
+}
return NULL;
break;
@@ -437,6 +443,27 @@
paint_core_free (tool);
}
+gboolean
+clone_proximity_check(PaintCore *paint_core)
+{
+ /* Render clone tool source-of-copy cursor */
+ /* unless its position is within the greater */
+ /* of x or y brush mask extent. */
+ /* Address bug 2184 [EMAIL PROTECTED]*/
+
+ if(first) return TRUE;
+ else
+ {
+int dx2 = offset_x*offset_x;
+int dy2 = offset_y*offset_y;
+int pr = ((paint_core-brush-mask-width
paint_core-brush-mask-height)?
+ paint_core-brush-mask-width :
paint_core-brush-mask-height) + 2;
+
+pr *= pr;
+return (dx2 + dy2) pr;
+ }
+}
+
static void
clone_draw (Tool *tool)
{
@@ -446,12 +473,15 @@
if (paint_core-core-gc != NULL clone_options-type ==
IMAGE_CLONE)
{
- gdk_draw_line (paint_core-core-win, paint_core-core-gc,
-trans_tx - (TARGET_WIDTH 1), trans_ty,
-trans_tx + (TARGET_WIDTH 1), trans_ty);
- gdk_draw_line (paint_core-core-win, paint_core-core-gc,
-trans_tx, trans_ty - (TARGET_HEIGHT 1),
-trans_tx, trans_ty + (TARGET_HEIGHT 1));
+ if (clone_proximity_check(paint_core))
+{
+ gdk_draw_line (paint_core-core-win, paint_core-core-gc,
+trans_tx - (TARGET_WIDTH 1), trans_ty,
+trans_tx +
Re: [gimp-devel] Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
Simon Budig wrote: Sven Neumann ([EMAIL PROTECTED]) wrote: How about some comments for feature triage? There are some features in Gimp 1.1.x which are buggy or unusable, yet stay the same for weeks snip... Ill try to do something on the tool in the next time, but as always I cannot promise anything. The first thing would be the API cleanup, the second thing would be to prepare the conversion to a selection, but bound to some strange events, since we need the Integration for the right way to do it. If there were one feature of Simon's path tool that I would like to have automagically appear in the Integrated path selection tool, it is the ability to manipulate the curve by "pulling" on it directly. it is a very pleasant way to adjust curves. It's effect needs to be adjusted near control points; bezier basis functions associated with the first and fourth control points grow expotentially to unity, so manipulating Simon's path near control points can be a tad exasperating. Be good, be well Garry
Rescuing Paths (Re: Triage!...)
Simon Budig wrote: Garry R. Osgood ([EMAIL PROTECTED]) wrote: snipped... bezier basis functions associated with the first and fourth control points grow expotentially to unity, so manipulating Simon's path near control ^ infinity? It waves at unity on its way to infinity ;) Though, strictly speaking, since the mapping is from the parameter space interval [0,...1] to the real line, the behaviour of the basis functions are moot for a parameter t 0 or t 1; the bezier basis functions partition unity (they always add up to one), and, at the zero boundary, the basis function scaling the first control point is just unity, the functions scaling the other points vanishing, which is why I had unity, not infinity, in mind. We can be both right; depends on how picky one wants to be in restricting the domain. I did look at the two path implementations last evening; I'm not particularly familiar with the code, so a clear integration path did not suggest itself. My schedule is reasonably light for January, will get hectic after, and though I've tasked myself primarily to bug detection/fixing, if there's a piece of this you think you can subtask, let me know. Timing, however, is very tight. If we keep our collective promise of releasing in March 2000 (like, March 31, 2000) then we only have 81 shopping days left. Be good, be well Garry Osgood
Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
Sven Neumann wrote: I don't see your problem. I do get my errors in the error-console. All that's missing IMO is a way to set the error_console as the default error_handler in the preferences. That should be easy and is definitely worth the effort. Nick Lamb: Well, I think you hit the nail right on the head, I have seen this nice Error Console dialog, and never found out how to get my errors reported there. From your description it sounds like that's just some plumbing. Sven: 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. I also see this error console, but never see anything *in* the error console. g_message() dribbles to dialog popups. Enlighten me: what sort of plumbing is involved? I've turned a couple of spigots, nothing comes out of pipes. Be good, be well. Garry Osgood
Re: Discovered paste to mask bug
Carey Bunks wrote: Hi, I'm using the CVS gimp 1.14 corresponding to the line 2000-01-08 Michael Natterer [EMAIL PROTECTED]> as the top entry in the Changelog, and I'd like to report a bug. The bug I've discovered is that it is no longer possible to paste from the default buffer to a channel or layer mask. Thus, the operations: o Copy a layer to the default buffer using Ctl-c, o Make a layer mask (and make sure it is active), o Paste from the default buffer using Ctl-v, and o Anchor the resulting floating selection by clicking on the Anchor button does not place the paste into the layer mask! The float just mysteriously disappears. Same behavior occurs when trying to paste into a channel mask. snipped...> Cary, I believe this corresponds to bug #5045 [Cutting from Layer and Pasting To Channel Fails] of which a variety of fixes were placed into CVSby Sven and myself around 01/11 and 01/12. While the bug discusses Layer -->Channel pastes, the underlying problem generally affected RGB -->Grayscale translations and would affect pastes to masks as well. Please let us know if what you see persists in newer versions. Thanks. Be good, be well Garry Osgood
Re: Thanks (Re: Gimp splash images)
Adrian Likins wrote: snipped... the baloon, the rocket, or the new one are my faves for 1.2. I really like the newest one. Nice work. Adrian The magical quality of 1.4 is hard to beat. It reminds me of Bilbo Baggins: "The road goes ever onward..." 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. GRO
[Fwd: Re: Startup - duplicate PDB messages? - 1.1.15]
Marc Lehmann wrote: On Sat, Jan 15, 2000 at 06:21:35PM -0500, Glenn PM [EMAIL PROTECTED] wrote: Did you remove your old gimp installation? The error messages below are probably caused by left-over plug-ins in your $PREFIX/lib/plug-ins Yes I did. I still think this is the only way you could get these messages. Maybe "make uninstall" did not work for some reason? The mos tprobable fix, then, is to rm `gimptool --prefix`/lib/gimp/1.1/plug-ins/*.pl gimp_image_base_type_with_alpha (gimage) snipped... Glenn also reported: "I also did a make uninstall on the old version after I got a good make on the new..." Was "make uninstall" invoked on Makefiles generated by the 1.1.15 package? These are not likely to be symmetrical with those generated by 1.1.12, and, I don't believe, can be expected to clean up after what Makefiles generated under 1.1.12 produced. Be good, be well Garry Osgood
Re: Addition of new plug-ins
Sven Neumann wrote: Hi, tonight two new plug-ins were checked into the tree... snipped: new plugin descriptions... A lot of work has been put into making the plug-in interfaces consistent, cleaning up the code and adding gettext support. As long as these new plug-ins don't adhere to the new standards, I see no chance to get them included. I know that I have added new features after the freeze myself, so if someone thinks that these new plug-ins are really that useful and wants to take care of them, please try to persuade me... Otherwise I vote for not accepting them now. Salut, Sven No persuasion here. To be fair, I don't recall a posting enumerating what these 'new standards' may be; if I'm wrong, apologies and please correct me. If one is wanting, your list of (1) consistent interface (2) coding standards (GNU or close relatives) (3) Internationalized is a decent start. That said, I've always thought (by some unfounded supposition) that plug-ins would generally begin life as an announcement here (Paul F Harrison [EMAIL PROTECTED] as a case in point) and in gimp-user, and the author would place the effort in the registry - perhaps, or perhaps maintain a download place on his or her own page. This, I supposed, would be the characteristic state of the the vast majority of plug-ins. Relatively few - that do one thing of common utility very, very well or which work very well in combination with other very adaptable plug-ins - would migrate into a standard Gimp distribution. To these qualities, one adds (1), (2), and (3), above, and - in the spirit of the Plug-in Maintainer's List - acquires (4a) either an author engaged in active support or (4b) a maintainer willing to serve as author surrogate. The presence of these last two attributes, I feel, serve as a harsh, but fair, barometer of whether a plug-in warrants inclusion in a core distribution. For if an author becomes too busy to further maintain a plug-in, and the plug-in fails to enthrall the active interest of a maintainer, then perhaps the plug-in is neither one of common utility, or particularly useful in conjunction with other plug-ins; it fails to capture a community of supporters, and, I contend, its absence from the standard Gimp distribution won't be sorely felt. In that light, a plug-in should find its way into CVS only after its utility has engendered a supporting community, so that its CVS inclusion is a foregone conclusion and not an incidental act of happenstance. My two U. S. cents. Garry Osgood
Re: Call for Layers Channels Testing
Tino Schwarze wrote: After all, I got around to test it. Though the patch got a bit messed up by sending it via mail, I managed to apply it. It works. At least, I checked that selecting a layer within LC does indeed change the active layer indicated within the image. Ibelieve the patch fixes only one of a number of possible ways that suspend_gimage_notify can get out of sync, so I'm not closing the related bug reports; see http://idt.net/~gosgood/gimp-patch/patch04.html, I believe you may see this again, particularly running scripts. Keep us posted by submitting any suspicious behaviour to http://www.xach.com/gimp/news/bugreport.html Thanks for your help. Be good, be well Garry Osgood.
Plugins at Sourceforge
In ChangeLog : Fri Jan 28 01:16:35 CET 2000 Marc Lehmann [EMAIL PROTECTED] * PLUGIN_CVS: updated to give Kevin Turner write access to the maze plug-in (therefore, the maze plug-in is no longer managable within the gnome cvs server. If you have any comments/suggestions...) Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating where "authoritative source" resides? Be good, be well Garry Osgood
Re: Edit Fille behaviour change?
Tom Rathborne wrote: I just noticed this new CVS entry: Fri Feb 4 18:27:16 CET 2000 Stanislav Brabec [EMAIL PROTECTED] * app/global_edit.c: edit_fill with foreground, not background. snipped... I don't think it's a bug, and making this change will suddenly render all of the GIMP books completely obsolete! Ok, so GIMP 1.2 will make the books obsolete anyways... but changing such a basic core UI thing seems like a bad idea to me. DrBronner Revert, revert, ok! /DrBronner Indeed, some of the 1.2 - revised books are well into pre-press and some are out in the market. These books suffer too. From "Gimp - Essential Reference (Covers GIMP 1.2, GTK 1.2 and Script-Fu" by Alex Harford, published by New Riders (Page 32): "Clear and Fill are simple tools for working with selections and entire layers... discussion of Clear omitted ... The Fill ([Ctrl+.]) operation adds paint to the current selection. The selection is always the *background* color even if there are layers or an Alpha channel. emphasis mine Fill is therefore useless when working with a flat image without an Alpha channel because it has the same effect as Clear..." So in a small way, a GIMP reference has been rendered less accurate. The issue of whether or not this change is more sensible is not the point; the point is that the User Interface is special ground; there is a lot of external dependency on long-standing behaviour remaining constant. One should not change it without first posting some kind of proposal here - especially in this feature-freeze period where many people are working hard to get documentation synchronized with the Gimp. My two U.S. cents. Garry Osgood
Re: Removing pencil?
Sven Neumann wrote: snipped... I'm all for removing the Path Tool, Agreed: In my opinion, there is just too much work to integrate for March 31 (56 days away and counting). the Xinput Airbrush Agreed: I've just got Wacom Intuos working with GTK+/GDK on SGI, and on this platform using the Xinput Airbrush with the tablet crashes Gimp nearly every time. and and merging Pencil and Paintbrush. Agree in concept, as part of a more unified paintbrush for 1.3, but I vote that we do not remove the pencil for the 1.2. About half the people I speak with think of it as a "hard-edge paintbrush" and their instincts have them grab the pencil whenever they want to do "precision" drawing. I also agree with Nick Lamb in that our energies ought to be spent in ferreting out unusual behaviour, logging bug reports, and fixing those that are tractible, given our various skills and talents. I believe this effort is more important than rescuing tools that just aren't done yet. Just this morning I discovered (1) Fuzzy select works fine with core pointers but with when the tablet is being used as a pointer device, Fuzzy select can run for minutes, and its not unusual to find 60 -120 references to the function find_contiguous_region_helper() on the call stack. (runaway recursion - don't know why, yet) (2) Confirmed with Calvin Williamson on Wednesday that the smudge tool should *never* introduce the color black when (a) "Keep Trans=TRUE" AND (b) No black is in the image AND (c) the user smudges from transparency to opacity. (3) After switching to the tablet, then using tool icon drag-and-drop in the Device Status dialog box, I *usually* get a segment violation. Three bugs in four days. And I wasn't really looking for them, They just happened when I was trying to have fun. I don't think we can even begin to claim Gimp Stability yet. 56 days to All Fools' Day. Must file some bug reports now. Be good, be well Garry Osgood
Plugins at Sourceforge
In ChangeLog : Fri Jan 28 01:16:35 CET 2000 Marc Lehmann [EMAIL PROTECTED] * PLUGIN_CVS: updated to give Kevin Turner write access to the maze plug-in (therefore, the maze plug-in is no longer managable within the gnome cvs server. If you have any comments/suggestions...) Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating where "authoritative source" resides? Be good, be well Garry Osgood
Please Make Bug Reports [Was: Re: Buggy plugins]
Martin Weber wrote: Here a list of buggy plugins in GIMP-1.1.16: snipped... Did you make bug reports of these? (http://www.xach.com/gimp/news/bugreport.html) 1. With 55 days (count'em) to a supposed release date, and lots of issues outstanding, Gimp needs all the resources it can possibly garner from the community. 2. Those of us on the periphery of support have time to lend - but perhaps only single-digit hours per week. 3, Expecting those of us on the periphery of support to go hunting through the mailing list wastes precious time that should go to the Gimp. 4. Mailing list "bug reports" are notorious for being incomplete. The form on the bug report page solicits pertinent information in an orderly manner, enhancing the possibility of a successful diagnosis. If you made bug reports that were not yet posted at http://bugs.gnome.org/db/pa/lgimp.html because of various latencies, then please accept my sincere thanks. Be good, be well Garry Osgood
Re: Sample Colorize [Was: Re: Buggy plugins]
Sven Neumann wrote: Hi, snipped... If you'd ever seen how Karin turns an old b/w photo into a colored one in a few minutes, you would know how good and useful his plug-in really is. (I had the chance to make this joyful experience last year in Berlin, when Karin and Olof presented the printed versiom of the GUM.) Salut, Sven I couldn't agree more - a plug-in that I find just mildly interesting found in the hands of another individual becomes a tool of great power. I trust, when the time comes to winnow plug-ins down to production numbers, the traffic on this mailing list will increase dramatically ;) By the way, Image/Filters/Colors/Map/Sample Colorize... which engendered this small aside has Wolfgang Hofer as author of record (and no one is maintaining it on a regular basis, according to PLUGIN_MAINTAINERS) Were Karin/Olof unsung contributors? Be good, be well Garry Osgood
Submitting Patches To The Gimp [Was Re: Some update to gimp sources]
Cosmin Truta wrote: snipped... It is the very first time when I try to send a patch to some GNU software, so I don't know exactly how to do it. I sent this message to this List now; if there is another, better way to contribute to contribute to GIMP, I would like to know about it :-) First of all, thank you for the contribution. The current submission procedure for The Gimp is kind of in two different places. First, unstable developer distributions should have a file called HACKING; it contains the submission procedure [gimp/HACKING CVS-1.9 Jan 21 1999]: Please submit patches to the [EMAIL PROTECTED] mailing list. All kinds of contributions are accepted. Patches that you wish to go into the distribution should also be uploaded to ftp://ftp.gimp.org/incoming. Follow the rules there for naming your patches. The ftp site accepts anonymous logins. The second half of the procedure is there: *** IMPORTANT NOTE (please read): If you put patches in the incoming directory you must follow the following format or I will just delete it. You must include the README with a minimum of what the patch does. The maintainers of the distributions will decide whether your patch will be applied in an upcoming release. (gtk|gimp)-username-date yymmdd-n.patch.gz (gtk|gimp)-username-date yymmdd-n.patch.README The "n" in the date indicates a unique number (starting from 0) of patches you uploaded that day. It should be 0, unless you upload more than one patch in the same day. Example: gtk-amundson-970801-0.patch.gz gtk-amundson-970801-0.patch.README We prefer greatly prefer unified diffs, if possible (diff -u for GNU diff) Once you upload *anything*, send the README to [EMAIL PROTECTED] I REPEAT. EVEN IF IT IS NOT A PATCH, SEND MAIL TO [EMAIL PROTECTED] with the README. EVERYTHING MUST HAVE A README! The README that you submit with the patch would detail what feature the patch introduces (note: we're in "feature freeze" at the moment) or what bug the patch fixes. Current known bugs are at http://bugs.gnome.org/db/pa/lgimp.html, so if you are patching a known bug, it helps to explicitly reference the bug number listed there. As an aside, if you encounter something that appears to be a bug, you can report the behavior at http://www.xach.com/gimp/news/bugreport.html If this seems a bit complicated, its because The Gimp is volunteer-supported with limited resources; the extra steps ensure that patches get noticed and handled. Be good, be well Garry Osgood
Re: What should I change in Script-Fu scripts?
Raphael Quinet wrote:
snipped...
There are several ways to fix these scripts, and I would like to get
your opinions about this:
snipped...
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.
snipped...
B3) Add a "flatten image?" option in all scripts, with the default
value set to FALSE.
There was recent discussion about a script user who wanted to
do subsequent modifications, but was faced with the tricky
prospect of making an intricate mask; advise to the user was
"edit the script to eliminate final flattening step." This should
reduce the liklihood of that.
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).
Literally "The Gimp" provides a l/c ascender, "h" a descender, "p"
and capital letters "T,G" so something is touching on the cap height,
ascender, and descender horizontals. That, I think, would be a good
set of visual cues for planning layouts.
snipped...
D2) Add a "padding" parameter to these scripts, so that it is possible
to specify a number of padding pixels around the text.
snipped...
P.S.: Hmmm... I think that I spent more time writing this message than
I would have spent making these changes to the code without
asking...
Ah, but consider how you sharpened your mind while considering
all the design issues...;)
Be good, be well
Garry Osgood
AdminTrivia: Amending Existing Bug Reports
In Gnome ticket report logs - #6257 Buggy Resize on Zoom Lee Willis [EMAIL PROTECTED]; dated Tue, 15 Feb 2000 wrote: Package: gimp Version: 1.1.17 I think this is similar to bug ID's 6070 and 5930 but I couldn't work out how to append to them so I'm submitting this to confirm that a problem still exists in 1.1.17. This particular trivia may be gleaned from the auto-reply one gets after mailing to [EMAIL PROTECTED], but if one has never submitted a bug report, how to amend an existing one may be, in fact, obscure trivia. So. You can amend any existing bug report by sending it mail. For example, to amend #6257, send mail to [EMAIL PROTECTED] Subject does not matter; the text of your mail gets prepended to whatever else has been reported - the original bug report winds up on the bottom of this LIFO stack. More exciting triva at http://bugs.gnome.org/Reporting.html, Be good, be well Garry Osgood
Re: pathsP.h
Blue Lang wrote: did someone take that out of cvs? Yes. From ChangeLog: Wed Feb 16 14:46:14 CET 2000 Sven Neumann [EMAIL PROTECTED] * app/pathsP.h: removed * app/path.h * app/pathP.h * app/path_transform.h: new header files. Only files that absolutely need to access the Path structures internally need to include pathP.h. All other functionality is described in the other header files. i just did an update from the anon-cvs tree (the one hosted by debian,) and cvs axed pathsP.h from the app/ dir. now gimp won't build. any ideas? Hm. Did you (1) tidy up through 'make distclean?' (2) Rebuild makefile.in's through 'autogen.sh your favorite configure preferences' (autogen.sh rebuilds configure, then runs the new configure for you) (3) make all. This synchronizes the configure script and makefiles with changes in the tree actually, nothing is getting put into the intl/ dir either.. the main makefile still looks for stuff in there. i've been just taking intl out of my makefile, configuring with --disable-nls and --dont-use-the-included-intlgetextthingy and crossing my fingers, but, no luck.. Last few days, there have been synchronization problems between various anoncvs servers - see 'CVS ChangeLog' thread. should i blow away my work dir and get a clean cvs dump, or is there a muckup in there? I think 'muck up' qualifies. Personally, I find it reassuring to tarball the work directory, blow it away, and let CVS build a new one from scratch, but that seems unnecessary in this case. Good luck. Be good, be well Garry Osgood
Re:active gradient suggestion
Tom Rathborne wrote [Sun Feb 20, 20:27 ]: snipped... Yes, but you haven't gone far enough. Each colour at a gradient node should be customizable through an expression language (like in MathMap), so instead of gradients like 'Tube_Red', there would just be 'Tube'. The highlight for 'Tube' could be 'hsv(fg.h,sqr(fg.s),sqrt(fg.v))', the shadow edge could be 'rgb(fg.r/2,fg.g/2,fg.b/2)', and the deepest shadow could be 'bg'. Then you set the FG and BG colour and get a tube gradient based on those two colours. (Note that my sample expressions think of colour value on the range 0.0-1.0 so sqr() makes a value smaller and sqrt() makes it bigger.) Just an idea :) Kind of like gradient templates. I was wondering if C++ was going to work its way into this project one way or another. ;) For intuitive use, I'm partial to the idea of (1) Mouse down at some point in the image (start generating a line indicia, a.k.a. Shiftbrush tool or measure tool) (2) Mouse up at some other point in an image. (3) Plot all pixels of the image between mouse down and up inclusive as points in an RGBA color space. (4) Now treat it as a problem in spatial geometry. and find a least squares solution with respect to some degree 2 bezier spline basis (some thought required as to finding optimal nonuniform knot spacing to capture large deltas nicely - See [1] for background) (5) The control points found in color space map to the color section markings in the gradient editor. The join points of adjacent degree two splines are black section markers; the interior control points are white markers. (6) From the user's prospect, this is a gradient snapshot tool: see a nice gradient in an image? Swipe a line over it and then name it. Bring up the gradient editor to tweak. (7) From the programmer's perspective, its a GtkObject that embeds L.S. logic to wean way-over-determined datasets into something more managable. The same logic can turn pen strokes into spline vectors or data reduce tablet output into sparse events, which, methinks, would help most pen-like Gimp tools deal with tablet data (#5947 lead to this thought). All this is very much post 1.2 thinking. Back to bug fixing. Be good, be well Garry Osgood [1] Press, William H. et alia. "Numerical Recipes in C" 2nd Ed. (1992) Section 15.4 "General Linear Least Squares"
Re: How to submit a patch to the GIMP tree ?
Emmanuel Mogenet wrote: Hi, I've justed added support for Targa V2.0 to the Targa plugin. I was wondering how to submit the patch for approval into the main GIMP tree. I contacted the original author of the plugin, but he didn't know either. How should I proceed ?
Re: Colour balance
Tor Lillqvist wrote: I think it is time to repeat this message, from a year ago... The same strange-looking code is still present in color_transfer.c. Is it a bug? Should it be fixed before 1.2? Is my suggestion below a good one? snipped... Comments, please? --tml I believe you are correct. Shadows ought to be handled differently. Using degree 2 bernstein-bezier polynomials feels kind of right, assuming one could convince oneself that this problem is identical to smoothing three samples into a blending function, as if we were "plotting" a parabola by using three "control points" I'd implement the code with forward differencing or DeCastlejau's algorithm, though - which probably already lives elsewhere in the Gimp anyway. I think this is worthy of a bug report. Will submit one if you don't beat me to it. My two U. S. cents. Garry Osgood
Re: Bug? cannot duplicate color channel
pixel fairy wrote: is seems you cannot do to the three color channels what you can to any other, such as duplicate. duplicating a color channel is usefull for things like masking out complex selections (like hair) Color channels are special; you can't get there from here. But you can come close. Here's a few exercises. 0. Open an RGB image. 1. Image-Mode-Decompose 2. Pick any decomposition into Red Green Blue; Hue, Saturation, Value 3. OK (Decomposing...) 4. You now have three or four greyscale images which can be readily fashioned into channels. 5. Layers-Layers, Channels, and Paths... 6. Use the image menu to select the various decomposed greyscale images 7. Now you can drag-and-drop or copy and paste your decomposed greyscale images back onto the original to create additional layers, channels, alpha masks Or you can mess around with them with levels and curves first, for all kinds of odd and interesting selection tricks. Have fun. Be good, be well Garry
New Installation Dialogs
All, The new installation screens are just very, very cool. If you haven't seen them, it's worth uninstalling Gimp just to see them. A small (really small, really) quibble. I find the red border a little over-powering. Maybe something a little more subtle ? (tigert?) Other than that, it really pleases me mightily. A rare treat for a mundane week. Be good, be well Garry Osgood
Re: Getting patches
Ben Fowler wrote: snipped... I am using CVS as a form of software delivery rather than a joint software development. That's OK. That's part of its job. On my machine, I have gimp-1.1.15. If I choose to update it, I need a patch 1.1.15 - current level. Hmmm. you need to patch to the current level, but CVS does that transparently for you. For the most part, CVS saves you from messing around with patches. So far as I can tell, only patches for previous level - current level are archived. Nope. CVS archives Everything Since The Beginning Of Time. For Gimp 1.1.x, that was the fork from 1.0.0, June 2nd, 1998. If you want historical versions of Gimps, you have to ask CVS nicely, and I'm not going into detail here. If you're on Linux or Unix, and you have a fairly standard CVS installation, you should be able to to: $ info cvs or in emacs Meta-x info and look up CVS in the menu. If you have such, you're in possession of the Cederqvist, the CVS bible. Read up on it. If you just want to update your Gimp from *any 1.1.x version whatsoever* to 1.1.18, and you *know* your sources are a working directory produced by CVS, then, when you're logged into the anoncvs server, just go to your gimp directory and $ cvs -z3 update Then rebuild. If your gimp directory was produced by an untarred semi-stable release package obtained from a gimp site, then it is *not* a CVS working directory and the above command will not work. You need to *checkout* a CVS working directory. tar up your old gimp directory (for backup), then remove it, or change directory to where you want to plant a new gimp directory tree, then, when you're logged into CVS: $cvs -z3 checkout gimp And that checks out a brand new working directory of the current version: 1.1.18+ You'll want to run autogen.sh - see gimp/HACKING If you're not sure about the origins of your directory, look for gimp/CVS. If it's there, you've got a working directory. If it's not, it was made from untarring a distribution. Hope this helps. Be good, be well Garry Osgood
Re: gimp 1.1.18
[EMAIL PROTECTED] wrote: snipped... - on alpha-dec-osf4.0d, the program give all errors when loading plugins even though plugin does not crash:: $ /usr/local/bin/gimp ** WARNING **: wire_read: error ** WARNING **: wire_read: error ** WARNING **: wire_read: error ** WARNING **: wire_read: error $ /usr/local/lib/gimp/1.1/plug-ins/align_layers /usr/local/lib/gimp/1.1/plug-ins/align_layers is a gimp plug-in and must be run by the gimp to be used This appears to be a curious manifestation of #2742, which has been pestering DEC Alpha people since October (see http://bugs.gnome.org/db/27/2742.html) What makes this curious and troublesome was that people seemed to be having trouble with compiler version 4.0.F, and reverting to 4.0.D was the workaround. You appear to be having trouble with 4.0.D. One individual upgraded to 5.0 and reported a clean compile. Be good, be well. Garry Osgood
Re: [gimp-devel] Gimp User Installation Dialog / XFree86 4.0
Simon Budig [EMAIL PROTECTED] snipped... BTW: Does somebody use XFree 4.0 with a wacom tablet? Sometimes I believe, that firm pressing the pen results in no more motion events... Is it "no more motion events", or is it *so many* motion events that the Gimp becomes paralyzed in processing the backlog? And is this problem always observed, or only when the "Perfect but Slow" preference choice is made? I do use Wacom Intuos, currently with the Wacom driver developed for SGI platforms, and I frequently find the apparent freezing of the Gimp is due to paralysis. When mapped to the screen, it subdivides that rectangle to very high resolution, implying *many more* events for a given stroke than if the screen pointer device was being used. Such phenomenon should be generally observable, not just with SGI. I'm wondering if this is a case of that. Thank you for the clarification. Be good, be well Garry Osgood
Wacom Tablet Flow Control [Was: Re: [gimp-devel] XFree86 4.0 and Wacom Tablets.
Simon Budig wrote: Garry R. Osgood ([EMAIL PROTECTED]) wrote: Simon Budig [EMAIL PROTECTED] snipped... BTW: Does somebody use XFree 4.0 with a wacom tablet? Sometimes I believe, that firm pressing the pen results in no more motion events... Is it "no more motion events", or is it *so many* motion events that the Gimp becomes paralyzed in processing the backlog? And is this problem always observed, or only when the "Perfect but Slow" preference choice is made? It seems to be "no more events", since lifting the pen and touching the tablet again made the pen work again. It only happens, when "Perfect but Slow"-tracking is *dis*abled. So I guess, when I press harder, more events are generated and Gimp loses some events? Motion Buffer is set to 0. Thank you for the feedback, and 'H...' indeed. This much I know for sure, and I can say 'for sure' because the scope is limited to the XInput Extension interface and not peculiarities of different implementations of that interface (which appear not to be uniform). Enabling your Wacom device and disabling "Perfect but Slow" tracking invokes the Input Extension macro DevicePointerMotionHint() [at the GDK level (gdkinputcommon.h gdk_input_common_find_events())] This macro is used in preparation of calling XSelectExtensionEvent() and, according to XConsortiums InputEvent Specification, tells the XInput extension the kinds of events that is to be obtained from devices. The hint modifier requests that not *all* motion events are to be fed upstream. They are to be filtered. How? That's where published XConsortium documentation becomes vague, and it seems interpretation varies from Xserver to Xserver implementations. On SGI's, in this mode, *one* motion event occurs after a device button press, and another after a device button release. No intermediary motion goes upstream and the pointer behaviour is extremely jerky from pen-down to pen-up. This is similar to (but not exactly like) how you've described it. Differences, I surmise, reside in how XFree implements their server. As an aside, enabling "Perfect but Slow" disables the use of the macro, and the device sends all motion events upstream -- I find that Gimp bogs down at this point: It tries to honor and process *all* motion events, and these arrive at 5 to 7 times the frequency of screen cursor motion events. Sven - In separate email you observe that the appropriate level for flow control of the event stream is in GTK/GDK level, and not at the Gimp application. If the situation were ideal, I'd agree with you, but the "flow control" that applications need to manage devices through the XInput Extension device amount to this almost-all-or-nothing macro. There may be XFree86-specific remedies, but Gimp runs on boxes where XFree does not exist. I'm a member of that last class, and it concerns me. There are a lot of high-end users using Gimp on SGI's Being unable to get the tablet to behave properly does not make members of this class happy. All - Are you happy with how Gimp behaves with your Wacom tablets ? Is this an isolated incident, or is there a general area of difficulty here? Comments ? Be good, be well Garry Osgood
Re: gimp 1.1.18
Tim Mooney wrote: In regard to: Re: gimp 1.1.18, Garry R. Osgood said (at 9:16pm on Mar 24, 2000): [EMAIL PROTECTED] wrote: snipped... - on alpha-dec-osf4.0d, the program give all errors when loading plugins even though plugin does not crash:: $ /usr/local/bin/gimp ** WARNING **: wire_read: error snipped... I've seen this at various times on all the alpha-dec-osf boxes I'ved tried compiling gimp on -- I think I may have been the first person to report it to the developer list. At various times I've thought the problem had been fixed by some change in the gimp, but I just tried 1.1.19 on a 5.0 box with patch set #1 last weekend, and the same thing happened. I have a 4.0f box that the problem doesn't happen for though. As I mentioned when I first reported this problem, it turns out that if you run the gimp under `trace' (just like truss) the first time you run the gimp, most of the plug-ins are queried successfully and work as expected thereafter. At that point, you can run gimp without tracing it, and the plugins work fine. It's only the first time through that this happens. snipped... We're definitely going to need help from people with DEC-osf boxes; between you and Philippe, you've shot my favorite theory down - that it was a peculiarity of the 4.0F compiler - and I have SGI here, and don't see it, and most active developers have various flavors of Linux or Solaris and they don't see it. It's a fairly well understood truth that the out-of-box gimp actually starts up the plug-in to invoke its query() function on run-up, but afterwards a "mature" gimp reads up on plugins from a resource file. So if the resource file gets built the first time, the problem won't occur subsequently - until a new plug-in gets installed. This leads to two ponder points: 1) the execution pathways on the gimp and plug-in side of the wire that are unique to query don't get exercised much - nice place for bugs to persist. 2) When an out-of-box gimp is querying all of those plug-ins, a whole lot of forking is going on - the OS is replicating the Gimp image into a new process, then overlaying that image with the plug-in executable. Not a trivial exercise. And it is happening RAT-TAT-TAT-TAT. Methinks when you started tracing Gimp, you reduce an undiagnosed timing constraint on sending messages between processes and the problem goes away. If fork timing is an issue, then the isolated and relatively infrequent forks of plug-ins likely do not trigger the mis-reading of messages on the wire and they behave just fine. If 2), then nothing bad is likely to be observed when single-stepping through processes on both sides of the wire - near quiescent conditions - so a debugger will likely not explicitly show anything. So one is led to ponder the architecture- particular latencies that occur when a parent is forking off children in fairly short order. I'll give the aforementioned execution pathways a careful look this weekend, and if something interesting suggests itself, I'll send -off-list mail to Tim and other victims of #2742. Anyone with a DEC out there that wants to play in this sandbox, come on in. Be good, be well Garry
Re: Instructions needed
Koot wrote: I want to unsubscribe from the gimp-developer list (am still on the user list) but I cant remember how :-( It will be of a great help if a kind soul would mail me the instructions so that I can unsubscribe. Thank -- DGIT Solutions Cell: +27 (0)82 464 2595 Tell: +27 (0)12 332 1223 Send empty mail to [EMAIL PROTECTED] Follow the directions that ezmlm returns to you. In the future, study your mail header carefully, in particular fields like "Mailing-List" The instructions were there all along, but for want of a careful look. Be good, be well Garry Osgood
Re: commands.[ch] conflicting types for...
Doug Alcorn wrote: snipped... It looks like the header file only defines two arguments in the prototype, but the actual function has three. How is it possible that the gimp compiles for other people and not for me? -- My commands.h file defines edit_fill_cmd_callback(...) et alia with three parameters. It's CVS version is 1.26, dated Mar 24 2000 09:54 checked in by Sven. 1) You've (somehow) obtained an out-of-date header ? 2) A (somehow) out-of-date header was in your distribution (Came from where?) 3) You have multiple commands.h in different directories, and a earlier version is being found first (There are include guards bracketing the header contents, so the first one found rules, and subsequent ones silently ignored). If you can, run the compiler preprocessor only and dump the output to file (on SGI MIPS compilers this is -E -- check your compiler documentation) This may give a flag where the compiler is finding the header. Be good, be well Garry
Re: signal invalidate preview?
pixel fairy wrote: 2000-05-12 Sven Neumann [EMAIL PROTECTED] * gimpdrawable.c: enabled the (commented out) signal "invalidate_preview". does this mean theres a way for a plug-in to know if a certain drawable or image or whatever has changed? No, Sven is referring to a GTK signal that GimpDrawables emit. Typical listeners may include Layer, Channels, and Path widgets that need to update previews of the layers they represent. This is internal to Gimp core logic and is not related to UNIX interprocess communication. Havoc Pennington's "GTK/Gnome Application Development (1999 New Riders) discusses the signalling mechanism that GTK objects (like GimpDrawable) uses. Be good, be well Garry Osgood
Re: gimp cvs massive problems??
Marc Lehmann wrote: What am I doing wrong? I do a cvs update, run autogen.sh, compile the gimp, install it, run it = no plug-ins. Don't know. Haven't reproduced this, but did similiar rebulds under IRIX and the laptop. FYI, my last update was from CVS June 10, 2000 3:30 am EDT. CVS Changelog version is 1.2739 with Vidar Madsen making the most recent entry. Perhaps something tricky was done since then. (CVS reports ChangeLog at 1.2741 as I write). Be good, be well Garry
Re: animation
Fethi BELGHAOUTI wrote: hi to all, how can i save a GIF animation ? the file_gif_save(...) don't generat an animate photo, but just one fixe phto like JPG. thak you! Fethi, symply. ___ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr The GIF has to be prepared as an animation. In GIMP, each frame is represented by a layer, converted to index, and then saved as a GIF; the GIF file plug-in, on seeing a lot of indexed layers, will automatically ask if you want to save the whole assembly as an animation. Jimmac (aka Jakub Steiner) has put together a very nice animation tutorial. See http://jimmac.musichall.cz/tutor.php3 I think, in particular, you would find all you need in his simple animation tutorial, but using the GAP plugin is an interesting next step. Be good, be well Garry
Re: 32-bit images in gimp - Alpha handling wrong?
David Hodson wrote: "Steinar H. Gunderson" wrote: GIMP already does this (32-bit = RGBA, the `extra' 8 bits is an alpha channel, used for transparency information), and has done for a long time now. Calvin Williamson recommended "Image Composition Fundamentals" by Alvy Ray Smith, for a review and advantages of the technique. http://www.alvyray.com/Memos/default.htm. At the moment, as far as I can tell, the Gimp cannot handle pre-multiplied rgba images. Yes. In fact, in generating the projection images (app/paint_func.c) Gimp pretty much does the "unmultiplied case" in the above cite, including the "second composition" step to recover an unmultiplied layer from a premultiplied intermediary result. From the premultiplied viewpoint, that's a lot of unnecesary multiply and divides. Example: render an rgba image. (I was using some PovRay output; I presume it does a reasonable job.) Now create a flat colour background in the Gimp, lay the rgba image on top, and try to get a clean composite without black fringing. I don't think it can be done, It can't be done, in my opinion. What we surmise to be [R*A, G*A, B*A, A] Gimp assumes to be [R, G, B, A] and reads the color components as near black for near transparent regions. That makes black fringing unavoidable. though I'd love to be proven wrong. (There could be issues here with different gamma handling between PovRay and the Gimp, but I suspect the problem is simply a failure to handle rgba properly.) If all we had to care about was an efficient pipeline, premultiplied is the way to go - but there's more to Gimp than its rendering pipeline. There are tools that are relatively simple to code with unmultiplied layers, but are difficult or impossible to do with premultiplied ones. How would the unerase tool deal with full transparent premultiplied alpha [A*R = A*G= A*B = A = 0]? Look for some back door on an undo stack? Premultiplication buys its efficiency by removing information content from the layer. The performance arguments advanced by Smith are compelling, and his pipeline is computationally cleaner, but the last time I did any serious performance measurement on the pipeline was a low-teens Gimp, and compositing to the projection was not a big comsumer compared to building buffered writes to the X server (this was, I recall, not built with threads enabled). My two U. S. cents Garry Osgood
Re: Help files
Rebecca Jean Pedersen wrote: I figured since everyone is talking help files I would just introduce myself. I'm on IRC as bex and I'm willing to help however I can. I'm somewhat new to gimp, so I won't be much good for writing new help files, but my education is in English, especially writing, so I have volunteered to proofread and edit documents. Don't sell yourself short. People very, very, familiar with a topic often "forget what they know" and, consequently, fail to properly stage concepts for the best comprehension of newcomers. On a number of occasions I have read exposition from newcomers to a topic of much higher caliber than that coming from acknowledged experts. The learning experience is still fresh to newcomers and they still remember the sequences of concepts that lead to their own "Eurekas!" and can relate these to fellow newcomers. Old hands often disassemble the scaffolding of their understanding once the framework is complete, so they have no idea how to explain what they've come to know. Jarda Benkovsky wrote: If I may add some points in favor of DocBook: - consistency - it will help make the pages the same style - easy change of style in all pages at once - I believe it's simpler than full-blown HTML (CSS ) Edheldil I'm inclined to agree. I find flat HTML documentation is hard to maintain. As much as possible writers should concentrate on content and leave issues of appearance of formatting, packaging, and delivery to downstream release mechanisms. My two U. S. cents Be good, be well Garry Osgood
Re: Command Line Options
Piers Cornwell wrote: Hi, snipped... * Add "-v" as synonym for "--verbose" * Remove "-v" as synonyn for "--version" * Add "-V" as synonym for "--version" I'd keep -v = --version and add -V = --verbose. This, out of respect for backward compatibility for any version checking automata. My two U. S. cents Garry
Re: Command Line Options
"Guillermo S. Romero / Familia Romero" wrote: [EMAIL PROTECTED] (2000-08-21 at 1913.32 -0400): * Add "-v" as synonym for "--verbose" * Remove "-v" as synonyn for "--version" * Add "-V" as synonym for "--version" I'd keep -v = --version and add -V = --verbose. This, out of respect for backward compatibility for any version checking automata. Yes, but Gimp is doing it inverse that everyone I have seen. I would preffer -v verbose, and -V version, to match other software. GSR perl -v gcc -v Neither are lightly used tools. They establish certain habits in their own right. Miles O'Neill observed. I almost did this when I revamped the command line options a year or so ago. I didn't for the "backwards compatibility" reasons. With much wider distribution of the GIMP now, I wish I'd done it then. I vote to change it. Odd decision to come to, "With much wider distribution of the GIMP now..." the likelihood of dependence on the current command line options is greater not less. If it were only my own self-absorbed preferences in play, I'd agree with the forum. Given the wide distribution of Gimp, I'm uncharacteristically conservative. The only argument I find to counter such conservatism arises from the fact that Gimp 1.1.xx is still an "unstable development series," so one could legally say "you've been warned" to all the automation writers. But as a pragmatic matter, possibly an unfriendly thing to do. If the quorum is for a change, it should be done now, before a 1.2 release. My two U. S. cents Garry
Re: Code cleanup
Maurits Rijk wrote: I just had a look at the code of some of the plug-ins and I noticed that there is often lot's of room for improvement: Yep. snipped... So my question: is it worth the effort to carefully go through all the code (not only plug-ins) and clean things up? Worth relates to whether a plug-in is worthy. Surely, the effort of a generally worthy plug-in deserves all the maintenance it can get. That is the idea behind the PLUGIN_MAINTAINERS file which Sven Neumann inaugurated on 4 January, 2000. Quite frankly, plug-ins compete for mindshare. Worthy plug-ins accrue individuals willing to maintain them. Maintainers shake out as much of the cruftiness that their time and talent allows and balance the advantages and disadvantages that Mr. Rijk advanced. The beauty of this is plain: the worthiness of a particular plug-in is not based on my humble opinion, nor yours, no anybody else's. It is simply based on the fact that it has accrued a maintainer, someone who cares enough about it to fight code rot. Now in the 240 days or so since PLUGIN_MAINTAINERS has been in the CVS tree, about fifty-five plugins appear to have garnered maintainers, out of a population of 165 or so. Of the two-thirds without regular maintainers, quite a few are like cacti, requiring little water and even less soil, they continue functioning with only occasional maintenance from bug fixers. Others are -- well, you can inspect the bug reports as well as I and correlate the unmaintained titles with outstanding reports. If, in the event that something like a 1.2 Official Release should crowd close upon us, and a motion is made to reduce the size of the distribution, I would claim that an unmaintained plug-in with outstanding bug reports is an ideal candidate to oust from the package. There would be unbiased and quantifiable reasons to do so. My two U. S. cents. Garry Osgood
Re: configure script missing
Vikas wrote: I downloaded entire CVS'ed sources of GIMP and to start I could not find configure script. Can anybody send me that file or tell me where can I find it other that doing CVS again (It is a long job). __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com Hi, Welcome to the bleeding edge. CVS gimp does not have "configure" in the CVS repository because it is generated from "configure.in" More generally, to work with CVS Gimp, you may need additional "maintainer" tools (check, though, because you may already have them) GNU autoconf, GNU automake GNU libtool, GNU gettext. Read gimp/HACKING in your CVS working directory on how to use these tools to generate your local configure script. To learn more about using CVS, I'd suggest "Open Source Development with CVS" by Karl Fogel (1999 Coriolis Open Press). Significant parts of this book is available online at http://cvsbook.redbean.com. Be good, be well Garry Osgood
Re: configure script missing
Vikas wrote: snipped historical stuff... I even ran autoconf on the directory and it did generate the configure script but the script did not run. There were errors at startup itself. I do not remeber them right now. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Hi, Typically, I run autogen.sh --prefix=/usr/people/garry/WorkSpace/dist \ --with-gtk-prefix=/usr/people/garry/WorkSpace/dist \ --enable-ansi \ --enable-debug \ --disable-static \ --disable-perl autogen.sh is designed to run autoconf, automake, libtool, gettext. then kick off configure, passing the parameter list to that script, as noted by Marc and described in gimp/HACKING (was that available to you to read?). None of the options I use above is mandatory; the first two assist me in keeping a development gimp environment that is distinct from a production gimp, the next three assist in debugging, the last concerning a regrettable difficulty specific to SGI/Irix (See bug report: http://bugs.gnome.org/db/193/19335), and which is approaching resolution. I suggest you experiment with autogen.sh, as described in gimp/HACKING. If you care to, send me the output by private e-mail if you do not have any success. Be good, be well Garry Osgood
Configure --with-mp=yes Who wants it?
Hi, Brief investigations confirm that two bugs, #10595 [gimp-bug] Tile Rendering not working with erasure], reported by Seth Burgess [EMAIL PROTECTED] http://bugs.gnome.org/db/10/24188.html #24188 [gimp-bug] Tile Rendering not working with erasure[gimp-bug] image *still* not properly displayinglayer mode, reported by Thaddeus Parkinson [EMAIL PROTECTED] http://bugs.gnome.org/db/24/24188.html occur only when gimp is built with configure option --with-mp=yes. (multiprocessor support). #24188 substantially compromises Gimp functionality: In new images, layers with properties other than "Normal" or "Dissolve" become invisible. Seth Burgess wrote [in Re: Bug#10595: [gimp-bug] Tile Rendering not working with erasure] Yes, we did discuss that briefly... [At Berlin GimpCon - GRO] is this bug worth tracking down as it is a very limited set of people affected? Seth #10595 addenda snipped: see http://bugs.gnome.org/db/24/24188.html For the (speculative) 1.2 release: 1. Do we support this option (and fix the bugs)? 2. or do we shut down option --with-mp=yes ? Leaving the situation as-is I regard unacceptable for 1.2 release. Those with multiple CPU's will be naturally attracted to the switch, unlimiting the set of people affected in short order. What's not functional should not be offered, so either a fix or an option removal seems in order. How should cleanup proceed? Be good, be well Garry Osgood
Re: Configure --with-mp=yes Who wants it?
Jay Cox wrote: Jon Winters wrote: Hi, Here is a screengrab if anyone is interested... [Jon Winters had reproduced #10595 with 1.1.25 distribution GRO] http://www.obscurasite.com/images/screengrabs/funky-tots.jpg Enjoy! EEK! I hope that isn't from the "fixed" version. I was hoping that it would fix that problem too. I still can't reproduce it here, but I only have the "fixed" version now. Jay Cox [EMAIL PROTECTED] Appears that your fix for #24188 also lays to rest #10595; I can reproduce neither phenomena this morning on the SGI and Linux machines with the new code and a complete rebuild. I think you bagged both. Congratulations. Interesting if Seth and Jon can confirm on #10595 and perhaps Thaddeus Parkinson [EMAIL PROTECTED] on his #24188. We should all keep an eye out for Tigert's thread dying message, as well. Be good, be well Garry
Re: gradients and pre-multiplied alpha
Hi, Kevin Turner wrote: Should the blend tool use premultiplied alpha for custom gradients? Make a custom gradient that is white on one end and transparent on the other. (Go on, use the RGBA 0, 0, 0, 0 option provided on the menu.) Very well. As a consequence of this, of course, the midpoint of my gradient is R = G = B = 127, for I am asking the gradient editor to ramp on all four channels from 255 = 0. My midpoint, therefore, is a neutral gray that is half transparent. Now use it with the blend tool on a white canvas. The result is a gray band. No surprises there. In comparison, with the foreground set to white, use the blend tool's "FG to Transparent" on a white canvas. Isn't that better? "better" always is a function of how well results matches intent. I have no idea how people generally intend to use Gimp or what their overall expectations are, so I won't even venture an opionion. But I do know that "FG to Transparent" does what it advertises. It leaves the R G B to whatever those values have been set to, then ramp A from 255 = 0, for if were to alter R, G, or B (the FG components) in any way whatsoever, it would be changing "FG" to something else, in violation of what the user interface legend says. So the two examples actually ask Gimp to blend with two different kinds of gradient; I am not surprised that two different results are obtained. So, I'd call the lack of premultiplied alpha for custom gradients a bug. But I seem to recall a recent debate about when it was and wasn't appropriate for gimp to use premultiplied alpha, so I figured I'd ask first. What was thought to be a bug, I surmise, is actually arising out of two different operations that were misconstrued to be the same. To make them actually the same, one would set the gradient editor to blend from [255, 255, 255, 255] = [255, 255, 255, 0]. The gradient doesn't offer the target as a preset, as Mattias Engdegård observed, but one can set the example by hand. There also seems to be a little vagueness here about what premultiplied alpha means. A premultiplied alpha pixel represents points in color space as [R*A, G*A, B*A, A]. It is a representation convention that happens to ease the task of compositing images (see references below). As a consequence of this representation, the first three components of a premultiplied alpha pixel cannot be any larger than the fourth. (also, fully transparent pixels necessarily look like [0, 0, 0, 0]). The current Gimp rendering pipeline is of the unmultiplied type, and it's pretty well hard wired. That is, the RGBA paint functions assume unmultiplied sources, be they TempBufs that tools make or upper layers, they composite a local foreground/background image pair to get a premultiplied intermediary, then divide out the alpha to prepare for the next pairwise composite one step downstack, until they've flattened all layer imagery onto the projection (see references, cited below, for the math). It is at this juncture that premultiplied alpha compositors take the lead in the race: they aren't constantly converting from the premultiplied to the unmultiplied world. All composition is premultiplied composition. Given that Gimp has an unmultiplied rendering pipeline, all facilities at the very top of the image chain must feed it unmultiplied sources, otherwise an image "type mismatch" arises, leading to upsetting results. This issue was given voice last July by David Hodson [EMAIL PROTECTED]. He observed that many image generators in the film and 3D animation industry, particularly 3D modeling tools, all premultiply alpha when making images. (See Alvy Ray Smith's "Image Composition Fundamentals", http://www.alvyray.com/Memos/default.htm. See also Jim Blinn's "Dirty Pixels", Ch 16, 17, and 20, and Ron Brinkmann's caveats in "The Art and Science of Digital Compositing" page 74-75.) Smith and Blinn both illustrate that compositing images with premultiplied alpha pixel data involves less multiplication, is mathematically more elegant, and requires less code. Since compositing digital imagery is a massive chore in the film imagery, it comes to no surprise that their compositing tools and paint boxes are familiar with premultiplied image data and can be asked to accomodate them. Wilber is naive about premultiplied alpha. Feed him a premultiplied image and he just thinks it has some very nearly transparent pixels very near the black point. Gimp uses the alpha channel rather more as a mask; he interprets the alpha component simply as a scale factor by which to make the R, G, and B components more or less invisible (but he leaves R, G, and B magnitudes otherwise unchaged). Given the difference in interpretation, there is a good deal of black fringing visible in premultiplied images that have been fed to Gimp. As Brinkmann points out, users of image tools have to be aware of the distinction between the two uses of one alpha channel and be aware of the possibility of "image type"
Re: gradients and pre-multiplied alpha
Federico Mena Quintero wrote: And yes, the blend tool should do the right thing with alpha values, i.e. premultiply them before compositing them in. I'll submit a patch for it in the afternoon. rant_and_rave I don't think this episode uncovered an alpha-related bug, so what needs to be fixed? Mr. Turner's example (unwittingly, perhaps) specified two different gradients (in the unmultiplied color space). And two different results were obtained. What went wrong? *Should* the gradient tool work in the premultiplied space, while GIMP mostly functions in the unmultiplied one? Won't this give users different alpha characteristics in different places? Won't they be better served with a consistent alpha channel behavior of the unmultiplied space in *most* places? Especially since - for better or worse - the rendering pipeline functions with unmultiplied alpha only? The gaussean blur HAS to pull premultiplied tricks. No surprises there either, for just as Mr. Lamb observed with premultiplied alpha, the unmultiplied space is no cure for the blues either. They happen to be two (mutually exclusive) conventions that can be applied to the alpha channel, and one has a Real Slick compositing algorithm associated with it, blessed by the Computer Graphics Gurus. In light of this, then, I think we should be very careful in preserving a consistent behavior when it come to how the alpha channel behaves, and warn users when inconsistencies (invariably) arise. /rant_and_rave Be good, be well. Garry
Re: TODO for 1.2 release
Nick Lamb wrote: Enough hilarity. If you know of something which must be done before 1.2.0 please follow on to this mail. If you know of a reason why we should unfreeze Gimp instead, feel free to let loose. 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 ??. sigaction/OSF/1/GTK resolution Signal messiness. and a temporary hack is (Am I correct on this, Tim Mooney?) is keeping #2742/#6050) at bay for a class of OSF/1 users. The real cause for the bug is in OSF/1, identified by Austin Donnelly, (See bug report for a lot of silly details), http://bugs.gnome.org/db/27/2742.html but GTK didn't respond well to the OSF/1 strangeness and Mitch Natterer had to write temporary error catching code to get plug-ins to correctly identify themselves. I think the conclusion was to revert the temporary patch before 1.2 release. This depends on g_io_channels revisions being injected into a general GTK release, an effort Tim Janik said the GTK team is undertaking. (discussed at Gimp developer's conference, last June). Be good, be well Garry
Re: TODO for 1.2 release
Austin Donnelly wrote: snipped... an extremely useful list. Thank you for composing it 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. I would penalize all plug-ins without maintainers 2 points. PLUGIN_MAINTAINERS is the authority on this. I would further penalize all plug-ins with outstanding bug reports a further 1 point per report. The entries in the top half of the list are publically announced as being dropped for 1.2 unless a maintainer comes forward, or the current maintainer addresses outstanding issues, or turns the reins over to someone who can. That instigates a probationary period that lasts until Yosh decides to do the Official 1,2 build. Plug-ins that are still in trouble at that juncture are retired in a 'very Darwinian' fashion. Rolling scoring, in case an orderly plug-in suddenly rebels, and no one know how or cares enough to fix it. The policy is indifferent to manner of implementation. To the end user, script can be just as broken as compiled code. My two U. S. cents. Garry
Re: What's up with the bug database?
Raphael Quinet wrote: Does anybody know what is happening on bugs.gnome.org? snipped... See the top level page, http://bugs.gnome.org. Re: "All controls on manual" Seems to be some kind of capacity/infrastructure problem. First noticed the posting around July. it's not a very explanatory explanation, but, perhaps the best they can offer. Be good, be well Garry
Re: macosx gimp works!
Jesse Wilson wrote: Woohoo! Looks like all I had to do was disable shared memory between plugins and the gimp. Yippiee!!! Anyone know why this could have been causing problems? Oh well, it works now, that's all that matters. =) With shared memory enabled, tiles (for sake of discussion, 64 X 64 pixels of image data) are not transferred between Gimp and plug-in over a Unix pipe, but are written into/read out of a region of memory that is literally shared between the plug-in and the Gimp. This very much increases the rate of data transfer between Gimp and plug-in, A big advantage, but for reasons unknown, this mechanism is being corrupted on MacOS. The Unix pipe is working, however. You're probably happy it works at any rate of speed, so go have fun. But sometime or other, please visit http://www.xach.com/gimp/news/bugreport.html and fill out the form. Remind us that plug-ins aren't behaving well when shared memory is being used for tile transport on the MacOS platform. The problem may be that Gimp is making platform specific assumptions about shared memory. The problem may be that shared memory is not quite there yet under MacOS X Beta. Without a reminder, nobody will likely investigate further. Thanks a lot! Be good, be well Garry
Re: could you help me?
Hi, I cc-ed Gimp Developer's List so the question will get wider exposure than just the select few you communicated with. "Dimitry D.Demirchiev" wrote: Hello! Can you help me with a little trouble? I had installed the Gimp for FreeBSD from ports, but plug-ins is not working. They are core dumped. Gimp prints error: LibGimp-WARNING **: gimp: wire_read: unexpected EOF Please, help me to solve my problem. Dimitry I imagine it could be anything. A few more details might usefully constrain my imagination; try filling out Xach's Splendid Gimp Bug Report Form at http://www.xach.com/gimp/news/bugreport.html. which asks a few questions intended to document oft overlooked details, such as the particular version of Gimp you are using and a few more details about your computer/operating system, all which may contribute to plug-in misbehavior. Are your plug-ins left-overs from a previous version? (Do remove old traces of prior Gimps so as not to have version mismatches among libraries, modules, plug-ins and the Gimp itself) Does your problem seem similar to any existing report at http://bugs.gnome.org/db/pa/lgimp.html? In particular, does it seem similar to http://bugs.gnome.org/db/27/2742.html? Thank you. Be good, be well Garry
Re: GIMP help docs
Peter Kirchgessner wrote: Hi bex, where is to-do.txt ? --Peter This probably has been answered privately, but I'll take the liberty of answering it publicly. Given the nearness of 1.2 release, the Gimp Help Team (bex, Piers Cornwell, Daniel Eggers apologies if I missed the other contributors) started a separate gimp-help project last July, and not integrate with the main tree until help stuff is reasonably sane, complete, and stable. % cvs co gimp-help See gimp-help/help/C/to-do.txt. Be good, be well Garry
Re: brush and pattern popups (was Re: Gimp tool icons)
Austin Donnelly wrote: Is it generally known that mouse-down and waiting on brushes and patterns pops up a larger preview window showing the whole brush/pattern if it's larger than the preview? Do many users discover this themselves, or are they ignorant of the fact? I think I noticed it around May or June, 2000 after a year of mucking around with Gimp. A preview suddenly popped up into my face. Pause. then light dawned over Marblehead. Wasn't looking for it; but glad to have found it. So it can be found by an innocent user, but perhaps not quickly. Daniel Egger asked: Just curious: Is anyone able to get the brush dialog by doubleclicking the brush in the toolbox using a graphicstablet? Yes. With Wacom Intuos tablet. Be good, be well Garry
Re: GIMP help docs
Marc Lehmann wrote: Simon and me are currently at the Systems'99, and, well, we probably need a lot of couple of beta-releases ;) gimp seems to have a lot of small problems like the selection going away after some time and not coming back, refresh problems (a lot, but difficult to reproduce) on all our machines, and the return of the "w-src w-bytes * ..." warning. I guess most of us just ignore these problems, but just how difficult would it be to fix this? Are we (simon and me) currently the only ones having these prblems? Selection going away: http://bugs.gnome.org/db/10/10498.html "Marching Ants die untimely deaths" I regularly observe the selection disappearing when I use the Wacom Tablet, and setting it as an input device through Image-Device Input. I have not observed it otherwise. Do you recall if your incident is purely/partially tablet related? Thank you. Be good, be well Garry
Re: Gimp testing
Chuck Egner wrote: Hey all, Does anyone have a test suite that they can release to the public? Is there anyone specifically in charge of SQA? After hours of struggle in the tropic heat,Wilber and Crew --finally! -- shifted the massive granite barrier just enough so that the small band of intrepid explorers could cd to gimp/app/unittest. Bunched together, wary, eyes wide orbs and still sun-blinded, they crept cautiously down steep, stone steps into the cool darkness of the directory, electric torches swinging to and fro, probing, picking out here and there dusty shards of shattered shell scripts. Quiet. then some soft scuttling off to the right where a dark form massed against the wall. Wilbur swung his torch to the right. They all gasped. Lying in the pool of incandescence, clothes rotted, bones picked clean, still intwined in the infinite loop that was his undoing, the skeleton grinned back at the crew, sightless sockets empty, black and unable to service connection requests. "Asbjorn" Wilber whispered softly. "Asbjorn Pettersen." "We all knew he was working down here somewhere. It looks like it got the better of him, poor sod." Frightened by the light, bugs scuttled into the dark recesses of the Application, where few have dared to wander and even fewer been known to return. Be good, be well Garry
Tablet Testing Needed!
Hi,
I was delighted this weekend to uncover a cause to #10498: "Marching
Ants die untimely deaths" which has been pestering me for sometime
now. The immediate cause stems from the pause count in the Selection
structure being incremented more often than being
decremented. [selection.c CVS-1.6 selection_pause() L. 590,
selection_resume() L. 600, selection_start() L. 627]
The underlying cause to the asymmetry is a bit troubling, for which I
will need some testing help on a wider range of hardware. It appears
that when the Wacom Tablet device is active, it is possible to
originate a right mouse button event to bring forth an application
menu, for example, even when the pressure point is active (and
functioning somewhat like the left mouse button). In particular, this
behavior undermines some assumptions implicit in init_edit_selection()
and edit_selection_release() about actually seeing a left button
release. [edit_selection.c CVS 1.34]. which assumes, (mostly
correctly, perhaps) that once a gdk_pointer_grab() has been performed,
it darn-tootin' *will* see the left button release to unwind the
selection pause count and the gimp_undo_freeze() among other
interesting things.
More about that later, first I would like tablet users [and not just
Wacom tablet users] to perform a nice little torture test on their
Gimp and post results here to determine how widespread this difficulty
may be. (I think any 1.1.2x Gimp version will do, as pertinent code
areas have not changed much lately)
0. Start Gimp. New Image (Cntl-N).
[Optional: File-Preferences-Image Windows-Cursor Mode is "Tool Icon"]
1. Activate the tablet device.
a. Image-Dialog-Device Status... (handy device monitor)
b. Image-Dialog-Input Devices...
c. Select your tablet device (mine is named "wacom", yours may differ)
d. Switch your tablet device Mode: to "Screen"
e. Confirm: your device should add itself to the "Device Status"
display picked in step 1.a. but be inactive ("pushed out" label)
2. Pick up your pen and bring it in proximity to the drawing tablet
a. Confirm: your device should become active ("pushed in" label)
3. Conveniently, the Rectangular Select Tool is already active. Make a
selection with it.
a. Confirm: Marching Ants appear around the selection border.
4. With pen still in hand, move to the interior of the selection region.
5. Press down and move the pen (this activates init_edit_selection()
and Edit Select tool methods that over-ride the rectangular select tool-set.
also, the pause reference count is incremented in the currently active
Selection object; gimp_undo_freeze() had already been invoked
in a rectangular tool method context)
a. Confirm: Move cross icon appears. (if Cursor Mode is "Tool Icon")
6. If you have a Wacom Intuos tablet (and Grapphire too, I believe) you
have a right mouse button emulator on the pen body. Such a button
is often on pens of other models as well. Press this right mouse button
emulator now.
7. Do you obtain a right mouse button Image menu? Please report "yes" or "no"
to this news group, plus your tablet model and X Input device driver
(If you know). I have a Wacom Intuos attached to an SGI O2, and the driver
is the Wacom Tablet Driver for Intuos tablets Version 4.4.0 (SGI)
I get a right mouse button Image menu, as if I had pressed the (actual)
right mouse button in ungrabbed gdk_pointer mode. Had I omitted steps
1.a - 1.e and followed the remaining steps with either the mouse or the
pen (Device status shows "Core Pointer" active), the generation of a right
mouse button Image menu does not occur after step 5 "press down and move...".
With the pen pointer (or left mouse button) pressed, the right mouse button
appears to be ignored.
In getting a right mouse button menu (Device status shows "wacom" and it is
active), all manner of mischief is now possible, undermining the assumptions
about pointer state underlying edit_selection code. This appears to range
from:
A. no mischief at all (the right mouse button emulator is immediately
released: no menu selection is made)
B. some mischief (The button release event is missed if a menu selection
occurs. Nothing ever decrements the Selection object reference count
and -- unbalanced -- the selection remains paused until application
exit: Bug #10498)
C. Great Mischief (If the pointer moves outside the Gimp Image window after
step 5 "press down and move the pen..." then it appears that the
specialized edit-selection tool remains in control well after its designers
intended: it's edit_selection_button_release() method does not get called
in a timely fashion, gimp_undo_thaw() is not immediately called
either, so undo events can be lost if the user proceeds with further
image manipulation.
I would like to obtain a sense of how widespread this phenomenon
is. Marc Lehmann reported to this list that he observed it on Simon
Budig's machine at Systems'99, but not his own, and
Re: Thanks for tablet testing...
Simon, Raphael Simon: Thank you for the Havoc Pennington/X-11 Consortium documentation As Raphael points out, the GDK/XInputExtension glacis is where interesting affairs transpire. Raphael wrote: 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. I suspect this. I'm not at the stage where I actually believe this. - For the ArtPad II under XFree86, another bug in XFree shadows the GTK+ bug and causes other strange things to happen. Can't say anything useful here, since I am testing without XFree86 (Setup uses Xsgi) If this theory is correct, then the Gimp 1.2 should require a new release of GTK+. :-( I am rather leaning toward this sad conclusion. However, at Gimp level, we never check gdk_pointer_grab() to confirm we have the pointer, and that is suspect [example: app/rect_select.c line 173] Pennington tells us we should (See 10.6.2 GTK/Gnome App Dev, first reference in Simon's mail] Also, we limit grab to the current window only, not to child windows (like menu panes?) so we can lose control of focus, no? When the pen point (simulated left mouse button) is already down and a grab has been made from rect_select, then here's what watch points at gdk_pointer grab report: (Tablet device enabled and active) (Rect Selection already made) (Cursor in selection) (pen point goes down...) only asking for grab on current window V 0 gdk_pointer_grab(window = 0x107bcb50, owner_events = 0, event_mask = 552, confine_to = 0x0, cursor = 0x0, time = 42275620) ["gdk.c":694, 0x0400cdec] 1 rect_select_button_press(tool = 0x10777d10, bevent = 0x103e79c8, gdisp_ptr = 0x107bb6c8) ["rect_select.c":173, 0x101e3244] 2 gdisplay_canvas_events(canvas = 0x107b6320, event = 0x103e79c8) ["disp_callbacks.c":281, 0x100b0878] rest of stack snipped... gdk_xgrab_window = 0x107bcb50 -- gimp image display window return_val = 0-- grab was a success (Floating selection being dragged, then "right mouse button" simulated depressed on pen body) Menu pane asks for self child V 0 gdk_pointer_grab(window = 0x1087a308, owner_events = 1, event_mask = 13060, confine_to = 0x0, cursor = 0x108bb570, time = 42288140) ["gdk.c":694, 0x0400cdec] 1 gtk_menu_popup(menu = 0x1065ed70, parent_menu_shell = 0x0, parent_menu_item = 0x0, func = 0x0, data = 0x0, button = 3, activate_time = 42288140) ["gtkmenu.c":493, 0x5fed58bc] 2 gdisplay_canvas_events(canvas = 0x107b6320, event = 0x103e79c8) rest of stack snipped... gdk_xgrab_window = 0x1087a308 -- menu pane window (child of gimp image window, yes ???) return_val = 0-- menu pane gets its pointer grab... The hunt continues Garry
GDK and XInput [Was: Re: Thanks for Tablet Testing]
Simon, Raphael, All...
I had the opportunity to spend three or four hours
yesterday afternoon/evening (GMT -5.00) seeking ways
to rescue Marching Ants (#10498).
I can confidently report that a call such as:
return_val = gdk_pointer_grab (gdisp-canvas-window, FALSE,
GDK_POINTER_MOTION_HINT_MASK |
GDK_BUTTON1_MOTION_MASK |
GDK_BUTTON_RELEASE_MASK,
NULL, NULL, bevent-time);
does not behave identically for core events (Defined in the
original X11 protocol) and XInput Extension events. This is
true when GTK+-1.2.8 has been built with the --xinput=xfree
option. While the GDK event request list is honored for core
X11 protocol events, the XInput events are subject to
special handling. The culprit,
gdk_input_common_find_events(), while nominally in charge of
just mapping the the GDK event request list into appropriate
XInput device classes [gtk+-1.2.8/gdk/gdkinputcommon.h], it
in fact asserts an internal policy of linking symmetric
events. That is, this code virtually adds
GDK_BUTTON_PRESS_MASK when a client requests only
GDK_BUTTON_RELEASE_MASK -- and vice-versa.
The comment is unhelpful:
/* We have to track press and release events in pairs to keep
track of button state correctly and implement grabbing for
the gxi support */
if (mask GDK_BUTTON_PRESS_MASK || mask GDK_BUTTON_RELEASE_MASK)
{
DeviceButtonPress (gdkdev-xdevice, gdkdev-buttonpress_type,
class);
if (class != 0)
classes[i++] = class;
...
[gdk_input_common_find_event() gdkinputcommon.h Line 322 ff]
It is not clear to me why "button state" matters to GDK or
why GTK+-1.2.8/GDK requires events to be linked in this
fashion -- for XInput Extension devices only.
To the contrary, Gimp' family of selection tools require the
alternate circumstance: that during the grab, button press
events cannot be permitted to arrive, else the grand Gimp
event dispatcher, gdisplay_canvas_events()
[disp_callbacks.c], would divert Gimp process flow into a
(likely) menu dispatch. Since many menu implementations are
"tool-like", this can lead to the unloading of the current
selection tool before it has had opportunity to put its
persistent state in order -- thaw the undo stack, for
example. This is especially true for the "Trojan Horse"
tool, edit-select, which, through invitation by some other
select tool (invoking init_edit_selection()), temporarily
substitutes its predecessor's tool methods for its
own. Should this tool become unloaded because of a
menu-related button press, the predecessor's finalize
methods are not called and the tool itself does not have
full opportunity to clean up.
What to do?
Certainly, bug reports to GTK are in order: GTK "promises"
to abstract the pointer so that the application writer does
not have to do anything special with core and extension type
events. Grab semantics should be uniform. Now that I am
confident of the chain of causuality, I can handle that.
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?
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.
Thank you to Simon and Raphael for thoughts, observations, snippets
of test code. As an aside, I think Simon is correct in observing
that this bug is also related to Bug #6901, "Can not continually move a
floating selection with a pressure sensitive pointer."?
Be good, be well
Garry
Re: GDK and XInput
Simon, Raphael, All...
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.
The GTK+ bug describing this GTK+/GDK issue, which #10498
has a dependency on, is #32617
"gdk_pointer_grab() Behaves Differently for X Input Events"
Austin Donnelly wrote: [Fri, 17 Nov 2000 15:07:29 +]
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?
I saw no evidence of a GTK bug report covering this in the gnome database/gtk+ list.
I recall that you and Tim discussing it at Berlin last summer; is the
gio_channels patch being handled informally?
Marc Lehmann wrote: [Fri, 17 Nov 2000 19:16:01 +0100]
1) Document, warn, but otherwise ignore the problem.
Probably the only viable way to go for 1.2, unless gtk+ can be fixed in
time. Maybe the best thing would be to issue a warning dialog ONCE.
3) Re-engineer select tool code to be more robust in button
That's out of the question for 1.2, I think.
I lean toward 1), since a tentative patch is in hand, I feed no motivation
to do complicated things at the gimp level. I have no idea how long
this patch (or something like it) migrates into production. The largest
concern I have in that regard is some application having a dependency
on old gdk_input_common_find_event() behaviour.
Be good, be well
Garry
--- /alice/WorkSpace/gtk+-1.2.8/gdk/gdkinputcommon.h-orig Sat Nov 27 02:51:24
1999
+++ /alice/WorkSpace/gdkinputcommon.h Sun Nov 19 14:09:36 2000
@@ -315,18 +315,17 @@
XEventClass class;
i = 0;
- /* We have to track press and release events in pairs to keep
- track of button state correctly and implement grabbing for
- the gxi support */
- if (mask GDK_BUTTON_PRESS_MASK || mask GDK_BUTTON_RELEASE_MASK)
+
+ if (mask GDK_BUTTON_PRESS_MASK)
{
DeviceButtonPress (gdkdev-xdevice, gdkdev-buttonpress_type,
class);
if (class != 0)
classes[i++] = class;
- DeviceButtonPressGrab (gdkdev-xdevice, 0, class);
- if (class != 0)
- classes[i++] = class;
+}
+
+ if (mask GDK_BUTTON_RELEASE_MASK)
+{
DeviceButtonRelease (gdkdev-xdevice, gdkdev-buttonrelease_type,
class);
if (class != 0)
Re: GDK and XInput
Raphael Quinet wrote: 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. I did a grep on all gdk_pointer_grab() in gimp/app; not one call requests proximity events during grabs, so even if XFree86 has reason to generate them, they will be supressed on the X server side during grab periods. But you are seeing them in the event stream to your Gimp image window? -- strange... (deep ponder mode) I have XFree86 on the laptop, if I can grab an older ArtPad II from somewhere... More testing is needed, by people who have another type of tablet. Agreed. One or two is not sufficient, and patch authors suffer from hubris ;) 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? I received a prompt reply from Owen Taylor following my submission of GTK+ bug report #32617, however, there is not complete buy-in from him that it is a GTK problem. See http://bugs.gnome.org/db/32/32617.html. (My response to his feedback is not posted yet: 21:43 EST (-5.00)) Thank you for the report. Not too many are testing this, which gives rise to an old saying: There are two kinds of software. 1. The kind everybody hates 2. The kind nobody uses. Could it be that actually activating X Input is so frustrating that people do not use it? Is core-pointer emulation mode the typically comfortable way to use a tablet with the Gimp? Be good, be well Garry
Re: Tablet Testing
the Loial Raven wrote: I've been looking back through the mail archive and am seeing if it is any way tied to my own problems... but i checked and i'm getting the same problem... i didn't even notice it before. I also noticed some other interesting things. i'll give the output from xinputev as well as a little bit of what i was doing: Enabling No. 0: "Eraser" (Type: 2) Enabling No. 1: "Cursor" (Type: 3) Enabling No. 2: "Stylus" (Type: 1) Enabling No. 65244: "Core Pointer" (Type: 0) button_press : device 2 pressure 81.000 button 1- pressed tip button_release: device 2 pressure -79.000 button -1 - pressed B3 proximity_in : device 0 --- proximity_out : device 0| proximity_in : device 0| proximity_out : device 0| proximity_in : device 0| proximity_out : device 0| proximity_in : device 0| proximity_out : device 0|--- moved stylus proximity_in : device 0|around proximity_out : device 0| proximity_in : device 0| proximity_out : device 0| proximity_in : device 0 --- button_press : device 2 pressure 8.000 button 1 - released B3 proximity_out : device 0 button_release: device 2 pressure -101.000 button -1 - pressed B2 button_press : device 2 pressure -101.000 button 3 - released B2 button_release: device 2 pressure 105.000 button -1 - released tip that definitly looks odd to me. i also noticed the lack of button_release when using B3 on it's own... under no other condition does the proximity_in/out happen except when a true proximity change. Hope this helps at all... Now the little thing i also noticed was the pressure readings... it seems that using xinputev, it shows my minimum pressure as 127, and max as -128... and yes, in that order. thanks Matthew Peters Matt Thank you for sending this to me. I'm about to leave for work, so I haven't digested this, but it looks similar to Raphael's bug. I've taken the liberty of forwarding this to gimp-dev mailing list. I'll be able to give this more thought when I'm home for (American) Thanksgiving holiday. Be good, be well Garry
#6091 Remarks
All,
I believe #6901 "Can not continually move a floating selection with
a pressure sensitive pointer." is very nearly intractable.
1) The Xlib Programming Manual notes that for the core pointer,
when PointerMotionHintMask is set, only one motion event will be
sent per change of position of the mouse (Appendix E, "Event
Structure Members" discussion of "is_hint" flag). The corresponding
guarantee is not made for XInput events. This weekend (11/24 -11/26/2000)
I used xscope to monitor the client/server traffic at the X protocol level.
For Wacom tablets using the Wacom 4.5.0 driver, hinted motion reporting
is confined to one motion event per change in some button state, giving
rise to the behavior reported in #6901. There is no indication that this
is anything other than Wacom driver specific behavior; other drivers may
cut more closely to core pointer behavior, but since the XInput Extension
document furnishes very little guidance about what driver writers should do
with the hint, a wide spectrum of hint behavior is possible.
(being a "hint" there is no obligation for driver writers to
honor it, and hinters should not make too many assumptions about particular
behavior resulting from the request).
Without uniform behavior, there is very little in the way of a common
approach that Gimp or GTK can take after requesting hinted motion from
a device. Large gobs of "if (this) {...} else if (that)..." dance before
me eyes.
2) The only tractable approach that occurred to me was to abandon the hint
request approach (i.e., remove GDK_POINTER_MOTION_HINT_MASK in any event mask
flag of gdk_pointer_grab() where edit_selection tool methods may follow).
This avoids variable behavior surrounding motion hinting with external devices.
While Adam Moss had furnished an event queue trimmer to telescope the resultant
flood of motion events, the underlying gdk code does not just manage a
client side "GDK event queue" but issues XPending() to flush possible events from
the server; much I/O waiting occurs on the gdk_event_get() call because
of this. (see gtkutil_compress_motion() cursorutil.c Line 509). I found
the results fairly sluggish (but not as sluggish as shunting
gtkutil_compress_motion() and mindlessly processing every motion event).
3) An approach that I did not try runs along the line of
changing the compression strategy of gtkutil_compress_motion() so that it
rejects any motion event where a x*x + y*y - (x +dx)*(x +dx )- (y +dy)*(y +dy)
delta is less than a pre-set difference. Such a filter is applied to all
motion events. This may be a bit radical this close to the Fabled 1.2 Release.
Observations? Suggestions? (Adam?)
Be good, be well
Garry
PS #6901, by the way, bears no particular relationship to #10498, apart from
the happenstance of being tablet-based. That bug stems from GTK+
bug #32617, which inserts an unrequested button-press event flag
in gdk_pointer_grab() for XInput devices only.
Re: #6091 Remarks
Austin Donnelly wrote: Something like (dx*dx + dy*dy) thresh might be a better condition, no? Yes ;) Thank you. No one particular value of "Thresh" would please everybody, it would give rise to a "snap to an invisible grid" effect, so a setting mechanism for this value should extrude into preferences. Though for very precise positioning, one can resort to the "Move Tool" and cursor keys, and, perhaps dispense with a preference setting (for now) and retain a relatively large area threshold. I haven't tried this to see if it improves the situation. A matter for this coming weekend. Be good, be well Garry
Request To Revert Curve Tool
2000-11-29 Austin Donnelly [EMAIL PROTECTED] * app/curves.c: Applied patch from David Hodson [EMAIL PROTECTED] to fix Bug#33399: GIMP crashes when applying curve to Grayscaled image when preview is off. Previously the curves tool attempted a reset when changing image, but didn't correctly do this. Now it has the (more useful) behaviour of doing a partial reset, where the curve remains the same across multiple invocations, allowing you to apply the same tweak to multiple images. The internal state relevant to image type/depth is correctly reset, stopping the segfault behaviour seen before. Well, after two weeks of trying the new behaviour, I find myself not liking it and request that the initial range transform from old to new just be the identity transform, as it was before. Alternately, I request an added toggle button to set the preferred kinds of initial state. 1. I find the new behaviour useful only when my intended effect is "something like" what I tried before, but this is not always the case. Often, my intent from one invocation of the curve tool to the next is along different lines, and in those (very frequent, for me) disjoint cases, I find the best starting point is the one that applies no transform to the image at all: the (former) identity mappings. This permits me to start my explorations from the image I have to what I think I possibly want. Now I have to somewhat unapply the old transform before intuiting what the new transform should be. 2. Individuals interested in applying similar transforms to a variety of images already had a remedy (which is still in place), saving a particular transform to file and then reloading it again. The current interface change does make this work flow more efficient (no save/load), but, I claim, at the cost of the disjoint case workflow, the one I frequently (typically) follow. 3. The change in interface has introduced something of an initial state bug, which I will report if the group thinks the new behaviour should remain in place. When the curve tool recalls the previous (not identity) transform, the image itself remains unchanged, as if the identity transform is in place, and not the actual transform manifest in the curve tool. The tranform ought to be applied so that the image state matches the setting of the curve tool. The "flash" of tiles suddenly updating would also furnish a visual cue to the user that the transform inside the curve tool is currently something other than the identity transform. This is a fairly trivial bug to fix; one applies a "pseudo mouse move" to invoke image_map.c logic. If I fall into the minority in this issue, then I (alternately) request that a toggle button, somewhat like the preview toggle button, be put in place so that those of us who prefer the old behaviour (start from the identity transform) can put the policy in place. Thank you for your attention; I hope to hear alternate opinions. Be good, be well, Garry Osgood
Re: repetitive stress . . .
Marc Lehmann wrote: On Tue, Dec 12, 2000 at 09:46:21PM -0500, Andy Deck [EMAIL PROTECTED] wrote: The attached image demonstrates a problem that I think ought to be remedied... Basically, when the disk is full, there is not much one can do. BTW: what, *exactly*, is your problem? I think his problem is that he doesn't know about bug reporting. The nice thing about Xach's form at: http://www.xach.com/gimp/news/bugreport.html is the series of questions it walks people through, so that version numbers get stated, which would have saved this particular guessing game. I *think* his second problem is that he's got a version of Gimp that doesn't telescope its error message windows. That's been fixed some time ago; so his immediate remedy is to upgrade. If he *has* a recent version, then there is a bug (failure to telescope error messages), which a bug report would have indicated immediately. Be good, be well Garry
Re: Request To Revert Curve Tool
David Hodson wrote: The reason I made the change is that: * the tool (one of them, at least) _did_ actually keep the old settings, [The curve tool ], it just didn't display the parameters correctly; and * the reset button is right there, if you need it. True, almost -- never displayed nor applied parameters initially. A "feature-in-waiting" I think, I also figured that it's easier to reset if you don't want the old settings, than it is to find them again if you do. Also true. The bug report specifically talked about applying the same transform to multiple images, so at least one person uses that facility. This, I gather, is Cooper [EMAIL PROTECTED], his first point in #33399. The change certain makes that workflow easier to perform (See http://bugs.gnome.org/db/33/33399.html). I certainly glad you've done the spadework (Thank you, again, David) and your interpretation of what to do is certainly reasonable, but I now find the tool less facile for my work, where I really *don't* like a setting that I've "disposed" of suddenly come back to life, and now have to explicitly reset it away. Here is what I propose: 1. There is now a "latency" bug where, when the curve tool is brought up with a non-identity transform, it is not immediately applied, so the setting of the tool is not reflected in the state of the image. That becomes the basis of a (minor, almost cosmetic, and easily corrected) bug report. The image should immediately align with whatever transform is being applied by any interactive, image_map-based tool (curves, levels, color balance, hue-saturation, brightness-contrast, threshold, posterize). 2. Among the interactive tools, the curve tool has a now-activated and unique "persistence" feature that some people like and others don't. In the course of fixing 1., I propose adding a "Persist?" setting. For those who prefer to start their search for a nice transform from the identity transform, they can disable this toggle and get the older behavior. Is this a reasonable course? Thank you all, for your time. Be good, be well Garry
Re: [gimp-devel] Re: repetitive stress . . .
Simon Budig wrote: Garry R. Osgood ([EMAIL PROTECTED]) wrote: If he *has* a recent version, then there is a bug (failure to telescope error messages), which a bug report would have indicated immediately. He has not, there are three tools missing in the toolbox. Correct. And no select/mask switch in the lower left corner. Simon, you have better eyesight than I do... ;) Be good, be well Garry
Re: Pupus pipeline: what Adam has been doing, etc. etc.
Hi. This also includes "The Future of Gimp" commentary. Tino Schwarze wrote: Hi Adam, On Thu, Dec 21, 2000 at 11:15:17PM +, Adam D. Moss wrote: How would the "pupus" functionality be directly exposed to users? The answer is that it most assuredly WOULD NOT. I do not advocate, in fact I ABHOR the idea that the user should end up drawing a little tree of boxes connected with wires. That's your view as a programmer I want it! Hey, this is interactive Script-Fu! I agree with Adam. It so happens that the directed graph abstraction which is serving his thinking about scheduling visually coincides with a user interface presentation where upstream branches of layers composite into common result sets. This happens to be two places where the abstract tree data type has taken root in the fecund (if imaginary) soil of Gimp 2.0. Trees happen to furnish a nice framework to think about the shape of a great many tasks, so this coincidence is common (and an ongoing source of confusion). If we dedicate the Gimp 2.0 core to nothing other than staging (various kinds of) compositing of result sets from different kinds sources (ideally, not all bit maps), then the user interface simply falls away from view. That is not to say that user interfaces are unimportant -- but they are (as much as possible) independent objects of design, each with their own concerns and issues. So Gimp is not married to the GTK widget set; if some (many) ones write a QT interface, bless them. Some few others may write a native Win32 interface -- bless them too. Script languages are interfaces as well; I should think that marrying Gimp with Perl or Scheme or Script Language X should not be nearly as hard a task in the 2.x series as it had been in 1.x. What may be commonly said about "user interfaces" is that they are *any* member of the class (including your favorite script interpreter) capable of originating work requests with the 'step manager' (handing over references to typographic or structured vector graphic or pixel graphic content) and querying "presentation" black boxes about the result (if any). It may be a refreshing exercise to inventory the black box bestiary presented by Adam thus far: 1. Some are capable of interpreting references to some sort graphic content as, say, PNG files in a file system. 2. Some (cache-boxes) are capable of persisting "upstream" image presentation for "downstream" black boxes. Some other component of the application might choose to associate with such cache-boxes the notion of "layer", but that is the business of that more or less external (and, me thinks, user-interface housed) component. To the step manager, it is a step that persists (parts of) images. 3. Some black boxes (it seems to me) house genetically engineered goats (large ones) that pixel process. As an aside, These GEGL boxes are (hopefully) the only interior places where some sort of physical implementation of pixels matter -- how many bits they have, how those bits relate to color and transparency components, what sort of pixel and pixel area operations are capable of mapping a region in one cache-box to a region in another. To pupus (the step manager) it is just a surface -- it is neither capable of, no interested in, the manipulation of the surface 'fabric.' 4. Some black boxes know how to stream to external representations: perhaps they embed connections to an X server, or something that knows how to write (particular kinds of) image files. So what is Gimp 2.0 -- the application -- do? Refreshingly (I think) not much. It configures a step manager of a particular arrangement that makes sense for the profile of requirements that some sort of user interface presents, authenticates that the version of user interface is capable of talking with the version of step manager present, (mumble, mumble, other kinds of sanity/compatibility checks) then steps back and lets the ensemble articulate. If the profile of requirements call for an interactive Gimp, then some of those black boxes will be display-capable. If the profile of requirements is a batch orchestrated by a perl script, then only file reading/writing and image processing black boxes will be required. It is this view that makes Gimp 2.0 largely a collection of shared object code, each shared object being a thing that a (likely) small group of individuals can dedicate themselves to and get to know particularly well, and there will be less of a need for someone to be knowledgeable about the Whole Massive Thing (as in Gimp 1.x) (the shared object may even be general enough to export to some other application, unchanged). What concerns me is this style of thinking places a great deal of importance on coordinating interfaces and internal protocols; this is not a topic upon which UI, scheduling, image-processing, and specialty black-box architects (a kind of Gimp 2.0 third party contributor) should drift too far
Re: gimp patch 1.1.32-1.2.0 [Also: Re: cmon guys, no patch from 1.1.32 to 1.2??]
[EMAIL PROTECTED] wrote: I got off my lazy arse and made a patch. I have no idea whether I did things correctly, I just downloaded the gimp- 1.1.32.tar.bz2 and gimp-1.2.0.tar.bz2 files, unpacked them, did diff -u -r gimp-1.1.32 gimp-1.2.0 gimp-patch, then bzip2'd that. It's 534kb, and you can download it from http://nova.student.utwente.nl/tc/gimp-patch-1.1.32- 1.2.0.bz2 Merry Christmas, Lourens Commendable, and in keeping with the spirit of the season. Thank you. Personally, I would strongly urge anyone desiring to support a Gnome or GNU/Linux project to learn about CVS. See http://cvsbook.redbean.com. The tarballs and patch-sets are really meant for end-users who prefer to compile from source, but don't otherwise desire to get involved in maintenance and so don't have a strong motivation to keep a bleeding-edge source tree around. Patch sets are published with this laid-back attitude in mind, They lack the CVS administrative files which is a pity (but then, CVS admin directories don't always transplant themselves effortlessly. They depend on the context of particular users on particular clients using particular CVS servers) After the initial working directory download (which can be painful on a slow, intermittent connection, but not prohibitive -- see below) keeping a working CVS directory current is painless, *especially* if one has a slow or intermittent connection. With CVS update, the server sends patches, not whole files, and per-patch compression somewhat lowers the absolute amount of bits to transfer (Steinar notes this could be better - agreed, but while the compressor could optimize across the entire patch set, it would not be as graceful in recovering if the connection dropped) Should a connection drop, the CVS client and server pickup can pick up where they left off -- check- pointing is an adjunct process to synchronizing a working tree with the repository. In contrast, not all ftp servers support restarting in an analogous way. And as for time, one can set up a cron job to do nightly syncs when one is asleep or otherwise occupied with something else, so it just happens that the tree is updated when you awake or come back to work. (with a little extra cleverness, the job can be written to restart dropped connections). Across the three or four projects I'm interested in, a weekly CVS hookup is generally complete in about fifteen to twenty minutes. (36K modem). Clearly, I could reduce the connect time if I synced nightly (fewer deltas). Apart from that, you have the CVS utilities available to access file update logs, find out who committed what, when and where, and other whatnot (Such information is also avalable from http://cvs.gnome.org/bonsai as well for many gnome projects). Most of all, you are liberated from wondering if a patch set matches a code base, since your CVS working directory and the repository it is associated with have per-file version granularity. See http://www.gimp.org/devel_cvs.html My two U. S. cents Garry
Re: GIMP 1.2.0 and IRIX
Albert Chin-A-Young wrote: On Thu, Dec 28, 2000 at 01:12:28AM +0100, Sven Neumann wrote: Hi, snipped... Yes, the old format was braindead and while the new is still bad, it does not suck that much. We tried to keep backward-compatibility with the old format and this piece of code might bite you here. I can not reproduce the problem here, but you could help me to locate it by explicetely checking if you can load and use the pepper.gbr file (which provides the "Pepper" pixmap brush). I can successfully use pepper.gbr. File-Open loads it in just fine and I can select the brush in File-Dialogs-Brushes. FYI, I have no problems with Solaris 8/SPARC nor Tru64 UNIX 4.0D/5.0. snipped... Hi Al, Sven Just this evening (GMT -5.00) I've observed this phenomenon, on the same brushes that gave Al problems. Not on the Linux laptop, but on the SGI O2 and Indigo (Irix 6.5.8 and 6.5.4 respectively). I can spend some time isolating it, but not until this weekend. If I don't obtain resolution, I'll make summary comments in a bug report. Be good, be well Garry
Re: ANNOUNCE: GIMP 1.2.0
regis rampnoux wrote: snipped... And another trouble, when I launch The Gimp: gimp: Failed to load one of the brushes in the brush pipe "/usr/local/share/gimp/1.2/brushes/SketchBrush-16.gih" snipped... What is happening? This has been observed with Silicon Graphics systems; add yours to the list (what is your platform, by the way?) In a few places in brush code, we seek backwards when we fail to find fingerprints of optional data chunks. In doing so, however, we were naive about Very Large Files and the file systems that support them (yours, I gather, is among that number). For example, SGI has an XFS file system, supports multi-gig files, so that platform can employ 64 bits signed integers for file pointing, (off_t -- long long -- signed 64 bit integer). When we decided to seek backwards in a brush file, we were simply accepting the return value of "-sizeof(BlahFooeyChunk)". The return value of "sizeof" is size_t, an unsigned integer (32 bits), and while applying a unary negation operator to an unsigned quantity certainly flips the bits, the compiler (properly) retains the "unsigned integer" type. So, when the compiler encountered this value as the off_t (signed 64 bit) bytes-to-seek in the lseek() parameter list, it performed the default conversion: the unsigned 32 bit integer (with merely flipped bits) mapped to a 64 bit positive signed integer. So we were seeking very far in the wrong direction. Sorry about that. Casting sizeof() expressiions explicitly to off_t seems to clear up the problem. I believe this is being fixed and will be incorporated in the next stable Gimp (1.2.1) Real Soon Now. Be good, be well Garry -- P.S. I'm starting the new century with a new ISP; so my email address is changing: gosgood "at" idt.net -- grosgood "at" rcn.com BGBW -GRO
Re: gimp patch 1.1.32-1.2.0 [Also: Re: cmon guys, no patch from 1.1.32 to 1.2??]
Raphael Quinet wrote:
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.
snipped...
Reproduced from "Re: anonymous CVS is broken :(" thread, Jan-04-2001
Following courtesy of Tomas gren, striccommercial "at" signing.umu.se,
(who wrote...)
On 04 January, 2001 - Nix sent me these 0.5K bytes:
Whoever is providing anonymous CVS, it's broken.
Some of them are, not all.
Name:anoncvs.gnome.org
Addresses: 142.92.65.13, 192.58.206.110, 209.81.8.253, 130.239.18.151
Aliases: anoncvs.gimp.org
There are aliases anoncvs1.gnome.org - anoncvs4.gnome.org as well
1 and 3 (I admin #3) are working, 2 seems to not respond (routing
problems) and 4 has chmod problems. CC:ing the server admins.
As of this writing (Wed Jan 10 20:57:04 EST 2001) here's how the
pings go down from New York City
142.92.65.13PING anonvcs.gnome.org (142.92.65.13): 56 data bytes
64 bytes from 142.92.65.13: icmp_seq=0 ttl=241 time=240.624 ms
192.58.206.110 PING asterix.crl.dec.com (192.58.206.110): 56 data bytes
64 bytes from 192.58.206.110: icmp_seq=0 ttl=242 time=275.294 ms
209.81.8.253PING cvsonopn.varesearch.com (209.81.8.253): 56 data bytes
36 bytes from e2-1.community8-bi8000.valinux.com (198.186.202.94):
Destination Host Unreachable for icmp_seq=0
130.239.18.151 PING farbror.acc.umu.se (130.239.18.151): 56 data bytes
64 bytes from 130.239.18.151: icmp_seq=0 ttl=238 time=425.297 ms
Personally, CVS has made my life easier; no
need to sort out patch sets, and after the
working directory is in place, there are not
so vast amount of deltas that a refresh takes
any longer than 10-15 minutes (36K connection).
Plus, you can diff against earlier versions to
better track on-going code catastrophes ;).
Be good, be well
Garry
--
--
P.S. I'm starting the new century with a new ISP;
so my email address is changing:
gosgood "at" idt.net -- grosgood "at" rcn.com
Re: Bumpmap with negative Depth ??
lasm wrote: Hi All, snipped...I was trying to look for an engraved effect, the opposite of emboss, i.e. to make the thing look caved in, instead of popped out. Short answer: "Invert bumpmap" Long answer: Beware the sneaky qualities of human perception. Make a grey "altitude map" of a cone (white means "high", black means "low") 0. Grey field. R = G= B= 127. 1. Foreground color white, background color black 2. Blend tool. Options: Mode - Lighten Only. Gradient - Radial All other options default 3. Make a fuzzy white circle - the altitude map of a cone. 4. Filters-Map-BumpMap. Assuming default settings. Manipulate the preview until you find your cone. Now, one person perceives "light" streaming in from the northwest, highlighting a raised conical hill. But, not knowing the settings, another person perceives "light" streaming in from the southeast, lighting the northwest rim of a conical depression. Same bitmap. Different perceptions. You can flip the perceptions in your own head with a little practice, so one person's emboss is another person's intaglio. This arises from the simple, straightforward interpretation of the first derivative of the altitude map as a kind of "light". Unlike real light, there is an absence of other cues to give a sense of "real" height or depth. Given this phenomenon of dual perception, it is hard to "improve" the bump map plugin with "absolute" embossing or intaglio properties. Be good, be well Garry
