Re: active gradient suggestion
Maybe best would be to have a magic entry in the gradient editor "FG-BG" and "BG-FG" which would change accordingly, and remove the selection from the gradient tool. jtl Make that the gradient selector rather than the editor, and I'll agree with you completely :) Seth
Re: gimp_image_get_resolution/gimp_image_get_unit/release timetable
Hi, Well, thus far we've had very little trouble supporting 1.0. Even the configure script works properly. 1.0 is still the stable release of the Gimp. I really don't understand your development cycle. We are approaching the 1.2 release but you insist on keeping the code that is going to ship with 1.2 compatible with 1.0. At the same time you start a new unstable branch heading towards a future you know nothing about yet. Why don't you put some effort into making the print plugin that ships with 1.2 a nice and featureful one? Adding new printers and other sophisticated stuff is probably a bad idea, but overworking the UI and supporting resolution info are things that should be addressed right now. Salut, Sven
Re: pathsP.h
Blue Lang wrote: did someone take that out of cvs? Yes. From ChangeLog: Wed Feb 16 14:46:14 CET 2000 Sven Neumann [EMAIL PROTECTED] * app/pathsP.h: removed * app/path.h * app/pathP.h * app/path_transform.h: new header files. Only files that absolutely need to access the Path structures internally need to include pathP.h. All other functionality is described in the other header files. i just did an update from the anon-cvs tree (the one hosted by debian,) and cvs axed pathsP.h from the app/ dir. now gimp won't build. any ideas? Hm. Did you (1) tidy up through 'make distclean?' (2) Rebuild makefile.in's through 'autogen.sh your favorite configure preferences' (autogen.sh rebuilds configure, then runs the new configure for you) (3) make all. This synchronizes the configure script and makefiles with changes in the tree actually, nothing is getting put into the intl/ dir either.. the main makefile still looks for stuff in there. i've been just taking intl out of my makefile, configuring with --disable-nls and --dont-use-the-included-intlgetextthingy and crossing my fingers, but, no luck.. Last few days, there have been synchronization problems between various anoncvs servers - see 'CVS ChangeLog' thread. should i blow away my work dir and get a clean cvs dump, or is there a muckup in there? I think 'muck up' qualifies. Personally, I find it reassuring to tarball the work directory, blow it away, and let CVS build a new one from scratch, but that seems unnecessary in this case. Good luck. Be good, be well Garry Osgood
active gradient suggestion
It's a little confusing to me sometimes to use the gradient tool, thinking the gradient at the bottom of the toolbar will be used, and finding out that it's actually using the FG-BG colors (or vice versa). I do know how to change it, but sometimes I forget which is in effect. It would be nice if there was a magic option in the gradient selection list called something like "[FG-BG colors]" that automatically showed a thumbnail of what the bg/fg colors would look like as a gradient. When it's selected, it would also display in the bottom of the toolbar, and dynamically update when the colors change. That way, no matter what gradient method is selected, the indicator at the bottom of the toolbar will always show you what colors you'll see when you make a gradient, independant of whether you're using a pre-set gradient or a bg-fg color gradient. This is just a suggestion, and not a demand for immediate action. Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: active gradient suggestion
Zach Beane - MINT [EMAIL PROTECTED] writes: It's a little confusing to me sometimes to use the gradient tool, thinking the gradient at the bottom of the toolbar will be used, and finding out that it's actually using the FG-BG colors (or vice versa). I do know how to change it, but sometimes I forget which is in effect. It would be nice if there was a magic option in the gradient selection list called something like "[FG-BG colors]" that automatically showed a thumbnail of what the bg/fg colors would look like as a gradient. When it's selected, it would also display in the bottom of the toolbar, and dynamically update when the colors change. That way, no matter what gradient method is selected, the indicator at the bottom of the toolbar will always show you what colors you'll see when you make a gradient, independant of whether you're using a pre-set gradient or a bg-fg color gradient. This is just a suggestion, and not a demand for immediate action. Zach Maybe best would be to have a magic entry in the gradient editor "FG-BG" and "BG-FG" which would change accordingly, and remove the selection from the gradient tool. jtl
Re: active gradient suggestion
It's a little confusing to me sometimes to use the gradient tool, thinking the gradient at the bottom of the toolbar will be used, and finding out that it's actually using the FG-BG colors (or vice versa). I do know how to change it, but sometimes I forget which is in effect. It would be nice if there was a magic option in the gradient selection list called something like "[FG-BG colors]" that automatically showed a thumbnail of what the bg/fg colors would look like as a gradient. When it's selected, it would also display in the bottom of the toolbar, and dynamically update when the colors change. That way, no matter what gradient method is selected, the indicator at the bottom of the toolbar will always show you what colors you'll see when you make a gradient, independant of whether you're using a pre-set gradient or a bg-fg color gradient. This is just a suggestion, and not a demand for immediate action. Come on guys. This idea is not new and the only reason it's not yet implemented is the feature freeze. Read the list we created last August at the Chaos Communication Camp... Salut, Sven
Re: active gradient suggestion
On Sat, Feb 19, 2000 at 10:04:05PM +0100, Sven Neumann wrote: [snip] Come on guys. This idea is not new and the only reason it's not yet implemented is the feature freeze. Read the list we created last August at the Chaos Communication Camp... What's the URL? I looked at http://sven.gimp.org/camp/ but didn't find it... Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: gimp_image_get_resolution/gimp_image_get_unit/release timetable
Robert L Krawitz wrote: I'm experimenting with gimp_image_get_resolution(). It appears (in 1.1.17, at any rate) that whatever I set the units to I always get a resolution back that's expressed in dots per inch. Is this behavior correct? Absolutely correct. If so, did it work this way in 1.0 also? This is so I can investigate its use with the Print plugin. 1.0 has no resolution info at all. BTW, do you really want to support 1.0? It may be quite hard to make use of the help system and the libgimp ui stuff (i.e. sizeentries which may be useful for the print plugin) if you want to keep the print plugin running with 1.0... bye, --MItch
Re: gimp_image_get_resolution/gimp_image_get_unit/release timetable
Date: Sat, 19 Feb 2000 22:43:41 +0100 From: Michael Natterer [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Robert L Krawitz wrote: I'm experimenting with gimp_image_get_resolution(). It appears (in 1.1.17, at any rate) that whatever I set the units to I always get a resolution back that's expressed in dots per inch. Is this behavior correct? Absolutely correct. Thanks. If so, did it work this way in 1.0 also? This is so I can investigate its use with the Print plugin. 1.0 has no resolution info at all. BTW, do you really want to support 1.0? It may be quite hard to make use of the help system and the libgimp ui stuff (i.e. sizeentries which may be useful for the print plugin) if you want to keep the print plugin running with 1.0... Well, thus far we've had very little trouble supporting 1.0. Even the configure script works properly. 1.0 is still the stable release of the Gimp. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: mkbrush.scm
Hi, While scripts are in the air, should we remove mkbrush.scm before 1.2? This script takes a bunch of parameters and makes a new brush, almost exactly like the "New" or "Edit" features of the brush dialog, but it's a Script-Fu. Do we need it for anything? Otherwise we should remove it to reduce end-user confusion I think. The script allows to create rectangular brushes too, which is something the brush-generator does not allow (yet). BTW: Is it only at my installation or are the generated brushes never loaded? They obviously get saved... Eeek, another bug! Salut, Sven
How to load a *.raw file
Hi, I want to load a image using gimp. this image size is 2048 times 1420 pixels. The value of each pixel is a 8 bit number. Is it possible to load thsi image using a script. I am very new to Gimp. If possibel please give some suggestion. Bye, Nilay.
Re: How to load a *.raw file
On Sat, Feb 19, 2000 at 04:06:19PM -0800, Nilay saha [EMAIL PROTECTED] wrote: Is it possible to load thsi image using a script. Yes. It is non-trivial. If you have ImageMagick installed, however, you can eaasily convert that image using a call like: convert -size 2000x1500 gray:inputfile.raw outputfile.pgm and then load outputfile.pgm -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: How to load a *.raw file
On Sat, Feb 19, 2000 at 04:06:19PM -0800, Nilay saha wrote: I want to load a image using gimp. this image size is 2048 times 1420 pixels. The value of each pixel is a 8 bit number. Is it possible to load thsi image using a script. There is a RAW plug-in avaialable which does this thing, you can find it at the registry. http://registry.gimp.org/detailview.phtml?plugin=RAW -- [EMAIL PROTECTED] | OpenPGP encryption welcome here, see X-DSA-Key
Re: gimp_image_get_resolution/gimp_image_get_unit/release timetable
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 20 Feb 2000 03:18:53 +0100 Don't underestimate the importance of the resolution info for the print plugin. The following task may not be very professional, but it is certainly something the average gimp user does frequently: Scan in an image, retouch it, collage it, whatever, then print it. When doing this with gimp-1.1.x all parts of the data stream support the resolution information. The scanner plug-in uses it, the application gives you the necessary infos in realsize units, you may even save and load your image in between in a variety of formats. But when you choose to print the image, that information carried along all the way is useless, since it is simply ignored. We have added the image resolution in 1.1 only to make Gimp better suited for printed graphics. CYMK support is still missing, but I thought we'd at least manage to integrate the resolution info completely. Pending a general way to scale images separately on X and Y axes, what would be your (collective) suggestions about how to handle an image with different X and Y resolutions? -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Small .....
Hi, * How to change RGBA image to an RGB image ?, because it's not intuitive enough. New option in "Remove Alpha" menu would be more helpful than explaining this and that. Removing Alha from a multilayered image is not possible since gimp insists on having alpha on each layer but the background. So, Flatten is actually the correct term here, IMHO. * in toolbox sometimes windows get really odd (color, palette, brushes, gradient), they look a bit scrambled and they are out of control. This more or less works now... * Still no transparent text (it can't be that hard) Although it's tricky to get transparent text, but it is possible and one must invent it ?? Sorry, I don't you here. * Lack of image info (in particular on: Amount of colours used in an image (GIF stuff) Fixed that a while ago. Histogram for indexed mode image [you get weird message when trying to get histogram for indexed mode image]) Hmm, what's weird about: "Histogram does not work on indexed drawables"? We might want to additionally set the menu sensitivity dependant on the image mode.
Re: [gimp-devel] Re: Some UI inconsistencies and a patch....
On Tue, Feb 08, 2000 at 10:55:04PM +0100, Jarda Benkovsky wrote: Tuomas Kuosmanen wrote: The icons are imho very good, try making better ones and you understand why. Of course they arent PuRdy CuTe, but that is not the point. Most graphics tools dont have too colorful icons, excluding Painter(tm) of course.. :) 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. You are right :) They could use some shading. But other than that, I think they serve their purpose pretty well. Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
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-Icons not correctly highlighted on mouseover?
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? Eeek, my fault. I somehow forgot about the importance of the mask. Please forgive me ;-) I have just added it back in CVS... Salut, Sven
