Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present

2000-03-22 Thread Zach Beane - MINT

[snip]
 I have just send a better bug report to the bugtracker, hoping that it
 will help you to fix the bugs in the scripts.  However, I see that the
 form on Xach's site wraps the text in a very ugly way, so my nicely
 formatted bug report is now very difficult to read (#7732).  I will
 send a copy of the bug report to you by private e-mail.

I just changed it so it doesn't wrap at all.
 
[snip]
 
 Well, I still think that I understood the situation quite well.  ;-)
 The difference between you and me is mostly a matter of opinion.  I
 consider that running the Perl-Fu scripts with the default values when
 there is no Gtk is a bad thing (because of the warning box, because it
 is difficult to guess what the script will do without seeing its
 parameters, because there is no help, because some scripts disable the
 undo on the image and because of the crashes that will hopefully be
 fixed).  So that's why I consider that installing these scripts when
 Gtk is not present is a bug, or at least a disservice to the user.  I
 understand that you disagree and you would prefer to install them
 anyway.  Well, we can at least agree to disagree...

I stuck a simple poll up regarding this a few days ago for the #gimp
channel. Participation was rather light. Maybe with some exposure from the
list, a more meaningful result could be determined:

   http://www.moviegroups.org/poll/one-poll.tcl?poll_id=22

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



Re: Bug? cannot duplicate color channel

2000-03-14 Thread Zach Beane - MINT

On Tue, Mar 14, 2000 at 06:13:18AM -0800, pixel fairy wrote:
 is seems you cannot do to the three color channels what you can to any 
 other, such as duplicate.
 duplicating a color channel is usefull for things like masking out 
 complex selections (like hair)

The RGB channels are not real channels, unfortunately. They're
pseudo-channels that don't act normal. Perhaps they will be promoted to real
channels after 1.2 comes out.

(Here is where Sven chastises me for saying this and tells me to read his
notes from the Camp...I would, if I knew where they were!) :)

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



Re: active gradient suggestion

2000-02-20 Thread Zach Beane - MINT

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...

Perhaps it's time to make the TODO file a more comprehensive list of items
that are planned for post-1.2...

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



active gradient suggestion

2000-02-19 Thread Zach Beane - MINT

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

2000-02-19 Thread Zach Beane - MINT

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: [Slightly off-topic] Gimp mailing list archives?

2000-02-18 Thread Zach Beane - MINT

On Fri, Feb 18, 2000 at 10:36:19PM +0100, Raphael Quinet wrote:
 Is there any current archive for the Gimp mailing lists?

http://www.mail-archive.com/gimp-user%40xcf.berkeley.edu/ and
http://www.mail-archive.com/gimp-developer%40scam.xcf.berkeley.edu/ have
relatively recent archives. They're at least a week behind due to some
hardware trouble, but I think they're trying to bring things up to speed
soon.

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



Re: Edit Fill behaviour change?

2000-02-14 Thread Zach Beane - MINT

On Mon, Feb 14, 2000 at 05:15:59PM +, Austin Donnelly wrote:
[snip]
 
  It's not clear why it behaves differently from the Bucket Fill tool,
  but it has done so forever. But then I only use DnD for filling
  nowadays since you can't get the color wrong then.
 
 I say fix the behaviour and change the scripts anyway.  Tedious, but
 makes the most sense.

I still don't think this is broken. It's an arbitrary choice, and I think we
should stick with historical precedent.

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



Re: Performance

2000-02-03 Thread Zach Beane - MINT

On Thu, Feb 03, 2000 at 10:35:33AM -0600, Elan Feingold wrote:
  Shouldn't we increase the default for the tile_cache_size? GIMP
  was shipped with the default of 10MB years ago. Memory is cheap
  nowadays and I guess we can expect the average user to have
  more RAM available. I'd suggest setting it to 32MB.
 
 Instead of guessing at fixed amounts, why not:
 
   - Detect how much memory the user has.
   - Pick a reasonable default in terms of percentage (say, 50%).
   - Let the user change this default, also in terms of percentage.
 
 That way, the default the Gimp ships with will work with all systems, and
 also on a given system if the user dumps more memory in, the Gimp will
 automagically have better performance.

I agree that magic numbers are foolish to use, but I do think that the
method for choosing a default should be carefully planned. Your system
sounds good, but the entire issue merits some discussion and possible
alternatives.

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



Re: Plugins at Sourceforge

2000-01-28 Thread Zach Beane - MINT

On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote:
[snip]
 
 However, since the masses haven't cried out yet, I guess we can try and
 see how it works in practise.

Count this as a cry out against it. I suggest waiting for a logical pause in
development, such as the release of GIMP 1.2, to begin making these
not-insubstantial changes in source management.

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



Re: Help System

1999-11-10 Thread Zach Beane - MINT

On Wed, Nov 10, 1999 at 11:10:14AM -0500, Federico Mena Quintero wrote:
   - Help us to make a seperate version of GtkXmHtml that compiles on a lot
 of setups and fix the Gimp configure script.
 
 Just so you know, GNOME is dropping GtkXmHTML because it is no longer
 being maintained and is not very good in general.  Anders is working
 on a very nice GtkHTML widget, and the new GNOME help browser will use
 it while Mozilla will hopefully be finished somewhere in the next millenium.
 
 The GIMP should really use the GNOME help browser instead of
 reinventing the wheel.

Will it be possible to get just the wheel without the rest of the car?

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt