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] 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: 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: 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: 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] 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/
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 21 || /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] 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 21 || /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/
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] 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] 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] 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/
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/
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
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] 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
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/
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] 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/
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] 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/
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/
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] XFree86 4.0 and Wacom Tablets.
Garry R. Osgood ([EMAIL PROTECTED]) wrote: Simon Budig [EMAIL PROTECTED] snipped... BTW: Does somebody use XFree 4.0 with a wacom tablet? Sometimes I believe, that firm pressing the pen results in no more motion events... Is it "no more motion events", or is it *so many* motion events that the Gimp becomes paralyzed in processing the backlog? And is this problem always observed, or only when the "Perfect but Slow" preference choice is made? It seems to be "no more events", since lifting the pen and touching the tablet again made the pen work again. It only happens, when "Perfect but Slow"-tracking is *dis*abled. So I guess, when I press harder, more events are generated and Gimp loses some events? Motion Buffer is set to 0. Hmm... Bye, 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/
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/
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/
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: * ** *DragDrop*: 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 image to another) Color selectors - use the standard GTK color-drag - color to channel - color to Q-mask Device status - drag patt
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: [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: 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/
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] 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] 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: 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: 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 LC 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
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] 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: Clean up and Re: Help System
Sven Neumann ([EMAIL PROTECTED]) wrote: Magnify: Shift zoom out --- Ctrl zoom in Isn't it just always Zoom In (I mean unless Shift 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: 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/
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/
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/
