Re: Opacity in bucket fill?
[EMAIL PROTECTED] wrote: > > Hi, let me introduce myself. My staff artist and I are in the early stages > of a book on web design with free software, including the GIMP. Anyway, we > started working with GIMP 1.1 because the book is going to have to be about > GIMP 1.2. > > Olivia was angry that the "opacity" slider was missing from the Bucket Fill > dialog box -- she likes it because, coming from a watercolor background, she > likes to create a canvas of colors on a canvas and use bucket fill to adjust > spots of color until they look just like what she wants. > > Anyway, I looked at the GIMP 1.1 and GIMP 1.0 source and it looks, > superficially, that the code for doing bucket fills with variable opacity > still exists (at least there is still an opacity option for bucket fills in > the procedural database.) Anyhow, I think I can make Olivia happy by just > adding a slider to the bucket fill dialog. > > So, am I right about this, or am I missing something? If I send in a patch > to add the slider to the dialog box, will you merge it into the tree? Please > direct a copy of your reply to me because I'm not a regular subscriber to the > gimp-developer list. Hi Paul, just deactivate the "Use Global Paint Options" button in the preferences dialog's "Interface->Tool Options" page. Otherwise the opacity as set in the brushes dialog will be used. ciao, --Mitch
Opacity in bucket fill?
Hi, let me introduce myself. My staff artist and I are in the early stages of a book on web design with free software, including the GIMP. Anyway, we started working with GIMP 1.1 because the book is going to have to be about GIMP 1.2. Olivia was angry that the "opacity" slider was missing from the Bucket Fill dialog box -- she likes it because, coming from a watercolor background, she likes to create a canvas of colors on a canvas and use bucket fill to adjust spots of color until they look just like what she wants. Anyway, I looked at the GIMP 1.1 and GIMP 1.0 source and it looks, superficially, that the code for doing bucket fills with variable opacity still exists (at least there is still an opacity option for bucket fills in the procedural database.) Anyhow, I think I can make Olivia happy by just adding a slider to the bucket fill dialog. So, am I right about this, or am I missing something? If I send in a patch to add the slider to the dialog box, will you merge it into the tree? Please direct a copy of your reply to me because I'm not a regular subscriber to the gimp-developer list.
Re: Re: Some UI inconsistencies and a patch....
Sorry, busy in last days: >> Should we start one? How? I can post all things I now about users, but we >> could do something better, I guess. >If you want to do some faq-like "style-guide" (with emphasize on how >general ui design techniques are applied to the gimp ;*) I'll edit it and >publish it in the docs section on sourceforge. OK, I will write down all things I talk with guys I know, and try to write old ones. GSR
Re: What should I change in Script-Fu scripts? (Summary)
Sorry, busy ending exams, now processing postponed things: > A3) Add a new parameter to the dialog box so that the color has to > be specified explicitely. >Almost everybody supports A3) so I will implement that. Everybody + 1. > B3) Add a "flatten image?" option to all scripts, defaults to FALSE. > B4) Never flatten, but rely on the Export mechanism (it works well). >For this, I got mixed opinions. Several people support B3, but I >also received two suggestions to use B4. More opinions are needed... If it works really well, use the Export mechanism. More buttons if you can do at save time (after changing things), no thanks. > C2) Use "The Gimp" as the default text in all scripts > C2b)Use "The Gimp" and adjust the font size so that all scripts > generate an image of comparable size when run with the default > parameters. > C3) Use the script name. >Here, this is a 50%-50% match between C1 and C2 (or C2b). More >opinions are needed... C2 with same font size, so you get the idea about how big a font is (damn font sizes... there could be a standard, no?). >My personal opinion (in order to bias the votes towards C2b :-)) is >that the first thing that most users will do when they want to produce >a logo is to change the text (of course!) and some of the other >parameters. But before creating a real logo with these scripts, it is >useful to run all of them quickly with the default parameters in order >to get an idea of what these scripts are doing. Running them quickly >means not having to change the defaults. It is much easier to compare >the results if the images have similar sizes and contain more or less >the same text. Currently, this is not easy because you have the >"Textured" logo using the default string "The GIMP" at 200 pixels >while the "Bovinated" logo uses the longer string "Fear the Cow" at 80 >pixels and the "Comic" logo uses the short string "Moo" at 85 pixels. I see you point, another C2b, "The Gimp" with same pixel size. > D2) Add the "padding" parameter to the scripts that create a > textured background. >Most people seem to support D2, so I will implement that. Most people + 1. GSR
Re: What should I change in Script-Fu scripts?
On Thu, 17 Feb 2000, Sven Neumann wrote: > The idea to have another menu entry is IMHO a good one and better then > adding a new preferences option. But please do not use a script or > another weird hack that changes the fg/bg for the fill, then restores > it later. Better add a fill_type parameter to the internal edit_fill() > function and default to FOREGROUND_FILL for the PDB call. I like this, but as I proposed before, I believe leaving Ctrl-. bound to fill-with-bg would be a good idea (since I don't know of anybody going to the menu option on a regular basis...). It would be intuitive (IMHO) to bind Ctrl-, to fill-with-fg; it occurrs to me that being able to do both easily might be useful, without swapping colors. --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Call for help with documentation (2nd try)
Hi, the response to this mail was very small when I sent it to the list a month ago, but I want to give it another try... So, here comes the next call for help: This one is targeted especially at people who always wanted to contribute, but couldn't due to the lack of coding skills. There's some documentation shipped with The GIMP that urgently needs to be updated and checked for correctness before version 1.2 can be released. Here's a list of things that need to be overworked: man-pages: gimp.1 gimprc.5 (generated from gimprc.5.in) stuff in the docs directory: cheat_sheet.txt keybindings.txt ( do we need both ? ) quick_reference.ps (the LaTeX source is in docs too) Additionally gimprc.in from which the global configuration file is generated should be checked for completeness and correctness. All possible configurations should be listed here with useful comments. The Phtoshop-keybindings file ps-menurc has to be updated to reflect the changes in the menu-structure. If you want to take one of those jobs, please announce that you are working on it, so we don't duplicate effort. An additional remark: We have started to document libgimg to provide a useful source of information for plug-in developers. Mitch and me have already done a fair amount of work in this area. Documentation of libgimpui is almost complete and we are right now working out a way to add the information contained in the PDB. However help in this area is of course highly appreciated. I want to encourage especially the authors of code contained in libgimp to add some documentation. There's a README in the devel-docs directory, you will want to read. Salut, Sven
dynamic text settings persistance
Dynamic text settings do not seem to persist unless you play fairly elaborate games, modifying existing DynText layers and saving to new layers. Dynamic text needs a default, or the ability to hold on to the most recently used font settings.
Re: edit->fill, alpha and some general thoughts
Marc Lehmann wrote: > > and maybe, but only maybe, we should have seperate Edit->Fill > BG and Edit->Fill FG items. This is the best idea I've heared so far. We could leave all scripts untouched and add the FG fill thing as a ui-only option. People can then assign menu shortcuts to swap the two entries. bye, --Mitch
Re: v 1.1.17 libintla error
On Wed, Feb 16, 2000 at 02:21:27PM -0800, Tony Webster <[EMAIL PROTECTED]> wrote: > I thought this might be a bug. You thought correct :) I'll try to fix it. > With my little bit of programming skills, I would have now idea where to > begin fixing this. It's a tricky problem. BTW&OFFTOPIC: did you have special reason not to use the i18n support that is in your libc? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
edit->fill, alpha and some general thoughts
On images without alpha, Edit->Clear and Edit->Fill always behave the same, so one of them is redundant on alpha-less images. This is what constantly puzzled me ever since I used these options. For me, clearing and filling are opposite actions. Another thing that puzzled me was that Edit->Clear behaved very differently depending on wether my image had an alpha channel (and thus, it behaved differently depending on the active layer, very disturbing (for me), just like the former (and needless) distinction between the background layer and a normal layer. Connected to that is that I (after working with the gimp for some time now) think that alpha is handled very poorly from the ui perspective. There is no way to pre-select alpha in the current Image->New dialog (it was factored differently in 1.0, not nevertheless better). What's worse: it is _very_ difficult to get rid of alpha again. It seems that the gimp really likes to have alpha enabled (for good reasons). IMHO, Edit->Clear should always act the same (adding an alpha channel if necessary), and maybe, but only maybe, we should have seperate Edit->Fill BG and Edit->Fill FG items. This mail is probably not 1.2 stuff, though ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: CVS Changelog
Hi, I'm forwarding this to the list since I can't do anything about this, but hopefully someone who can listens... --- Start of Forwarded Message > I guess you are having trouble with the anoncvs servers. There are > four servers and I have the strong feeling that at least one of them > is not updated any more for a couple of weeks now. The faulty one is 142.62.1.41 (faucon.ccrit.crc.ca), the other three seem to work fine. Paul - -- [EMAIL PROTECTED] --- End of Forwarded Message
Re: What should I change in Script-Fu scripts?
On Thursday, 17 Feb 2000, Raphael Quinet wrote: > My 0.02 Euro: I would like to change the Edit->Fill behaviour globally > and at the same time provide a three-lines script (or code in the > core) that would register itself as "Edit->Fill with BG" and would > swap the colors, call gimp-edit-fill and restore the colors again. So > those who prefer the current behaviour could bind Ctrl-. to it. Yes. Austin
Re: What should I change in Script-Fu scripts? (Summary)
I received several replies to my opinion poll, by private e-mail or on this list. Here is a summary of what I got so far: About changing the scripts that call gimp-edit-fill without setting the colors first (thus taking the current color in use): A1) No change to the scripts (they would then use the fg color) A2) Swap foreground and background A3) Add a new parameter to the dialog box so that the color has to be specified explicitely. Almost everybody supports A3) so I will implement that. About flattening the image or not: B1) No change to the scripts B2) Add a "flatten image?" option to all scripts, defaults to TRUE. B3) Add a "flatten image?" option to all scripts, defaults to FALSE. B4) Never flatten, but rely on the Export mechanism (it works well). For this, I got mixed opinions. Several people support B3, but I also received two suggestions to use B4. More opinions are needed... About the default text string in the logo scripts: C1) No change to the scripts C2) Use "The Gimp" as the default text in all scripts C2b)Use "The Gimp" and adjust the font size so that all scripts generate an image of comparable size when run with the default parameters. C3) Use the script name. Here, this is a 50%-50% match between C1 and C2 (or C2b). More opinions are needed... My personal opinion (in order to bias the votes towards C2b :-)) is that the first thing that most users will do when they want to produce a logo is to change the text (of course!) and some of the other parameters. But before creating a real logo with these scripts, it is useful to run all of them quickly with the default parameters in order to get an idea of what these scripts are doing. Running them quickly means not having to change the defaults. It is much easier to compare the results if the images have similar sizes and contain more or less the same text. Currently, this is not easy because you have the "Textured" logo using the default string "The GIMP" at 200 pixels while the "Bovinated" logo uses the longer string "Fear the Cow" at 80 pixels and the "Comic" logo uses the short string "Moo" at 85 pixels. About adding a "padding" parameter to the scripts: D1) No change to the scripts D2) Add the "padding" parameter to the scripts that create a textured background. Most people seem to support D2, so I will implement that. -Raphael
Re: CVS Changelog
> What happened to ChangeLog in CVS? The newest entry > is dated January 26th (the revision date in my > gimp/CVS/Entries says it is rev. 1.2137, dated Feb, 17th). I guess you are having trouble with the anoncvs servers. There are four servers and I have the strong feeling that at least one of them is not updated any more for a couple of weeks now. You may want to hardcode the IP of an anoncvs-server that works for you into your /etc/hosts file until this problem is solved. Salut, Sven
Re: What should I change in Script-Fu scripts?
> My 0.02 Euro: I would like to change the Edit->Fill behaviour globally > and at the same time provide a three-lines script (or code in the > core) that would register itself as "Edit->Fill with BG" and would > swap the colors, call gimp-edit-fill and restore the colors again. So > those who prefer the current behaviour could bind Ctrl-. to it. The idea to have another menu entry is IMHO a good one and better then adding a new preferences option. But please do not use a script or another weird hack that changes the fg/bg for the fill, then restores it later. Better add a fill_type parameter to the internal edit_fill() function and default to FOREGROUND_FILL for the PDB call. Salut, Sven
CVS Changelog
What happened to ChangeLog in CVS? The newest entry is dated January 26th (the revision date in my gimp/CVS/Entries says it is rev. 1.2137, dated Feb, 17th). Paul -- [EMAIL PROTECTED]
Re: What should I change in Script-Fu scripts?
On Wed, 16 Feb 2000, Glyph Lefkowitz <[EMAIL PROTECTED]> wrote: > Why are you bothering to change this behavior (edit/fill) when it makes > sense to 1/2 of the people who use GIMP, it's a historical precedent in > terms of the UI, and it's a huge amount of work to get to function > correctly? Are there not enough bugs in the gimp that need to be > fixed that more twiddling like this needs to be done? The "fill with background" behaviour is a historical precedent in terms of the _Gimp_ UI. But most of the other programs that I tried are using the foreground color. So although some of the old users who use Ctrl-. frequently might be confused if the Gimp starts to behave like other programs, this should be a good thing for most of the new users. Besides, why should we have a Fill Tool that fills with the foreground color by default and an Edit->Fill menu that fills with the background color? Even if we end up making this option configurable, I would like the defaults to be consistent. Regarding the "huge amount of work", I would say that this is a tedious task but it is not hard to get it to function correctly. On the other hand, this allowed me to see that some scripts had a number of bugs that had not been reported yet: for example the "3D Truchet" script does not restore the colors correctly upon exit. Another script (I forgot which one) creates a layer, fills it with the current color, and then "forgets" to use it in the image. On Thu, 17 Feb 2000, Sven Neumann <[EMAIL PROTECTED]> wrote: > > Sven, thanks for clearing that up. > > Well, it's not yet cleared up since we'll first have to agree if we want > to change the Edit->Fill behaviour globally or not. My 0.02 Euro: I would like to change the Edit->Fill behaviour globally and at the same time provide a three-lines script (or code in the core) that would register itself as "Edit->Fill with BG" and would swap the colors, call gimp-edit-fill and restore the colors again. So those who prefer the current behaviour could bind Ctrl-. to it. -Raphael
Re: v 1.1.17 libintla error
On Wed, 16 Feb 2000, "Tony Webster" <[EMAIL PROTECTED]> wrote: > During the make process on my Mandrake Linux 7.0 machine of Gimp > 1.1.17 I received the following error. > > Running Mkbootstrap for Gimp::Lib () > chmod 644 Lib.bs > LD_RUN_PATH="/usr/local/lib" cc -o ../blib/arch/auto/Gimp/Lib/Lib.so > -shared -L/usr/local/lib -l./../../../libgimp.libs > -Lirprefix/../../libgimp -lgimp-L/usr/lib -lglib /intl/libintl.a Lib.o > cc: /intl/libintl.a: No such file or directory This is looks like a bug in the Makefile for the Perl plug-in in 1.1.17. If you do not want to edit that file, you can configure the Gimp with --disable-perl (but then you loose Perl) or you can create as root a symbolic link /intl pointing to the correct directory. This bug will probably be fixed in CVS soon, if not done already. -Raphael
mkbrush.scm
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. (Presumably this script inspired the current app unctionality, but isn't somehow called by it) Nick.
