Re: [gimp-devel] Proposed Paint Core changes to support textures
David A. Bartold ([EMAIL PROTECTED]) wrote: > I dug into the paint core to see what needs to be changed to support > drawing on textured media. Here's the basic modifications necessary: > > * enum BrushApplicationHardness: > Add a new value "TEXTURE" which applies both pressure and > texture to a brush mask. It doesn't make sense to apply > only texture. Rationale: much of the realism afforded by > textures is due to the interaction between them and the > pressure an artist exerts on the medium. Have you considered making the texture dependant of the direction in which the user strokes the tool? This would be awfully cool. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] New Plugins
Tuomas Kuosmanen ([EMAIL PROTECTED]) wrote: > Speaking of old stuff to be ported to 1.2.. If I remember correctly, the 0.54 > version (yes, kids. It did exist and it ruled.) had antialiased Threshold > tool. Hmm - i just compiled gimp 0.54 and did not manage to find *any* threshold function. Can you give me a rough idea, if this is a separate plugin or how to invoke this function? A am considering to create a plugin for this... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] New Plugins
Martin Weber ([EMAIL PROTECTED]) wrote: > Now that we have the new gimp 1.2.0 out, we should think about adding > new plugins to the gimp. Here my proposal: Basically the number of plugins distributed with the gimp will most probably shrink. We are thinking about a new scheme of distributing plugins. There is no final result of this discussion. > 3. Not yet adopted to the new gimp, but stable in the old version: > quant.c from gimp-unstable-plugins from the old 1.0.4. gimp. quant used to crash sometimes deeply in the quantizing algorithm where I have no idea of > 4. Scripts: > lcd-downscale.scm Do you think, this script ios so importand it should be distributed with the Gimp? It has a fairly experimental nature... > warp-sharp.pl Is in Gimp 1.2. > warp-sharp.scm Do you think it is useful to duplicate the same functionality, just because it is implemented in two different Languages? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] FD leak in 1.2.0 Solaris?
Matthew Class ([EMAIL PROTECTED]) wrote: > With regards to the ulimit problem described on this list earlier, I > ran lsof on a running gimp, and there are 155 open files...looks like > all the palettes. This can't be good... This has been fixed in CVS. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: repetitive stress . . .
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. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Menus, shortcuts, and internationalization
Steinar H. Gunderson ([EMAIL PROTECTED]) wrote: > On Tue, Dec 12, 2000 at 03:31:07PM +0100, Simon Budig wrote: > >Huh? Netscape is "free software"? Do you have an idea what "free software" > >is about? > > One word: Mozilla. http://www.mozilla.org/. Netscape 6 is based on > Mozilla, although it has some extra proprietary add-ons. Well, you say it: Netscape < 6 is proprietary and Netscape =6 is partially proprietary. And Mozilla != Netscape - that is exactly my point... :-) > But yes: > Cutting and pasting works just fine in both NS6 and Mozilla here. On > both Windows and Linux. Probably it is impossible to do Alt-E + C for Copy and Alt-E + P for Paste. Thus it is impossible to Cut&Paste with Netscape >:-> Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Menus, shortcuts, and internationalization
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > Well, the great piece of free software called "Netscape" doesn't allow me > to cut & paste today, so I am going to have to retype a lot of stuff. Huh? Netscape is "free software"? Do you have an idea what "free software" is about? Anyway. Even Netscape as non-free software has a reply-button, which would include a quoted version of the mail *and* insert a correct "References"- Header so that a correct threading could be done... > > There is no way to resolve duplicates - and what does it help if the > > shortcut-key is the third letter of the Word you want to select? You > > want to accelerate your work - and decyphering from some accidentally > > underlined letter which is the current shortcut does not improve your > > speed. > > First of all that's why care is (or should be) taken when determining > which letters get underlined. Second, there is no posible way you are > going to run out of 26 letters of the english alphabet on the same > menu. Remember, these keys only work while you are on that particular > menu. Well - while this may be common/used for Languages with a non-latin alphabet it is IMHO not a good solution to have *two* shordcut- indicators like this: New (N) Alt-N Open(O) Alt-O Save(S) Alt-S Save-As (A) Alt-Shift-S While this is an example where the shortcuts can be assigned without having to choose total unrelated letters from somewhere in the alphabet it shows, that the menu-entries become nearly unreadable, because the user gets flooded with information (IMHO). > On most software packages (not for Linux, though), the > "underline" action keys are generally organized well enough so that it's > quicker to push that key instead of moving the mouse. For laptop users > this is true especially since most laptop mice don't have as much control > as standard desktop mice. If you ever tried to pick a menu item from a > 1024x768, 10" laptop screen , using a kludgy input device like a > touchpad or one of those pointing sticks, you would appreciate the ability > to push a key instead of moving the mouse. Dont argue with speed: Pressing Alt-F + x to exit a program is definitely more complicated than pressing Ctrl-Q. This goes double for nested menus. (As a sidenote: I dont think, referring to bad equipment does help us much in this case. Everybody, who touches up photos on a 10" LC-Display with a touchpad and expects a seamless workflow is nuts. You could also expect Gimp to run smoothly without restrictions on a text-terminal... :-) > Again, seems like the > dominating attitude around this area is "I *hate* alt-f-x style of > navigating the menus, so it must not be implemented". Hopefully these > examples describe this issue better than the original post. I said, that I wont be unhappy, if this remains unimplemented. *I* am not the one, who claims that something *must* or *must not* be implemented... [...] > I believe you are missing the point. Nobody is complaining about general > shortcut keys. Things like Ctrl+L are never going away. This has nothing > to do with the issue I am talking about, which is putting accelerator keys > on menu items to allow faster navigation once the menu is already open. You are talking about using Alt-F to open the File-Menu. Since you have to invoke the ->File Menu to be able to save images the general shortcut "Alt-F" would be lost for normal operations. (like repeating the last plugin). [Translation issues] > "File (F)" "Exit (x)" "Image (I)" etc. The ja.po file for gimp already > does this kind of things with the "File", "Xtns", and "Help" menu, and > others. This is not the most "pretty" way of doing it, but there is no > issue of having to "relearn" key combinations to get around menus. See above, why I dont like this notation. The underlining is quite unintrusive but relies on having the letter in the word... [...] > > it is blocking a huge amount of "regular" shortcuts. I *want* to use > > alt-f/e/s/v/i/l/t/d/r (note that the filters entry would probably end up > > with an "R" as a shortcut because all other letters are already > > occupied...)/G/V/C for something other than invoking menus. > > Sigh. Once again, you are missing the issue and exaggerating the > problem. The way Gimp's "image" menu was designed, there is no possible > way to do the "Alt-blah" thing to open it. Now if all that menu was on > top of the drawing area (like a normal menu type thing), then yes, one > would expect to operate that menu by doing Alt-F or Alt-I etc to open > it. But since the main menu is hidden until you right click, then it will > take that right click to open it. It is AFTER the fact that its open that > these shortcut keys come to use. In your original post you constantly complain, that "Alt-F" does not work. Extrapolating from that it is clear that the above mentioned Shortcuts should work the same way for a consistand user interface. The Idea for a special keypre
Re: [gimp-devel] Request To Revert Curve Tool
Garry R. Osgood ([EMAIL PROTECTED]) wrote: > > 2000-11-29 Austin Donnelly <[EMAIL PROTECTED]> > > > > * app/curves.c: Applied patch from David Hodson [...] > > 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 > > 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. Add me! > Alternately, I request an added toggle button to set the > preferred kinds of initial state. Maybe a better Idea would be (but this is definitely a new feature) to have some kind of history, where you can recall the last three (or so) curves... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: [lasm] Using the menu + "safe pointer"
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > I could be wrong and this key could be "customizable" too, but in my > experience, hitting the "r" key while inside an image changes your current > tool to "rectangular select" which I find to be the least "damaging" if you > accidentally click somewhere. Most of the toolbox actions fortunately DO have > shortcut keys. FYI: These shortcuts are indeed configurable, because the tools in the toolbox are the same as in the ->tools menu and thus have configurable shortcuts. Yeah. Those configurable shortcuts you blamed in your first message: > * Configurable menu shortcut keys? Who the fuck uses that? I would > rather see consistent menu hotkeys so I can do Alt-F-X to exit the > application rather than be able to customize what key I press to save > the image. Another useless feature, in my opinion. Personally I use configurable Menu shortcuts always and I'd pretty pissed, if they'd disappear. Personally I *hate* the "Alt-F-X" way to navigate the menus because: * There is no way to resolve duplicates - and what does it help if the Shortcut-key is the third letter of the Word you want to select? You want to accelerate your work - and decyphering from some accidentially underlined letter which is the current shortcut does not improve your speed. * it is inconsistent and impossible to translate between different languages (And I *do* switch between german and english): Now you can give hints like "Press CTRL-L to open the L&C-Dialog", this would be impossible with "If you use an english Gimp press Alt-D-L, if you use an german Gimp press Alt-D-E(benen)"... I remember the switch from Pagemaker 4 to 5: all shortcuts changed, because they changed their translation philosophy to translate the Shortcuts too: It was definitely a PITA. * it is blocking a huge amount of "regular" Shortcuts. I *want* to use Alt-F/E/S/V/I/L/T/D/R (note that the "Filters" entry would probably end up with an "R" as a shortcut because all other letters are already occupied...)/G/V/C for something other than invoking menus. (That said: A shortcut to open the -menu would be good, further menupoints could be reached with the cursor-keys.) IIRC we already discussed these issue when you brought up this thing some time ago. However, I dont remember a good solution for these problems and I'm unable to find the thread in the archive. So I guess this remains unimplemented - and I'm not unhappy about this. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: use of the Delete key on Dec keyboard or similar
Olivier Lecarme ([EMAIL PROTECTED]) wrote: > For programs designed after the PC has begun to be the dominant > computer, most implementors have taken as granted that a Backspace key > is meant to erase on left, and a Delete key is meant to erase on right. > This was the simplest solution for them, but it is fundamentally wrong. > I have the feeling to preach in the desert when I try to convince people > of that, but at least they should try to understand the problem, and > even try to find a solution which would work for everybody. Ok, Ill give it a try. Please specify, where in Gimp you notice the wrong behaviour. I cannot check this, since every Keyboard I have access to is a PC-Style Keyboard, where the X-Server maps the Key above the Return Key to the "BackSpace" Keysym and the key to the right of the return key to the "Delete" Keysym (as reported by xev, this is a SuSE-Linux right now) In an XTerm The "BackSpace"-Keysym deletes the character to the left of the cursor and moves the cursor one position to the left. The "Delete"-Keysym deletes the character under the cursor and does not change the cursor position. In both cases the text to the right of the cursor is moved one position to the left. In a randomly chosen Text-Entry field in the Gimp the behaviour is the same (but the cursor is a vertical line between two chars). So what exactly is the Problem? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: use of the Delete key on Dec keyboard or similar
Richard Stallman ([EMAIL PROTECTED]) wrote: > Gimp developers, I asked Olivier to report this because it is a > serious (though superficial) problem. Since the Gimp only runs under > a window system, it should be able to handle both Backspace and Delete > in the same way (as delete-backwards), since both of them can be > distinguished from the ASCII characters C-h and DEL. One Question: Where in Gimp is the handling of the Backspace/Delete Keys wrong? Probably in the GTK+-Widgets. So isn't this a general GTK+-Problem and should be discussed there? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: layer_get_offests(layerId, &x, &y);
Martin Edlman ([EMAIL PROTECTED]) wrote: > Simon Budig wrote: > > Hmm - it is definitely too late to change the Api to rename this > > function to "gimp_layer_offsets". But is there a special reason why this > > One way to make it sensefull and put gimp_layer_offsets to the API is to > rename the function and then > #define gimp_drawable_offsets(id,x,y) gimp_layer_offsets(id,x,y) > > or withou renaming the function just > #define gimp_layer_offsets(id,x,y) gimp_drawable_offsets(id,x,y) > > You keep compatibility and make happy those who want > gimp_layer_offsets(); No. You have to change it in the PDB, where those #defines are useless (they would only work inside libgimp). However, this problem is not a technical one. I just wanted to know, if there is a *reason* why this funcion is named oddly. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: layer_get_offests(layerId, &x, &y);
Sven Neumann ([EMAIL PROTECTED]) wrote: > Maneesh Yadav <[EMAIL PROTECTED]> writes: > > No one knows how to get the offsets for a layer from libgimp do they? > > Yes, we know. Since a layer is only a special kind of drawable, the > following call will perfectly do: > > gboolean gimp_drawable_offsets (gint32 drawable_ID, > gint *offset_x, > gint *offset_y); > To Quote from the description: : This procedure returns the specified drawable's offsets. This only makes : sense if the drawable is a layer since channels are anchored. The : offsets of a channel will be returned as 0. Hmm - it is definitely too late to change the Api to rename this function to "gimp_layer_offsets". But is there a special reason why this function can handle channels? It may lead to the wrong assumption that a channel is moveable too... Anyway, this is an inconsistency and nothing to be fixed before 2.0. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Tablet Troubles
the Loial Raven ([EMAIL PROTECTED]) wrote: > Pressure sensitivity is the problem... it seems like gimp is either > getting a pressure of 0%, 100%, or some value higher that causes feedback > when using some paint tools. I was thinking it was a problem with Xfree, > but when i used the xinputev, i found it was giving proper values... > > Before i switched to xfree 4.0 it was working fine... is there something > i've missed or a variable i haven't seen? A wild guess: Is it possible that the names of your pen and eraser have changed when you rewrote the configuration for XFree 4.0? If this is the case you have to re-enable the tools for gimp with the "Input Devices"-Dialog. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Types argument to gimp_install_procedure
Robert L Krawitz ([EMAIL PROTECTED]) wrote: > What happens if you specify RGB rather than RGB* as the image type > (I'm presuming RGB* means RGB or RGBA) and you get passed an image > with an alpha channel? Does the plugin refuse to run (or the Gimp not > allow the plugin to run on the image), or does the Gimp (or the > library) handle the alpha channel on the fly? Specifying "RGB" should disable the menupoint with RGBA images. However, IIRC doing a PDB-Call from a script-language does work. Most plugins do a sanity check at the beginning and return an execution error when the bit-depth does not match. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Gimp-Perl fails to build.
Simon Budig ([EMAIL PROTECTED]) wrote: > IIRC it was like this: > > (17. Nov.) > cvs co gimp > ./autogen --prefix=/unstable > make > make install I forgot something here: I did this make install as user simon (/unstable is mine) and perl of course did not install. I then did an additional make install in plug-ins/perl as root. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Gimp-Perl fails to build.
Marc Lehmann ([EMAIL PROTECTED]) wrote: > On Sat, Nov 18, 2000 at 04:54:39PM +0100, Simon Budig ><[EMAIL PROTECTED]> wrote: > > checkout of the gimp. Gimp-perl compiled and - after doing a separate > > make install as root in plug-ins/perl it worked. > > (BTW: Why is gimpdoc installed in /usr and not in my PREFIX?) > > See README.perl. It's where you told perl to install extensions. Hmm - IMHO at least for these additional files (not the module itself) the option specified at the top level ./configure should be inherited. >From README.perl I learn that I have only the chance to set one prefix. Wouldnt this install the Gimp-Perl module in /unstable (in my case) and perl would not find the module? BTW: The Perl installation happily installs the man-pages to /usr/local/man/man? while the scripts gimpdoc and xcftoppm reside in /usr/bin. This is inconsistent. > > However, in the desire to keep up to date :-) I did an cvs update > > and typed make in the top level source dir. > > > Makefile out-of-date with respect to Makefile.PL > > Cleaning current config before rebuilding Makefile... > > make -f Makefile.old clean > /dev/null 2>&1 || /bin/sh -c true > > this shouldn't happen. what were the exact commands you entered before the > make? I did definitely not mess around in the plug-ins/perl directory. IIRC it was like this: (17. Nov.) cvs co gimp ./autogen --prefix=/unstable make make install perl was OK at this time. (today after major changes in app/) cvs update make > > configure: warning: ** unable to find gimp > > ./configure: no: command not found > > ./configure: no: command not found > > ./configure: test: -lt: unary operator expected > > now *that* is strange ;) As I said: gimp-config and gimptool are not in my PATH... > > What is happening here? Why does the second build suddenly depend on an > > It tries to build as a standalone perl extension (so it tries to find the > gimp). This should not happen as the top-level configure script tells it > not to do so. I am not sure, if the make re-invoked the top-level configure script. > Did you configure the gimp tree without perl? What did you do to enable > gimp? Did you do make distclean and re-run autogen.sh? As I wrote before this was the second build counting from a fresh CVS Checkout. Normally the make re-invokes the autogen.sh script when it is necessary. > > Marc - could you please fix this behaviour so that people with zero > > knowledge about the Gimp-Perl build process could conveniently build > > It works for other people, actually, without any knowledge. The problems > only start when people replace Makefiles in the perl directory, usually ;) Ok, but this time I did not yet mess with the Makefile... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Gimp-Perl fails to build.
Hi. To revive the gimp-perl support for my gimp installation I did a fresh checkout of the gimp. Gimp-perl compiled and - after doing a separate make install as root in plug-ins/perl it worked. (BTW: Why is gimpdoc installed in /usr and not in my PREFIX?) However, in the desire to keep up to date :-) I did an cvs update and typed make in the top level source dir. The location of gimp is not in my normal path. However, for my rebuild of the gimp this should not matter, because it is older than the one I am compiling... Gimp Perl fails to build: - Making all in perl make[3]: Entering directory `/unstable/src/gimp/plug-ins/perl' Makefile out-of-date with respect to Makefile.PL Cleaning current config before rebuilding Makefile... make -f Makefile.old clean > /dev/null 2>&1 || /bin/sh -c true /usr/bin/perl "-I/usr/lib/perl5/5.005/i386-linux" "-I/usr/lib/perl5/5.005" Makefile.PL creating cache ./config.cache checking for gimp... no checking for gimptool... no checking for GIMP - version >= 1.0.4... no *** The gimptool script installed by GIMP could not be found *** If GIMP was installed in PREFIX, make sure PREFIX/bin is in *** your path, or set the GIMPTOOL environment variable to the *** full path to gimptool. configure: warning: ** unable to find gimp ./configure: no: command not found ./configure: no: command not found ./configure: test: -lt: unary operator expected checking for glib-config... /usr/bin/glib-config checking for GLIB - version >= 1.2.0... yes checking how to run the C preprocessor... cc -E checking for libgimp/gimpmodule.h... no checking for libintl.h... yes checking for unistd.h... yes checking for vsnprintf... yes checking for intelligent life... not found checking for _exit... yes updating cache ./config.cache creating ./config.status creating config.pl creating config.h now invoking perl to complete the configuration... + exec /usr/bin/perl Makefile.PL --writemakefile PREFIX=/usr FATAL: unable to deduce plugindir from gimptool script make[3]: *** [Makefile] Error 1 make[3]: Leaving directory `/unstable/src/gimp/plug-ins/perl' - What is happening here? Why does the second build suddenly depend on an installed (older) gimp? Even worse: after adding the location of gimp to the path gimp-perl ultimately fails to build: - Making all in perl make[3]: Entering directory `/unstable/src/gimp/plug-ins/perl' make[3]: *** No rule to make target `all'. Stop. make[3]: Leaving directory `/unstable/src/gimp/plug-ins/perl' - At this point the whole issue is no fun anymore and I usually replace the plug-ins/perl Makefile with: - all: echo "Gimp-Perl sucks." install: echo "Marc, please fix this." - Marc - could you please fix this behaviour so that people with zero knowledge about the Gimp-Perl build process could conveniently build Gimp - including gimp-perl - from CVS? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Thanks for Tablet Testing
Garry R. Osgood ([EMAIL PROTECTED]) wrote: > Simon Budig wrote: > > I wrote a small program to monitor the extended XInput-Events, it is > > attached. > > I've not had much time to investigate further on , but these are some trial > runs I get Built and run on ALICE, an SGI Indigo R4000, using MIPS 6.2 > compiler ALICE 35% xinputev --display harriet:0 (An SGI O2 Xsgi X-window > server Wacom 4.4.0 device driver) > Enabling No. 2: "wacom" (Type: 1) > Enabling No. 3: "mouse" (Type: 1) > Enabling No. 65244: "Core Pointer" (Type: 0) > button_press : device 3 pressure 0.500 button 2 > button_release: device 3 pressure 0.500 button -2 [...] > button_press : device 3 pressure 0.500 button 2 > button_release: device 3 pressure 0.500 button -2 > > In this configuration, button 3 release is consumed before > it reaches your code when using the mouse. My guess is, that the release events simply go to the menu when the mouse pointer is over it at this time. There seems to be a problem: [from http://www106.pair.com/rhp/sample_chapters.html ] : The X server automatically causes a pointer grab when a button is : pressed, and releases it when it is released. This means that the : button release event always goes to the same window that received the : button press event. Xlib allows you to change this behavior, but GDK : does not. (In the Xlib documentation, this automatic grab is referred : to as a "passive" grab. It's distinct from an "active" grab initiated : with gdk_pointer_grab(), described in Section 10.6.2.) Have a look also at http://ftp.x.org/pub/R6.4/xc/doc/specs/X11/CH12 . IIRC this only applies when the event mask contains both the GDK_BUTTON_PRESS_MASK and GDK_BUTTON_RELEASE_MASK. However, there seems to be a problem: Obviously this does not work with XInput-Devices. (Maybe they are "traditionally" something fundamental different than the "Core Pointer" and all higher level event processing is left to the application, and the "AlwaysCore"-mode does not respect this) So a solution might be: * when someone presses the button down, grab the pointer until the release event occurs (should be done on GDK-Level?) * prevent the invokation of the menu when the first button is pressed down (ugly!). Maybe this is also related to Bug #6901, "Can not continually move a floating selection with a pressure sensitive pointer."? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Thanks for tablet Testing [Re: Tablet Testing Needed]
Garry R. Osgood ([EMAIL PROTECTED]) wrote:
> Simon wrote:
> > When selecting something (e.g. tearing the menu off) the marching ants die.
> > When opening a new image they are alive for the new image.
>
> I Confirm this as well. Excellent, Simon, for you have brought forth
> the work-around to the problem for the poor Gimp user until this is
> resolved: When Marching Ants Die, Cntl-D for a New Image (I suppose
> saving the image first won't be such a bad idea). This creates a new
> Selection object for that image without an unbalanced pause count.
Heh - I didn't realize this... :-)
[does GTK handle the XInput-devices and the "normal mouse" in the same way?]
> At present, we know that is not entirely true in two mixes of hardware.
> However, the manner in which they are untrue appears essentially the same.
> I have, however, just read Raphael's well-documented response, and he
> is seeing quite different things. I need more time to reflect on his
> mail, but his results suggest that 10498 does have hardware
> dependencies. I think a sensible fix is not immediately forthcoming.
I wrote a small program to monitor the extended XInput-Events, it is
attached. For my Artpad II it shows a strange thing: If I press the "right"
Pen-Button when pressing the Pen on the tablet, each motion event is
surrounded by proximity in and proximity out events for the
eraser side of the pen. This is probably a bug in the XFree-driver
or a bad tablet-protocol. There is a strange comment in the Driver
source (The Artpad II speaks the Wacom 4 protocol, Intuos Wacom 5:
if (common->wcmProtocolLevel == 4 &&
!(common->wcmFlags & GRAPHIRE_FLAG)) {
/* The stylus reports button 4 for the second side
* switch and button 4/5 for the eraser tip. We know
* how to choose when we come in proximity for the
* first time. If we are in proximity and button 4 then
* we have the eraser else we have the second side
* switch.
*/
Maybe there is a bug in the XFree86 driver with this assumption?
My demo program is simply compiled with
gcc -o xinputev xinputev.c `gtk-config --libs --cflags`
When invoked with an additional argument it does report the motion
events too. When you press the right button it invokes a
submenu without any function. You can see, that under certain
circumstances the release events for the buttons 1/3 dont reach the
main window.
Bye,
Simon
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
/* XInputEV -- a program for monitoring XInput-Events
* Copyright (C) 2000 Simon Budig <[EMAIL PROTECTED]>
*
* Distributed under the terms of the GNU GPL.
*
* compile with
* gcc -o xinputev xinputev.c `gtk-config --libs --cflags`
*/
#include
#include
#include
#define EVENT_MASK ( GDK_PROXIMITY_IN_MASK | \
GDK_PROXIMITY_OUT_MASK | \
GDK_BUTTON_PRESS_MASK | \
GDK_BUTTON_RELEASE_MASK | \
GDK_POINTER_MOTION_MASK )
GtkMenu *menu = NULL;
GtkWidget *menupoint = NULL;
/* Event-Handler */
gboolean
printevent (GtkWidget *widget, GdkEvent *ev, gpointer user_data)
{
GdkEventButton *bev=NULL;
GdkEventMotion *mev=NULL;
GdkEventProximity *pev=NULL;
GtkWidget *win = NULL;
switch (ev->type)
{
case GDK_BUTTON_PRESS:
bev = (GdkEventButton *) ev;
g_printerr ("button_press ");
if (bev->button == 3)
gtk_menu_popup (menu, NULL, NULL, NULL, NULL, 3, GDK_CURRENT_TIME);
break;
case GDK_2BUTTON_PRESS:
bev = (GdkEventButton *) ev;
g_printerr ("button2_press ");
break;
case GDK_3BUTTON_PRESS:
bev = (GdkEventButton *) ev;
g_printerr ("button3_press ");
break;
case GDK_BUTTON_RELEASE:
bev = (GdkEventButton *) ev;
g_printerr ("button_release");
break;
case GDK_PROXIMITY_IN:
pev = (GdkEventProximity *) ev;
g_printerr ("proximity_in ");
break;
case GDK_PROXIMITY_OUT:
pev = (GdkEventProximity *) ev;
g_printerr ("proximity_out ");
break;
case GDK_MOTION_NOTIFY:
mev = (GdkEventMotion *) ev;
g_printerr ("motion_notify ");
break;
default:
g_printerr ("Unknown Event\n");
}
if (bev)
g_printerr (": device %5d pressure %6.3f button %d\n",
bev->deviceid, bev->pressure,
bev->type == GDK_BUTTON_RELEASE ? bev->button * -1 :
bev->button );
if (pev)
g_printerr (": device %5d\n", pev->deviceid);
if (mev)
g_printerr (": device %5d pressure %6.3f\n",
Re: [gimp-devel] Tablet Testing Needed!
So. Finally I could do some test with my Intuos A5 and my Artpad II. Garry R. Osgood ([EMAIL PROTECTED]) wrote: > 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) Notebook, Celeron 333, XFree86 3.3.6, Intuos A5: I get a context menu. For the misbehaviour I do not need to be inside the selection. If I make a selection, select e.g. a paint-tool, paint someting (in- or outside the selection) and while pressing the pen down press the "right mousebutton" a menu pops up. When selecting something (e.g. tearing the menu off) the marching ants die. When opening a new image they are alive for the new image. This also happens without the "AlwaysCore" mode. Then the mousepointer does not move with the tablet. Setting the Mode of the pen to "Window" lets gimp draw its own cursor, the tablet is mapped to the image window. Create a selection, select a paint tool and move the core pointer to the image, using the mouse. Then use the pen to paint something and press the right button of the pen. The menu will open. Selecting something makes the ants die. The Artpad II is interesting too: IIRC the protocol is a little bit fuzzy about the difference between tapping on the tablet and pressing the right button vs. the eraser side of the pen. The XFree86-Driver starts switching between the Pen and the Eraser very fast. Sometimes the ants die, sometimes not. The behaviour is unclear. > 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. I can confirm this. Additionally pressing the right button of the mouse when the pen is pressed onto the tablet will also be ignored. > 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 I believe Simon > has a tablet/driver/machine quite different from an SGI O2. [See Re: > Gimp help docs thread]] It is possible that the graphire Marc had is more similiar to the Artpad than to the Intuos. I will dig a little bit in the XFree86-Driver. Hopefully we can fix this in a sensible manner. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Python-Plugin for Gimp - what happened?
Hi all. I'd like to know what happened to the Pygimp-Plugin. There is a strange comment in Makefile.in: # This has been modified slightly. The Makefile.am file has been moved to # Makefile.am.14 because it uses some non standard extensions. This should # be resolved when automake-1.5 comes out. I guess, the non-existance of Makefile.am is the reason why the plugin will not be build, even with --enable-python. Is there a special reason for the need of the latest automake features? I have no clue about these tools, so could someone please help? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Tablet Testing Needed!
Garry R. Osgood ([EMAIL PROTECTED]) wrote: > I was delighted this weekend to uncover a cause to #10498: "Marching > Ants die untimely deaths" which has been pestering me for sometime > now. Whoo ho! > 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 I believe Simon > has a tablet/driver/machine quite different from an SGI O2. [See Re: > Gimp help docs thread]] I have at the moment no tablet available so i cannot try to reproduce this now. I definitely will try this tomorrow. But the Machine at the systems was an Intel-Machine with 128 MB Ram. The tablet was an Intuos A5 with serial connector plus lots of different pens (3 intuos Pens, 2 Stroke pens, 1 Airbrush, 1 4D-Mouse, 1 inking pen), the X-Server was a 3.3.6 XFree86. Thanks for hunting in this area! Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Hispalinux talk / demo
Daniel Egger ([EMAIL PROTECTED]) wrote: > On 28 Oct, Tuomas Kuosmanen wrote: > > No clue. Is this a "they want someone to do a demo" or "who the heck > > is going to do a gimp demo there??" > > BTW: I'm going to show GIMP at the COMDEX in Las Vegas at the SuSE > booth While we are at it: At the Systems 2000 in Munich will be a (small) Gimp-Booth at the Linux-Park. Marc Lehman, Lukas Grunewald, me and (hopefully) Carey Bunks will present the Gimp... :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Systems Fair 2000 in Munich
Hi all. >From 6th to 10th November the Systems 2000 (www.systems.de) will be in Munich. Among others there will be a small Gimp-Booth. Do YOU want to help presenting Gimp? There is still one room reserved for a gimp-staff member. Please contact me if you are interested. Thanks, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: 3D paint interface.
Stephen J Baker ([EMAIL PROTECTED]) wrote: > > Unfortunately, you can't communicate that tightly with the core > > application from a plug-in. You're limited to the language of the PDB. > > Doh! > > How do devices like digitizing tablets interface to GIMP? Perhaps > there is a way for me to pretend to be something like that. Graphics tablets use a standard X11-way to communicate: the XInput-devices. So you would have to implement a X11-driver for your "virtual" pen or talk the (e.g. ArtPad) Tablet protocol to a named pipe where the X-Server reads it. This "tablet" must not run in "Core-Pointer" mode, since you probably want to use the mouse to use your program. Another idea would be to fake events and send them to the Image-Window. Both ways sound nasty... Probably Gimp does ignore events when the image window is not active. You would have to work around hundreds of strange effects... I'd guess Gimp 2.0 would support "module tools", where something like this could work. Now you are limited to things like the gimp-paintbrush PDB-Call (as mentioned by Kevin) which might help a little bit. But it definitely sounds interesting... :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] xpm output: is RGB a legal xpm format?
Uwe Koloska ([EMAIL PROTECTED]) wrote: > With this (and possibly later versions) it is possble to save an RGB image > to xpm format. I don't know the xpm format, but the xpm code from kde 1.1 > isn't possible to load such an not-indexed xpm image. > > So two questions: > o is it legal to save an xpm image in not-indexed format? > o is the header of this not-indexed format right? Maybe there is missing > the indication for the RGB format AFAIK the xpm format does not make a difference between "indexed" and "rgb". From the xpm point of view everything is indexed - with an arbitrary number of colors. With a small number of colors it assigns every color an character - you can easily understand the format if you read an xpm file. However with this you run into problems if you have more than ~ 100 colors, because then you would have to use nonprintable/non-ascii characters. So the xpm-format can use strings (of the same length) for different colors: "aa" could be red, "ab" green etc. So the strin "aaab" would mean a red and a green pixel. I believe this is standard, this bug should be fixed in KDE. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Gimp to MacOS
Arnaud Masson ([EMAIL PROTECTED]) wrote: > I have ported a big part of gtk+ to MacOS 9, it's on mac-gtk at > SourceForge. > IT'S ALIVE ! ;-) > The GDK port is based on QuickDraw+WindowMgr, and Justin Armstrong has made > changes for carbon support. > Of course, on MacOS X, he uses a standard unix glib (I must use the GUSI > posix emulation on the classic MacOS which is not easy for the process > stuff). Unfortunately I dont have a mac but... THIS IS DEFINITIVELY GREAT NEWS! > AND... I have a minimal version of Gimp running on MacOS 9 ! > There are still a lot of bugs but at least I can paint some flowers with the > brush tool... Yow! > Currently I don't have much time for GTK because I am on holidays (far away > from my G4) so you should contact Justin for the MacOS X port. World domination for Gimp! ;-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Gimptool in Gimp 1.0.4
Marc Lehmann ([EMAIL PROTECTED]) wrote: > On Tue, Aug 01, 2000 at 02:26:49PM +0200, Simon Budig ><[EMAIL PROTECTED]> wrote: > > Argh - OK. I forgot the Script-fu scripts. But adding plugins is > > impossible w/o gimp-devel, because the libgimp header files are > > unavailable. > > I don't think so: You don't need header files to add a plug-in. You only > need gimptool. The header files are only required when compiling a plug-in > from source. So you can obtain precompiled plugins from the registry? Anyway. I am not really happy about the descision to put gimptool in the gimp-devel package. But it will fail to work for installing plugins from c-source, so technically speaking it *has* a dependency on gimp-devel and it is perfectly reasonable to put it in gimp-devel. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Gimptool in Gimp 1.0.4
Marc Lehmann ([EMAIL PROTECTED]) wrote: > On Tue, Aug 01, 2000 at 11:49:26AM +0200, Simon Budig ><[EMAIL PROTECTED]> wrote: > > IIRC gimptool is in the gimp-devel package, which makes sense, because > > all uses (except determining the Gimp Version) are developer-related. > > So, adding scripts you downloaded from the registry is developer-related? > > (it's definitely not _that_ clear). Argh - OK. I forgot the Script-fu scripts. But adding plugins is impossible w/o gimp-devel, because the libgimp header files are unavailable. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Gimptool in Gimp 1.0.4
Robert L Krawitz ([EMAIL PROTECTED]) wrote: [gimptool not in Red Hat Gimp RPM] > Any suggestions? Is Red Hat broken, or is it our configure script? IIRC gimptool is in the gimp-devel package, which makes sense, because all uses (except determining the Gimp Version) are developer-related. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: The undo stack does not record some changes in layer attributes
Tom Rathborne ([EMAIL PROTECTED]) wrote: > On Wed, Jun 07, 2000 at 04:25:49PM +0200, Sven Neumann wrote: > > I still believe that it is a bad idea to waste undo steps for > > operations that don't save any shadow tiles. > > I agree. If I'm on a machine with limited resources and have the GIMP > set up for only, say, 8 levels of undo, I don't want to lose the > ability to undo image changes just because I toggle a few layers on > and off. Agreed... :-) > The undo history dialog should probably note which actions count as > "undo levels" and which don't. Also, it would be nice to be able to > force a tile-changing undo (e.g. with Ctrl-Shift-Z) ... if you do 30 > layer moves/visbility changes then you probably don't want to have to > hit Ctrl-Z 30 times just to undo your last pixel change. This comes very close to the idea of micro- vs. macro undo's we discussed at the gimpcon. Ctrl-Z could undo the last micro-operation: Toggling visibility, undo the last stroke... and ctrl-shift-z could undo all operations of the same type: Lets say we have the following operations on the stack: Stroke with Brush Stroke with Brush Bright/contrast Bright/contrast Bright/contrast Bright/contrast Bright/contrast Stroke with Brush Stroke with Eraser Stroke with Eraser Stroke with Eraser Ctrl-Z would work as usual, Shift-Ctrl-Z would undo the last three steps (all erasing) then the single brush-stroke (like ctrl-Z) and then all contrast-changes However, this is probably not possible for 1.2. I have no real clue of the undo system, but it may be possible that Brush and Eraser are currently undistinguishable for the Undo-system. To hack around this we could set some kind of flag to the current undo-step when the tool changes or the operation is fundamentally different from the previous. Ctrl-Shift-Z would then jump to the next undo-step with this flag set... Just my 0.02 DM. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
LinuxTag: Sorry, im unavailable right now.
Hi all.
Currently our local university has massive problems with the net so
I'm currently not normally reachable via EMail. If you need to urgently
reach me try the Adress <[EMAIL PROTECTED]>, this is especially targeted
to all people who contacted me for the Gimp-Booth at the LinuxTag.
Sorry, currently I'm nearly cut off from my EMail-Communication.
Sorry for the inconvenience.
Bye,
Simon Budig
--
--
currently not reachable via [EMAIL PROTECTED]
Sent through GMX FreeMail - http://www.gmx.net
Re: [gimp-devel] Re: Questions to the Opensource community
Soeren Staun-Pedersen ([EMAIL PROTECTED]) wrote: > On Mon, 22 May 2000, Rickard [iso-8859-1] Nordström wrote: > > Hello there ! > > We are two students writing our master thesis about Open Source > > Software. If you have any experience in developing Open Source Software, > > Would it be okay to reply to the list? I am considering going open source > with a company project, so any replies to this mail will interest me too. > So, don't reply private, reply to list please :-) I'd prefer if you ask them per private mail if they can share their results. Personally I dont want hundred mails with non gimp-devel stuff... Thanks, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Proposal for new gimp_tips.txt
Sven Neumann ([EMAIL PROTECTED]) wrote: > > You can save a selection to a channel (Select->Save to Channel) and > > then modify this channel with any paint tools. Use the "Channels" tab > > in the "Layers, Channels and Paths" dialog to toggle the visibility of > > this new channel and to perform various operations on it. > > Huh? This is misleading. The Channels tab does not toggle the channels > visibility. That sentence needs to be rewritten. This Tip should be changed to a pointer to the Quick-Mask option. This is the easier way to do the same thing. Maybe something like You can use the paint tools to change the selection. Click on the quickmask button at the bottom left of an image window. Change your selection by painting in the image and click on the button again to convert it to a normal selection again. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Gimp-booth at the biggest european Linux-fair.
Hi all. In about two months the biggest Linux Fair in Europe will take place. The Linuxtag will happen in Stuttgart, Germany from 29.6.-2.7.2000. Further information can be found at www.linuxtag.de. The reason why I write this to this list is simple: I'm searching for people, who are willing to help me with a Gimp-booth. Four days are a lot of work for a single person :-) >From my personal experience the Linuxtag is a really great event where you can meet interesting people and *lots* of interested people. There are two ways to help: The most obvious way: Presenting Gimp at the booth. Who can help one or more days at the booth and show clueless newbies how to draw straight lines and show professionals, why Gimp is more flexible than Ph*t*sh*p? Unfortunately it is unclear at the moment, if it is possible to pay a flight or a room. Ill try to organize some money - probably the group organizing the Linuxtag has a budget for free projects. If you are interested please tell me if it is possible for you to come: - if somebody pays flight and hotel room - if somebody pays a flight and provides place for a sleeping bag - if somebody pays a hotel room - if somebody provides a place for a sleeping bag - without restrictions. The other way to help is: provide place for a sleeping bag :-) I look forward to hear from you. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] [Fwd: Re: Export behaviour for fully transparent backgrounds]
Garry R. Osgood ([EMAIL PROTECTED]) wrote: > (2) I trust the user in choosing between information > content and compression, so long I walk the mile in telling her > that this is a choice to be considered. Then she can write/invoke the > macro or deliberately set R = G = B = A = 0 in all regions deemed > transparent before writing out to file. IMHO we should not remove any "unnecessary" information until the user explicitely chooses it. It is a great feature if the unerase works on an PNG... > (3) If someone wants to write something in Gimp core or the png > plug-in to automagically clean up after the user, it's presence should > be made known and its activation optional. It is fairly trivial to write a plugin to remove the unnecessary color-information. Either steal code from the semiflatten plugin or extend the semiflatten plugin to export a second PDB-function to remove the UCI. If nobody else works on this currently I can do this this weekend or so. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: JPEG correction (was Re: Gimp Wishes)
Jon Winters ([EMAIL PROTECTED]) wrote: > The only manipulation I can think of that would benefit from "lossless" > jpeg would be rotating the image. (if I were shooting low-rez) I > remember seeing some tools at the JPEG F.A.Q. site that would rotate a > JPEG without damage. http://www.faqs.org/faqs/jpeg-faq/ This lossless operations depend heavily on knowledge about JPEG internals. They operate without de- and recompressing the image data. You can use them with tools like jpegtran . However, this is nothing to embed into Gimp. Gimp has a totally different approach on storing image data and it is virtually impossible to preserve the JPEG-internal data (parasites for all JPEG-Coefficients - Urgh... ;-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Gimp Wishes (efficient trivial wishes)
Karl Heinz Kremer ([EMAIL PROTECTED]) wrote: > [EMAIL PROTECTED] said: > > Please note that adding "tags" to the messages will mean that GIMP > > isn't usable any more without catalogs which is not very sensible > > IMHO. I'd rather refine the messages to have more variance in the > > texts... > > Why should English be treated differently than any other language? > Let's just add an English catalog to the default installation and > the user will not see any difference. Until he disables nls-support. Some users want this. And then english is better than some crude tagged semi-english. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] 1.1.19 bugs and questions about pixmap brushes
Raphael Quinet ([EMAIL PROTECTED]) wrote: > So my question is: could someone explain what these parameters mean > and how to save a .gih brush in the correct format? Specifically, I > have a set of layers that were originally grabbed from a .GIF > animation and I would like to save them as a pixmap brush, so that I > can follow a path with that brush and get some nice effects. I tried > various tricks with the guides, with the number of cells in the .gih > save dialog and so on, but I did not manage to get the effect that I > wanted. I only managed to crash the Gimp... :-( The GIH was broken, when I tried it some time ago. I dont know if somebody fixed it there. I always had to "vim -b foo.gih" and fix the strings with the options. It did help to RTFS to do this. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: "Global Locking" for Gimp :-(
Sven Neumann ([EMAIL PROTECTED]) wrote: > > Is there any chance to do this on an "per image" base without > > hazzeling too much? > > It's not only parallel operations on an image. Gimp doesn't like you to > change the tool while it is active. So you can't rotate an image (using > the transform tools; using the rotate plugin should work) and change to > the paint-tool to paint even if you do this on another image. Tools are > global, so we have to disable tool-changes globally. Oh - forget my other mail then. Hmm - maybe the current way is the best we could get for 1.2... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: "Global Locking" for Gimp :-(
Austin Donnelly ([EMAIL PROTECTED]) wrote: > On Monday, 27 Mar 2000, Simon Budig wrote: > > Is there any chance to do this on an "per image" base without > > hazzeling too much? > > I proposed to add per-image locking a while ago, but apparently this > wasn't too well liked. I'm can't remember why. > > There are 2 tricky parts (as far as I can see): > > A) plug-in.c needs to take out an image lock when starting a plugin > operation, and release it on normal (or equally importantly) > abnormal plugin termination. > > B) what happens when acquiring a lock fail? Do you queue the > operation up on the lock (hard) or do you fail it (easy)? I think, proper locking is among the first things that should go in Gimp 1.3. However, it may be a little bit late for 1.2 :-( What Im thinking about is: Every user action starts in the image window. When we prevent a) clicks in the image to take effect b) selection of menu items (graying out?) if this image is "locked" we have a lot of potential crashes fixed. We could even give some sort of feedback through the cursor. Well, when a script or plugin randomly accesses the locked image then this is bad luck, but I think this should not happen too often. The way described above eventually could be handled inside the callbacks. Mitch: Do you see a chance to get it working this way? Is this reasonable? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
"Global Locking" for Gimp :-(
Hi all. I see, that Gimp can be crashed very easily when trying to use multiple tools at the same image/layer. Michael adressed this: from the changelog: 2000-03-25 Michael Natterer <[EMAIL PROTECTED]> * app/cursorutil.[ch]: new global variable "gimp_busy" which gets set/unset whenever busy cursors are added/removed. [...] Here starts the ugly workaround which simulates something like locking. If it works, it will close lots of bugs, if not, it's easy to remove again. So far, I didn't find strange side effects but Gimp is told to be a complex program :-) Please test this. Well - unfortunately this disables "user multitasking" with working on multiple images. Admittedly I dont do this too often, but sometimes it is nice to paint something while waiting for a big image to rotate. (just tested - multiple plugins do work! :-) Is there any chance to do this on an "per image" base without hazzeling too much? Or - if this is too hard to implement - do you think that this limitation is better than crashes which could be avoided if the user knows that parallel operations on an image will fail and result in data loss? I do not know, what is the better way, but I think global locking is a big limitation... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] XFree86 4.0 and Wacom Tablets.
Garry R. Osgood ([EMAIL PROTECTED]) wrote: > Simon Budig <[EMAIL PROTECTED]> > > > > > 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. Hmm... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Making Pencil more useful.
Hi all.
Most brushes are quite useless with the pencil, since it treats even an
opacity of 1 as fully opaque. I just fiddled around a little bit in
paint core and tried the following:
simon@cantaloop:/unstable/src/gimp/app> cvs -z3 diff -u ./paint_core.c
Index: paint_core.c
===
RCS file: /cvs/gnome/gimp/app/paint_core.c,v
retrieving revision 1.86
diff -u -r1.86 paint_core.c
--- paint_core.c2000/03/05 00:06:09 1.86
+++ paint_core.c2000/03/26 21:11:11
@@ -1366,7 +1366,7 @@
data++;
for (j = 0; j < brush_mask->width; j++)
{
- *data++ = (*src++) ? OPAQUE_OPACITY : TRANSPARENT_OPACITY;
+ *data++ = (*src++) >> 6 ? OPAQUE_OPACITY : TRANSPARENT_OPACITY;
}
data++;
}
--
this sets the threshold to 64. Suddenly the brushes are recognizeable... :-)
What do you think? Does this break something? The best way would be to make
it configurable, but then this is definitely a new feature ;-)
Bye,
Simon
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Gimp User Installation Dialog / XFree86 4.0
SHIRASAKI Yasuhiro ([EMAIL PROTECTED]) wrote: > >* There seems to be a problem with the big titles. As you can see > > at http://www.home.unix-ag.org/simon/gimp/GimpUserInstallation.png > > the title of an page gets cut off (Gimp CVS from > > Sat Mar 25 02:01:18 CET 2000 ). > > Are you using XFree86 3.9.x or 4.0? Ah yes, this might be the problem... Any ideas? 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... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
bugs.gimp.org
Can somebody change the redirection from bugs.gimp.org? http://www.wilberworks.com/bugs.cgi is nonfunctional and depreciated. The target url should be http://bugs.gnome.org/db/pa/lgimp.html Thanks, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Gimp User Installation Dialog.
Hi. First congratulations for the new User-Installation Dialogs. But I cannot resist to comment on it :-) * There seems to be a problem with the big titles. As you can see at http://www.home.unix-ag.org/simon/gimp/GimpUserInstallation.png the title of an page gets cut off (Gimp CVS from Sat Mar 25 02:01:18 CET 2000 ). * The dialog is quite huge, it does not fit on a 640x480 screen completely. Do we need to fix this? * Personally I dont like the orange color. I prefer blue, but this is personal preference. I tried an alternative layout (with Gimp - not C :-) (moving Wilber to the right, blue color) and created another Wilber-Icon with a helmet on to indicate that there is real Work going on :-) You can see a pseudo-screenshot at http://www.home.unix-ag.org/simon/gimp/GimpUserInstallation2.png The XCF of the new Wilber is available at http://www.home.unix-ag.org/simon/gimp/wilber_work2.xcf.gz What do you think? The defaults from gimprc are questionable IMHO. The default imagesize is not specified and defaults to something around 950x760, which is pretty close to my screen resolution. Maybe we should default to something like 300x300 ? Is there a reason, why (install-colormap) is not enabled by default? Gimp needs pretty much colors and probably wont start on most systems with 8bit color. Enabling this has no negative impact on Truecolor users. So if somebody really uses gimp as the only application on an 8bit screen he can switch this Option off manually to avoid flashing. The default toolbox-layout is IMHO ugly. Should we default to the layout with three columns? This has the positive effect that people updating from Gimp 1.0 will not be confused unnecessary. Opinions? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
Raphael Quinet ([EMAIL PROTECTED]) wrote:
> > Are there really multiple different executables named "perl" (not "perl4" or
> > so!) in your path? So when you work in your shell you always execute
> > version 4 of perl, when you invoke "perl"?
>
> I suppose that Marc meant that the person running a Perl-Fu script
> might not the the person who has configured and installed it. It is
> likely that the one who configures the Gimp has set his path correctly
> (in order to be able to run configure without errors) but it can
> happen that another user has a broken path, with old tools listed
> first. In that case, the user would get a different version of perl
> than the one that Gimp was configured with.
I see the point. So it is probably really the best to hardcode the
path to perl at ./configure-time. Though I dont like situations as in
your example. This is a perfect way to create great confusion among the
users... ("But it works for me! Why?")
> I think that the only way to guard against users having a broken path
> is to hardcode the location of the perl executable in the scripts.
> Actually, this should also be done for python because using "env" will
> create exactly the same problems.
Using "env" is much more portable than always using "/usr/bin/python".
Determining the location of the binary at compile time is a good
compromise IMHO. So where is our autoconf/automake guru? :-)
> Just to give you an example, there are several versions of Perl in my
> path on one of the systems I use at work:
>
> $ /usr/bin/perl -v
> This is perl, version 5.003 with EMBED
> $ /opt/local/bin/perl --version
> This is perl, version 5.004_04 built for sun4-solaris
> $ /Local/bin/perl --version
> This is perl, version 5.005_03 built for sun4-solaris
Ouch!
> There are also some older versions of Perl available, but fortunately
> they have been renamed (e.g. perl4, oldperl) so that they are not used
> by default.
/me wants to say "please fix the version chaos on this machine" but
I understand, that there are Systems with lots of perl installations
where the Gimp-Admin is != Perl-Admin...
Bye,
Simon
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
Marc Lehmann ([EMAIL PROTECTED]) wrote: > On Mon, Mar 06, 2000 at 04:16:04PM +0100, Simon Budig <[EMAIL PROTECTED]> >wrote: > > There is a better way. > > This might work for python, but it will not work for perl. It will find > the first perl in your path (which is often perl4), not the perl gimp > was configured with. Are there really multiple different executables named "perl" (not "perl4" or so!) in your path? So when you work in your shell you always execute version 4 of perl, when you invoke "perl"? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: The virtuall CVS checkin (aka the TODO list) (fwd)
Hi all.
Xach missed the CCC-Notes, here they are again ;-)
Bye,
Simon
- Forwarded message from Sven Neumann <[EMAIL PROTECTED]> -
X-Mailer: exmh version 2.0zeta 7/24/97
To: Olof S Kylander <[EMAIL PROTECTED]>
Cc: Michael Natterer <[EMAIL PROTECTED]>,
Simon Budig <[EMAIL PROTECTED]>
From: Sven Neumann <[EMAIL PROTECTED]>
Subject: Re: The virtuall CVS checkin (aka the TODO list)
Date: Thu, 12 Aug 1999 21:24:00 +0300
Hi Olof,
> It was a very nice weekend (CCC camp) and I hope I can meet you all again.
> Anyway I hope that you all had some luck with the eclipse. Below is the
> edited todo list. Any questions just mail me otherwise I will send it to
> the mailing list as a post from us all Friday or Saturday.
>
Yes it was indeed very nice to be at the camp! The eclipse wasn't as
impressing as I hopes it to be due to the fact that it was raining and we
haven't seen the total eclipse phase at all. However the moment when the
light went off was pretty chilling...
I have attached an overworked version of your TODO proposal. These are only
small formatting changes ( and I changed tile cash to tile cache ).
Salut, Sven
Start
-
Hello Gimpers!
As some of you may know, we (Sven, Mitch, Simon and Olof) have had a
Gimp session at the CCC camp in Berlin. Naturally, this resulted in a lot
of hacking and we have added some nice new features to Gimp.
Most of our current project is not finished yet, and some of the features
aren't in a presentable state, so we can can't commit them now. But
freezing Gimp without adding these new features makes some of our work
quite useless. We have therefore redefined the meaning of "feature freeze",
and hereby add those features (listed below) to the development version of
Gimp. You can consider them virtually checked into the current CVS tree :-).
**
* Features added by Sven, Mitch, Simon and Olof into the *
* current CVS tree as of 8 August 1999, Berlin Germany: *
**
*Drag&Drop*:
Channels-> drag channel to toolbox to create new image
(both grayscale and RGB)
-> drag alpha channels to image to add channels to
that image (both single and multiple
selected channels)
-> drag color from color selection dialog or
fg/bg color swatches to colorify channel
Layers -> drag to palette (new palette from the current
layer)
-> drag to brush (new brush from layer)
-> drag to pattern (new pattern from layer)
-> drag to gradient (extract palette and
distribute in HSV space :-)
-> drag to layer mask
Selected layers -> the same functions as for Layers
Layer Masks -> the same functions as for Layers
Image -> drag image to layer dialog to create new layer
of image (select (modifier key) to drag
all visible layers or just the active
layer)
-> drag image to layer mask (select (modifier key)
to drag all visible layers or just the
active layer)
-> drag image to channel (select (modifier key) to
drag all visible layers or just the active
layer)
-> to palette (new palette from the active layer)
-> to brush (new brush from image)
-> to pattern (new pattern from image)
-> to gradient (extract palette and distribute :-)
File-> drag filename (from the File Open dialog) to
layer
-> to layermask
-> to channel
-> to palette (new palette from the active layer)
-> to brush (new brush from image)
-> to pattern (new pattern from image)
-> to gradient (extract palette and distribute :-)
Toolbox -> drag foreground color in fg/bg color swatch to
background or vice versa
-> drag color, pattern or gradient to status
dialog
Path-> drag selected paths to image (will copy paths
from one imag
Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > -- Problem description: > Path to PERL do not have to be: > #!/usr/bin/perl > it's somewhere else at my system... > -- How to repeat: > Try to compile with PERL installed somewhere else... > -- Other comments: > Should be set in ./configure correctly... There is a better way. If the scripts start with #!/usr/bin/env perl env will search for perl in the path and start it. From the env info-page: The first remaining argument specifies the program name to invoke; it is searched for according to the `PATH' environment variable. Any remaining arguments are passed as arguments to that program. I submitted a similiar bug-report for pyton to the list, but noone cared to apply it. I do not have CVS-write access so I cant fix it. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Some Python-fu Plugins fail with a nonstandard python installation. Fix attached.
[This should go to [EMAIL PROTECTED], but this complained about a missing Package-header. Can't the tracking System handle Mime-Mails?] Package: gimp Version: CVS from 19.2.2000 2 Python scripts fail to start with a nonstandard python installation since the path to /usr/bin/python is hardcoded there. The attached patch fixes this by using "#!/usr/bin/env python" (as usual). The diff was created in $GIMPSRC/plug-ins/pygimp/plug-ins/ Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ Index: pdbbrowse.py === RCS file: /cvs/gnome/gimp/plug-ins/pygimp/plug-ins/pdbbrowse.py,v retrieving revision 1.1 diff -r1.1 pdbbrowse.py 1c1 < #!/usr/bin/python --- > #!/usr/bin/env python Index: sphere.py === RCS file: /cvs/gnome/gimp/plug-ins/pygimp/plug-ins/sphere.py,v retrieving revision 1.1 diff -r1.1 sphere.py 1c1 < #!/usr/bin/python --- > #!/usr/bin/env python
Gimp-Icons not correctly highlighted on mouseover?
Tuomas Kuosmanen ([EMAIL PROTECTED]) wrote: > On Tue, Feb 08, 2000 at 10:55:04PM +0100, Jarda Benkovsky wrote: > > IMHO the problem is that the new ones (from dodge/burn on) are > > somewhat inconsistent in drawing style - I would personally like > > them to have more gray, so they are visible with dark button > > background too. For example, lasso or text have nice gray shadow, so > > they are clearly recognizable, but dodge/burn and smudge are black > > only. > > They could use some shading. But other than that, I think they serve their > purpose pretty well. BTW: Has something changed in the handling of the icons/toolbox buttons? If I move the mouse over a button (current CVS) just a rectangular frame around the image gets highlighted. Did the transparency of the imaged disappear? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Probably a FRF: Dialogs should remember
Aaron Optimizer Digulla ([EMAIL PROTECTED]) wrote: > (a Frequently Requested Feature): When I close a dialog and open it again > (e.g. a plugin), it should *not* reset its values to the defaults. This is a per plugin issue. AFAIK most plugins do this already. Where did you notice it? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Edit File behaviour change?
Sven Neumann ([EMAIL PROTECTED]) wrote:
> > I agree with marc here. Nobody expects Gimp 1.0 / 1.2 compatibility.
> > If we change this right after the 1.2 release we would force people
> > who want to use new plugins to a probably really unstable developers
> > version. IMHO this is bad.
>
> Ok, so who is going to do it? We will certainly not accept a change as
> it was done the last time. All scripts and other affected spots have to
> be changed!
Here is a list of probably all affected files:
[simon@vmax:~/cvs/gimp]> find . -exec /usr/local/bin/grep \
> -l "edit.fill" \{\} \;
./ChangeLog # no need to fix :-)
./README.perl # probably no need to fix
./app/commands.c # Just callbacks
./app/commands.h
./app/edit_cmds.c # Autogenerated
./app/menus.c # Just menu-generation
./app/global_edit.c # This needs to be adjusted to use the fg-color
./app/global_edit.h
./docs/script-fu.tex # Some example scripts need to be adjusted.
# BTW: Do they work in Gimp 1.2 ???
./help/C/image/edit/fill.html # Not yet documented
./plug-ins/perl/README
./plug-ins/perl/scm2scm
./plug-ins/perl/examples/Create_Images
[15 files deleted]
./plug-ins/perl/examples/translogo
# Marc?
./plug-ins/script-fu/scripts/3d-outline.scm
[64 files deleted]
./plug-ins/script-fu/scripts/xach-effect.scm
# Raphael already volunteered... Contact me, if you need assistance.
./plug-ins/pygimp/doc/procedural-database.html # no need to fix
./plug-ins/pygimp/doc/pygimp.sgml# example needs fixing
./plug-ins/pygimp/doc/structure-of-plugin.html # example needs fixing
./plug-ins/pygimp/plug-ins/clothify.py # needs fixing.
./plug-ins/pygimp/plug-ins/foggify.py # needs fixing.
./plug-ins/pygimp/plug-ins/sphere.py # needs fixing.
./tools/pdbgen/pdb/edit.pdb# Documentation string needs to be fixed.
# I can do this.
Did I miss a Pattern? I think "edit.fill" is good enough?
Bye,
Simon
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Edit Fille behaviour change?
Marc Lehmann ([EMAIL PROTECTED]) wrote: > Kevin Cozens <[EMAIL PROTECTED]> wrote: > > From some of the other comments on the mailing list here, perhaps its > > something that should be changed after 1.2 is out. Many scripts may have to > > I don't think so: if you need to do an incompatible change, do it as early > as possible. If we break it now, people will need to change things for 1.2, > but the devel version and the released version will act the same. In other > words: each such change, done early, will remove one further source for > incompatibility between gimp-1.2 and 1.3. I agree with marc here. Nobody expects Gimp 1.0 / 1.2 compatibility. If we change this right after the 1.2 release we would force people who want to use new plugins to a probably really unstable developers version. IMHO this is bad. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: An experiment (was Re: Move help menu item...)
Jon Winters ([EMAIL PROTECTED]) wrote: > I've had problems with the toolbox ever since it became re-sizable. I can > size it exactly the way I want it, three vertical rows of tools with > colors, brushes, patterns, and gradients below but the brushes, patterns, > and gradients are always pushed outside the window, invisible and > un-usable. Known Bug. Solution: If the Gradients are unuseable make the window *smaller*. Yes, smaller. The gradients will come up. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Move help menu item to last-on-left not first-on-right?
Nick Lamb ([EMAIL PROTECTED]) wrote: [Reordering the Toolbox Menubar, because "Help" clobbers "Xtns" with narrow Toolboxes] What about renaming "Help" to "?" ? Maybe we can do this automagically in narrow Toolboxes. Is there a way to detect the clobbering? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Announcing a New GIMP Book
Carl B. Constantine ([EMAIL PROTECTED]) wrote: > Is there any way to "unflatten" or unmerge layers in the Gimp? Here's why. I > used a Script-Fu script to generate a 3D Text logo for my wife. It looks > very cool. However, the final image only has a single layer and the > background is all white. This means I can't change the background at all no > matter what I've tried. I've tried duplicating the layer and modifying one > layer. I've just tried selecting all the white area - but this doesn't work > well due how the text turned out, etc. but I want to use a different > background for this image. It would be nice if the script-fu scripts kept > the layers in tact so that users could do some more manipulation > ofter-the-fact to fine tune the image a bit. To unmerge the layers would involve significant magic, since this infomation is lost when flattening the images... You can try to eliminate the call to (gimp-flatten-image foo) in the script. Hopefully this is the last step in the script. Then the layers will be preserved. HTH, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Pathtool?
Sven Neumann ([EMAIL PROTECTED]) wrote: > Daniel Egger wrote: > > It works, it may not have all the features that Simon desired but it's > > nice nevertheless... > > Do you have any idea how much work is needed to integrate it with the > Paths dialog? A number of new bugs would certainly be introduced by doing > so. That's why I say: It's too late! Agreed. Its a pity that I dont have the time to complete the tool at the moment and - as pointed out earlier - I dont dare to touch the Path-Dialog in the current feature-freeze state. The converting-to-selection should be pretty easy. > > I'd like to hear the thoughts of developers, too Hmm - Sven is no developer??? Did you mean me? I did the above statement some time ago - so what? The behaviour of the old Path-tool is strange - yes. But I dont think it is buggy. I can not remember how to use it and so it sometimes seems strange when clicking on an anchor creates a new anchor. But this is not a bug: To move an anchor you have to press IIRC Ctrl. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Some UI inconsistencies and a patch....
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > On 1 Feb, Marc Lehmann wrote: > > Your: > > CategoryNew File > > Looks IMHO much worse than the existing: > > CategoryNew File Settings > > Not really, you have the word "Preferences" just a few mm above it. > Also there was some inconsistency: The category "Monitor Information" was > a settings dialog anyway but it had no "Settings" in its name Hmm - I dont like the first too, since it is unclear what preferences are adjusted inside "New File". "New File Settings" is not much better... What about "New File Defaults" ? > >> 2. Some tools had a "Tool" in the options dialog and some not. Since > >> all toolsare tools and people know what tools are, we don't need > >> to call some > > > Same thing here. Just because all tools are tools there is no reason > > _NOT_ to display this. > > Well, we could have add the word "Tool" to all tools the other way > round but that's unprofessional; you don't call every Mercedes > "Mercedes Car", do you? You know that Mercedes produces cars as you > know that a pencil is a tool and in a toolbox every item is a tool. > > There's no need to tell the user what she/he's seeing if it's > obviously. So, what about the "Colors->Curves" Thing ? It is a tool isnt it? It is not always clear, if something is a tool or not - especially when it does not have a button in the Toolbox. IMHO Redundacy is not that bad. I vote for "Tool" in every Option-Dialog. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: End-user feedback: Perl logulator & innerbevel
Marc Lehmann ([EMAIL PROTECTED]) wrote: > On Mon, Jan 24, 2000 at 01:52:40AM +0100, Sven Neumann <[EMAIL PROTECTED]> >wrote: > > I won't unless someone tells us what he thinks is broken. > > Well, telling "us" about it didn't help in the past, so why should it now? > "us" should mean "the script-fu maintainer", and not me nor you. >From PLUGIN_MAINTAINERS: --- NAME : script-fu AUTHOR : Spencer Kimball & Peter Mattis MAINTAINER : Sven Neumann <[EMAIL PROTECTED]> SIZE : 463.2 kB in 11 files (only C files counted) COMMENT: --- Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Thanks (Re: Gimp splash images)
Adrian Likins ([EMAIL PROTECTED]) wrote: > On Wed, Jan 12, 2000 at 03:15:55PM -0800, Tuomas Kuosmanen wrote: > > On Wed, Jan 12, 2000 at 10:24:09PM +, Austin Donnelly wrote: > > > I vote for releasing gimp 1.2 with Tigert's 1.4 "floating balloon" > > > splash screen. > > > > I was thinking of that too. People seem to like that one. > > the baloon, the rocket, or the new one are my faves for 1.2. I really > like the newest one. Nice work. I love the newest one (with the brush), esp. since this is our first stable release with XInput-Support. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
Garry R. Osgood ([EMAIL PROTECTED]) wrote: > 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 ^ infinity? > points can be a tad exasperating. Yeah. The basic idea is, that when you drag on the curve near an endpoint you dont want to change the curve at the other endpoint. So I have to move the handle from the near endpoint more drastically to achieve the "curve-dragging" effect. Maybe I should limit the ratio at some point... Anyway: It is not too hard to get the control-point back: Simply drag the curve near the anchor towards the anchor. The controlpoint will appear as quick as he went away earlier :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
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 > > at a time. Without paid staff to do this work, we must throw away [*] > > stuff that's not going to make it. On my short list... [...] > > * Paths > > Simon ? Umm - Yes. I´m terribly sorry, but at the moment my Dis-organizer works a little bit too well. A short summary of the state of the tool: Good News: * Manipulating the path works, maybe needs some minor cleanups. * Converting to a selection probably is easy, since there is code from Andy to convert an array of floats to an selection. * The code seems fairly stable - I dont get crashes at the moment. Bad News: * The API for new path types is not sane at the moment. At some points are Ints instead of floats, some functions do have too much parameters and so on. * The integration with the paths Tab in the L&C Dialog/the PDB Path API/ The XCF-Format is probably horrible - at least for me. Im not sure if this is on the TODO for 1.2, since there are lots of points, where we can break something. My point of view: If the Integration of the Paths tool could not be done before 1.2 we should not include the tool. Its use is too limited in the current state. It should be fairly easy to remove the files shortly before the 1.2 release if necessary. 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. Hope this clears some things. Ill respond to questions... :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Feature wanted
Glyph Lefkowitz ([EMAIL PROTECTED]) missed an important feature :-) > The only thing *I* would say is a problem is the fact that the tool > shortcuts are so widely spaced on the default QWERTY keyboard: using GIMP > is a lot like playing Quake for me :) and it would be nicer if I could > have my right hand on the mouse and my left hand on the keyboard and not > move it around so much; but that might make the keys less pneumonic. You know how to remap keyboard shortcuts? Simply open the menu, move the mousepointer over the appropriate item and press the new shortcut. It will be saved in .gimp(-1.1)/menurc Really cute! Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Feature wanted
Paul Melis ([EMAIL PROTECTED]) wrote: > I suggest the following generalisation: > a thingy (for lack of a good name) which: > - activates a certain tool on the toolbox > and has its own settings for that tool > - picks a certain color/pattern/gradient > - picks a certain brush > - etc... > Every image can then have a set of thingies associated > with it (just like a set of paths). A user can select > a thingy from this list, which is an easy way of selecting > a tool from the toolbox, picking the right color and > picking the right brush and ... This has been adressed in the context-system. Michael Natterer did work on this. I dont know the current state, but it probably wont come into 1.2. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] How to make scripts undoable?
Raphael Quinet ([EMAIL PROTECTED]) wrote: > Olof and others mentioned here that it is important for the GIMP to > have a consistent interface. One of the inconsistencies that should > be fixed before 1.2 is the fact that many scripts (mostly Script-Fu) > are not undoable. Making these scripts undo-aware is a prerequisite > for moving them from the "Script-Fu" menu to the "Filters" menu or > some other location. So I started thinking about this a bit... A short notice to this topic: Even a "normal" (C-implemented) is not undoable by default (IIRC). This may be the case, if it just fiddles around in some shadow-tiles and handles them correctly. But if you have to handle several layers and do some PDB-Calls you wend up quickly with the same unwanted effect as with the scripts. I had this problem, when I ported the pagecurl plugin. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Menus
Tuomas Kuosmanen ([EMAIL PROTECTED]) wrote: > On Fri, Nov 12, 1999 at 11:50:53AM -0700, Michael J. Hammel wrote: > > I suspect a similar change would need to be made to the Layer menu, ie "Set > > Layer Size" instead of "Layer Resize". Just for consistancy sake. > > Resize Layer and Resize Canvas would be consistent, but what do others > think? I dont want to be too pushy on these :) But I like the term "Canvas". Yeah, I think Canvas is better than image in this case. But there is a (minor) clash with the "Apply Canvas" Script, where Canvas stands for the real material (in germany we would say "Leinwand" or somthing like that. But we can rename script to something like "Apply Structure" or so. But Im not a native english speaker... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Menus
Austin Donnelly ([EMAIL PROTECTED]) wrote: > On Friday, 12 Nov 1999, Simon Budig wrote: > > Me too. What about moving this one to the Dialog menu? > > Under "/View", maybe? At the moment, the undo history is like > the info window - tied to a particular image. If you want a single > instance of it to track the active image like L&C, then putting undo > history under /Dialogs would make sense. The latter is IMHO the right thing to do (TM). Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Menus
Olof S. Kylander ([EMAIL PROTECTED]) wrote: [Lots of good ideas snipped] > > * Reconstruct the menu structure > > Core gimp funcs > > Image menu > > /image/-mode-| > |RGB > |Grayscale > |Indexed Add a separator here, since Compose and Decompose are no Modes... Do we have a better name for the submenu to reflect this? > |Compose > |Decompose > | [...] > Transform--| > | Offset > | (Remove layer) > | Auto-crop > | Guillotine > | Image -- Rotate (270/90) > | Rotate (no layer option) Definitely! > | Zealous Crop > | > --- > Resize could be named Canvas size > Scale Image could be named Image size Canvas Size is perfect IMHO. Scale Image is better than Image size. > Duplicate > --- > Histogram > Save palette > > Edit Menu > /edit/---| > Undo > Redo > Undo history (not happy with this one) Me too. What about moving this one to the Dialog menu? > > Cut > Copy > Paste > Paste into > Paste as new > Buffer--| > - Cut Named > Clear Copy Named > FillPaste Named > Stroke > - > Copy Visible > > Layer Menu (Image and dialog) > --| > Layers & Channels > Stack-- > Layer--Rotate (270/90) > Rotate (no image option) Yeah. > - > Same as before > - > Semi-Flatten Since this is a plugin: Is it possible for a Plugin to register in the Layers&Channels Submenu? > Filter Menu > Filter/--| > Repeat last > Re-show last > Filter all layers > > Animation (The same except Filter all ...) [...] > Toys (the same ;-) This is *way* too obvious. What about ->Filters->Misc->Stuff->Not useful->Just Toys->Really!->Dont try this at home->You->have->been->warned->The egg ? ;-) > File Menu Image > /file > Remove Preference > > File Menu Toolbox > /file/-| > New > Open > > Acquire (We have to tell SANE) > > Preferences > > Dialogs > - > Doc Hist > > Quit What about unifying those two menus? We do have the concept of an active image, so why not use it? BTW: We have to add an indicator, which display is currently active. Another field in the status bar is IMHO a good start. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Clean up and Re: Help System
Sven Neumann ([EMAIL PROTECTED]) wrote: > > Magnify: > > zoom out > > ---> zoom in > > Isn't it just always Zoom In (I mean unless is pressed of course)? Just an idea: middle mouse-button is panning, why not Shift-middle button = Zoom Out and ctrl middle-button = zoom in. (Personally I'd prefer it the opposite: Shift: Zoom In, CTRL: Zoom out, but I cannot tell you why, it seems more logical for me...) Maybe using alt for allowing window resizing is a good idea. In a post 1.2 step we can make the Magnify tool behave the same and simply bind the middle mouse-button per default to the magnify-tool. Then you could assign arbitrary tools to the middle mb - for example to easily switch between the eraser and the paint tool. BTW: Shift middle-button + some dragging easily leads to artefacts when the paint tool is active! Apropos cleanup: What about removing the pencil and substitute it with a "hard edge" toggle in the Painbrush? Sometimes it is quite hard to convince the people to use the paintbrush instead of the pencil... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Help System
Austin Donnelly ([EMAIL PROTECTED]) wrote: > On Wednesday, 10 Nov 1999, Sven Neumann wrote: > > - Grab GtkXmHtml seperately. This is difficult at the moment, but I was > > told that the gEdit application offers a seperately bundled one. > > If gEdit needs GtkXmHtml, and so does Gimp, does this not mean there's > a real requirement to make GtkXmHtml a standard part of libgtk? > > Maybe the time has come to fold GtkXmHtml into the main library. We > should talk to the gtk people. Tim, Owen? IMHO there is a lot of things, that should be reorganized in the GLib/Gtk/Gnome-field. Higher-level widgets like Gnome-Canvas and GtkXmHtml should go in a separate library, since Gtk is already a huge library and those very specialized widgets are not useful for the average application. Gnome Canvas is so useful, it should not be in the Gnome-Libs, because some people refuse to install gnome (I dont know why, but there are those people...) Also the Object Model in Gtk should go in the glib package. Things like the signal-handling can be useful in Non-Gui applications and I dont want to link against Gtk for a console-tool... Just my 2 Pf, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Tile Cache Size
Guillermo S. Romero / Familia Romero ([EMAIL PROTECTED]) wrote: > Why I say that? Becuase Unix swap (I suppose to a partition, not to a file) > will be better than Gimp swap. So if you need to swap, use first what the OS > provides, and then Gimp system (and if NFS, remember to use local /tmp for > Gimp). This is not necissarily true. The System-Swap routine is optimized for arbitrary data. Gimp organizes its image-data in tiles and may perform better in swapping those tiles, since they are a very special data-structure. So the swapping routines could be optimized specially for those data (I have no idea if this is done currently) and perform better than the systems routine. The NFS problem should be adressed. Can we detect somehow if the configured swap-directory is a NFS-Direcrtory and issue a warning? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: tile cache size
Austin Donnelly ([EMAIL PROTECTED]) wrote: > Idea: if the size is set to 0, make it mean "guess something good". > Out of the box gimp can come with it set to 0, and we just make the > algorithm pick something appropriate. That's the hard part. Just to start a discussion: What about trying to detect if it is a "private" machine with less than 5 regular users and then using 80% of the physical memory? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: More Inconsistency in eraser, blur and dodge tools
Tuomas Kuosmanen ([EMAIL PROTECTED]) wrote: > We also have Space if we need something. On Photoshop it is used for > panning, but Gimp has mouse2 for that. Could Space be a toggle after all for > the togglable tools? I know we had a talk about this a while back, and we > agreed that Shift is a "natural" way to "shift" things.. But it is clearly > conflicting at the moment.. I would be just happy to control the tool > toggles (erase/antierase, fg/bg fill, blur/sharpen, dodge/burn) with SPACE. Hmm - what do you think about dropping the panning (Ugh - no - dont beat me! :-) I think the Quick-navigation is much more useful and quicker. So we could use the middle mousebutton for an alternative function, maybe even a second device with an own context. Just my 0.01$ :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Tablet and multiple active Areas / Pointer Window Mode
Olof S. Kylander ([EMAIL PROTECTED]) wrote: > In the new driver which I asume that you use the AlwaysCore is always on > :-). This is why you have trouble. No, one configured device does not emit core-events. The Problem is, That I want Gimp to handle two different XInput-devices with the same "context", so I can use one area as Quickpoint-area to move the core-pointer and one area to paint in the window without moving the core-pointer. But Gimp insists to have different configs for those two devices. Hmm - probably something for the wishlist :-( Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Tablet and multiple active Areas / Pointer Window Mode
Hi all. I have defined two active Areas on my tablet, one generates core-events, one not. See the part in the XF86Config. SubSection "WacomStylus" Port"/dev/ttyS0" DeviceName "Stylus Pen 2" ModeAbsolute Suppress10 Serial 2564817921 TopX0 TopY0 BottomX 15240 BottomY 12180 # AlwaysCore EndSubsection SubSection "WacomStylus" Port"/dev/ttyS0" DeviceName "Stylus Pen 2" ModeAbsolute Suppress10 Serial 2564817921 TopX15240 TopY12180 BottomX 20320 BottomY 16240 AlwaysCore EndSubsection >From the X-Server point of view it works as expected. But the idea was: I want to use the bigger area in the top left corner in Window-Mode and the bottom Left corner as Quickpoint-area. The Problem is: Gimp detects two different devices with the same name. So it is impossible for me (without a mouse or using the menus) to change the "windowed" Pen to another tool, because the Quickpoint-Area is an own extended device. Is it possible for Gimp to treat two XInput-Devices as the same "Gimp-"Device? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Cool method to sharpen images (including script!)
Hi. The german computer-magazine c't (No. 22/1999) described a cool method to sharpen images including a Photoshop-action. I converted it to a Script - it is attached. Basically unsharp edges will get squeezed together, so that the edge will get sharper (by edge-detecting, bluring, bump-mapping two times for X- and Y-direction and displacing) It works quite cool. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ;;; warp-sharp.scm ;;; Date: <1999/10/30 0:50 [EMAIL PROTECTED]> ;;; Author: Simon Budig <[EMAIL PROTECTED]> ;;; Version 1.0 ;;; This implements a method to sharpen images described by Joern Loviscach ;;; in the german computer-magazine c't, 22/1999. ;;; Basically it "squeezes" unsharp edges. This method is a simplified ;;; Version of an algorithm by Nur Arad and Craig Gotsman: ;;; "Enhancement by Image-Dependent Warping", IEEE Transactions on ;;; Image Processing, Vol. 8, No. 8, S. 1063 (define (script-fu-warp-sharp img drw edge-strength blur-strength bump-depth displace-amount) (let* ((drawable-width (car (gimp-drawable-width drw))) (drawable-height (car (gimp-drawable-height drw))) (drawable-type (car (gimp-drawable-type drw))) (old-selection 0) ; layer for detecting edges (edge-layer (car (gimp-layer-copy drw 0))) ; layer for x-displace information (x-displace-layer (car (gimp-layer-new img drawable-width drawable-height drawable-type "Displace X" 100 0))) ; layer for x-displace information (y-displace-layer (car (gimp-layer-new img drawable-width drawable-height drawable-type "Displace Y" 100 0))) (selection-info (gimp-selection-bounds img)) (has-selection (car selection-info)) (bump-xoff 0) (bump-yoff 0) ) (gimp-undo-push-group-start img) (if has-selection (begin ; If there is a selection don't render too much. (set! old-selection (car (gimp-channel-copy (car (gimp-image-get-selection img) (gimp-selection-grow img (+ blur-strength bump-depth displace-amount)) (set! selection-info (gimp-selection-bounds img)) (set! bump-xoff (cadr selection-info)) (set! bump-yoff (caddr selection-info)) )) ; set up the layers (gimp-drawable-fill x-displace-layer 2) (gimp-drawable-fill y-displace-layer 2) (gimp-image-add-layer img edge-layer -1) (gimp-image-add-layer img y-displace-layer -1) (gimp-image-add-layer img x-displace-layer -1) ; detect the edges and blur the layer a little bit (plug-in-edge 1 img edge-layer edge-strength 1) (if (>= blur-strength 1) (plug-in-gauss-iir 1 img edge-layer blur-strength 1 1)) ; create the displacement-maps by bump-mapping the edges. ; elevation=30: areas without edges will get a 50 % gray. (plug-in-bump-map 1 img x-displace-layer edge-layer 0 30 bump-depth bump-xoff bump-yoff 0 0 0 0 0) (plug-in-bump-map 1 img y-displace-layer edge-layer 270 30 bump-depth bump-xoff bump-yoff 0 0 0 0 0) ; restore the old selection (if has-selection (begin (gimp-selection-load old-selection) (gimp-channel-delete old-selection) )) ; finally displace the image. (plug-in-displace 1 img drw displace-amount displace-amount 1 1 x-displace-layer y-displace-layer 1) ; clean up... (gimp-image-remove-layer img edge-layer) (gimp-image-remove-layer img x-displace-layer) (gimp-image-remove-layer img y-displace-layer) (gimp-undo-push-group-end img) (gimp-displays-flush))) (script-fu-register "script-fu-warp-sharp" "/Script-Fu/Alchemy/Warp Sharp" "Sharpen the current drawable by squeezing unsharp edges. Algorithm described by Joern Loviscach in c't 22/1999, p 236." "Simon Budig <[EMAIL PROTECTED]>" "Simon Budig" "30. 10. 1999" "RGB RGBA GRAY GRAYA" SF-IMAGE "Image" 0 SF-DRAWABLE "Drawable" 0 SF-ADJUSTMENT "Edge detection" '(7 1 10 0.1 1 1 0) SF-ADJUSTMENT "Blur radius" '(3 0 10 0.1 1 1 0) SF-ADJUSTMENT "Bump depth" '(2 1 10 1 1 0 0) SF-ADJUSTMENT "Displace intensity" '(2.5 0.1 10 0.1 0.5 1 0) )
Gtk+-rpms with xinput enabled?
Hi all. Are there some Gtk+-Rpms with xinput enabled floating around somewhere? I have no Idea, how to build them, I usually compile myself from the tarballs... But I want to write a quick xinput tutorial without an explantation how to compile Gtk... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Right Click on Foreground/Background
Benjamin B. Thomas ([EMAIL PROTECTED]) wrote: > I just noticed in 1.1.9 that right clicking on either the current > foreground or background color in the tool box does nothing (until > you drag it, that is). It seems like it would be extremely useful to > have this produce a drop down list display of the last N colors used > as either the foreground or background, respectively. > > I apologize if there is already an easy way to select a recently > used color, and I missed how to use it. We discussed this Idea at the Meeting in Goeteborg and considered it as a new feature. So IMHO we should wait until 1.2 is out. It would be way cool - but please for brushes, patterns and Gradients too :-) But we should make the right button work like the left button. Probably a one-liner :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Gimp at the Systems 99 in Munich
Hi. As you may have read at the Gimp News I am coordinating the Gimp Booth at the Systems 1999 in Munich. I need some people, who will be there and have some time left to present the Gimp. So if you are interested, please mail me ASAP, so I can get a ticket for you. Further information: http://www.linux-magazin.de/systems/ ---german--- Wie Du vielleicht mitbekommen hast, werde ich den Gimp-Stand auf der Systems 1999 in Muenchen organisieren. Ich brauche noch ein paar Leute, die dort sein werden und etwas Zeit uebrig haben um Gimp zu praesentieren. Wenn Du Lust hast, mail mir so schnell wie moeglich, damit ich noch ein Ausstellerticket besorgen kann. Weitere Informationen: http://www.linux-magazin.de/systems/ Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] disabling signal handlers?
Marc Lehmann ([EMAIL PROTECTED]) wrote: > Is there a way to disable the libgimp signal handlers? [...] > - in 99% of the cases, they result in an endless loop, which requires me to > switch the terminal and kill it manually. This is my main concern. I had this problem too. Updating glib (and maybe a recompile of the whole Gimp) was the solution for me. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
