Re: Performance

2000-02-05 Thread Daniel . Egger

On  4 Feb, Raphael Quinet wrote:

 I wouldn't be too sure about that.  On a system that I was previously
 administering (students' network at the university), I have seen some
 users that were using /var/tmp or /tmp to store their applications
 while they were logged in, and deleted the stuff afterwards.

 In our university you just have a chance to compile anything if you 
 are using /tmp. It is also a very convenient place because everything 
 else will go over NFS and thus is dog slow. You can even leave your
 programms there if you make sure that you get the same machine back if
 you need them or the /tmp-machine is at least running Linux... :)
 It makes also sense to crosscompile projects like GIMP on an Alpha
 maschine with plenty of memory and very fast RAID clusters. 

 progress?  On third thought...  If your disk quota is exceeded, you 
 will not even get the core dump.  On fourth thought... :-)  Who in 
 their right mind would use the Gimp on a systems that has such strict 
 constraints?

 I do sometimes, but you are right: In general it's better to convince
 the sysadmin to install a programm in a place where everyone might use
 it than forcing eveyone to do it for himself. Unfortunately you won't
 have a big chance to get your favourite latest snapshot of some
 software installed :( 

-- 

Servus,
   Daniel



Re: [gimp-devel] Re: Some UI inconsistencies and a patch....

2000-02-05 Thread Daniel . Egger

On  4 Feb, Steinar H. Gunderson wrote:

 I'm constantly finding myself looking for tools. I know that they are
 there, but I have to stop and look closer at almost every single tool.
 There are simply too many tools (some of them could well be combined),
 and the icons look very much the same (believe it or not). I don't
 know if colour would solve this (or just add clutter), but we should
 really get to reduce the number of tools, as a previous poster
 suggested.

 Yes, at least the Pencil now is rather useless

 Now, where are the users? :)
 
 They're buried in the pile of messages from gimp-developer (I was told
 "2 or 3 messages per day" when I joined) ;-)

 Bad luck... Believe me, it'll go better at least in summer :)

-- 

Servus,
   Daniel



Removing pencil?

2000-02-05 Thread Daniel . Egger

Hiho!

 I think it's time to remove that useless pencil before the release
 of the magic version 1.2. Did anyone use it in the last time?
 It contains no functionality that paintbrush doesn't have except of
 hard edges (anyone needing that "feature"?)...

 Anyway: This is up for discussion on this list. Quite a lot people
 I know think it's useless but maybe you don't think so. :)

 Patch is appended

-- 

Servus,
   Daniel

 diff23.gz


Pathtool?

2000-02-05 Thread Daniel . Egger

Hi developers,

 At the moment we have got 2 Pathtools in GIMP. One which is called
 Bezierselect in the Toolbox but has a Path dialog
 (in the Layers/Channels dialog???) and another one called Path tool.

 The latter works a lot nicer IMHO but I haven't managed yet to
 transform a path into a selection and the former has better support
 in form of a dialog. Which one should we keep? Or better: should we
 merge it into one Tool which works nicely AND has a support dialog?

-- 

Servus,
   Daniel



Re: Edit Fille behaviour change?

2000-02-05 Thread Daniel . Egger

On  4 Feb, Kelly Lynn Martin wrote:

What does Photoshop do?
 
 What does that matter?  

 Photoshop is the most used graphicstool out there and it makes sense
 to have a closer look on their behaviour especially in the UI sector.

 Anyway, even if books do now say that Fill fills with the background
 color, the obvious way would be using the foreground color. I'd prefer
 that, too, but we then also have to correct all plugins/scripts! 

-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-05 Thread FUJITA Yuji

From: [EMAIL PROTECTED]
Subject: Pathtool?
Date: Sat, 5 Feb 2000 12:03:44 +0100 (CET)

 Which one should we keep? Or better: should we
  merge it into one Tool which works nicely AND has a support dialog?

I hope them to be merged into one tool with support dialog.

Anyway, the dialog window title should be something like
"Layers, Channels and Path" or so.


FUJITA Yuji
[EMAIL PROTECTED]



Re: The toolbox...

2000-02-05 Thread Sven Neumann

  Kelly did a try to clean up this issue with the hwrapbox which is
  currently used in the toolbox. Unfortunately this hasn't helped a lot
  and since other approaches for the toolbox after 1.2 rise up it seems
  sensible to revert to the old behaviour (which is fine, what should
  the use of gtkhwrapbox get us?)...

It works much better now (/me thanks Kelly). Well, if you don't see the 
advantages of a more configurable toolbox layout, I can't help you... 
Of course this needs to get better before 1.2, but I don't hink that 
lamenting about it will help.


Salut, Sven




Re: Removing pencil?

2000-02-05 Thread Sven Neumann

  I think it's time to remove that useless pencil before the release
  of the magic version 1.2. Did anyone use it in the last time?
  It contains no functionality that paintbrush doesn't have except of
  hard edges (anyone needing that "feature"?)...

It is a very important feature, believe me! But the pencil can easily
be merged with the Paintbrush by adding a "Hard Edges" option. This will
add all the goodies the paintbrush has (like gradient and fadeout) to 
the pencil tool for free.

I'm all for removing the Path Tool, the Xinput Airbrush and and merging
Pencil and Paintbrush. If I counted correctly this would reduce the 
number of tools to 24. This is a perfect number of tools since 
24 % [2|3|4] == 0 which means we always get a nicely layed out toolbox.


Salut, Sven




Re: Pathtool?

2000-02-05 Thread Sven Neumann

Hi,

Daniel, please, do you follow the discussions on this list?

  At the moment we have got 2 Pathtools in GIMP. One which is called
  Bezierselect in the Toolbox but has a Path dialog
  (in the Layers/Channels dialog???) and another one called Path tool.
 
  The latter works a lot nicer IMHO but I haven't managed yet to
  transform a path into a selection and the former has better support
  in form of a dialog. Which one should we keep? Or better: should we
  merge it into one Tool which works nicely AND has a support dialog?

OK, I'll repeat it once again: The new tool was an approach to design a 
better path tool taken by Simon Budig. The goal was to exchange the user
interface of the BezierSelect tool when it becomes useable. Simon didn't
find the time to complete it and noone else did. There's no need to 
discuss which path tool should make it into 1.2, since there is only one 
that is working. You are too late if you want to change this now!

The Path tool will not be in Gimp-1.2. Same applies to the Xinput Airbrush 
unless someone fixes it really quick now (I see a small chance for the 
Xinput Airbrush to be fixed in time since its a standalone tool).


Salutm Sven



Salut, Sven








Re: Pathtool?

2000-02-05 Thread Daniel . Egger

On  5 Feb, FUJITA Yuji wrote:

 Which one should we keep? Or better: should we
  merge it into one Tool which works nicely AND has a support dialog?
 
 I hope them to be merged into one tool with support dialog.
 
 Anyway, the dialog window title should be something like
 "Layers, Channels and Path" or so.

 Yes, forgot to mention that :)

-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-05 Thread Daniel . Egger

On  5 Feb, Sven Neumann wrote:

 OK, I'll repeat it once again: The new tool was an approach to design
 better path tool taken by Simon Budig.

 Well, I talked with Simon about it.

 The goal was to exchange the
 user interface of the BezierSelect tool when it becomes useable. Simon
 didn't find the time to complete it and noone else did.

 But it seems that work on the Bezierselect was done...

 There's no
 need to discuss which path tool should make it into 1.2, since there
 is only one that is working.

 It works, it may not have all the features that Simon desired but it's
 nice nevertheless...

 You are too late if you want to change
 this now!

 Why? Fixing tools which are in there and removing redundant code is
 our work at the moment.
 
 The Path tool will not be in Gimp-1.2.

 I'd like to hear the thoughts of developers, too

 Same applies to the Xinput
 Airbrush unless someone fixes it really quick now (I see a small
 chance for the Xinput Airbrush to be fixed in time since its a
 standalone tool).

 OK... 

-- 

Servus,
   Daniel



Re: Removing pencil?

2000-02-05 Thread Daniel . Egger

On  5 Feb, Sven Neumann wrote:

 It is a very important feature, believe me!

 It's your right to consider it useful, I don't and won't believe you...

 But the pencil can easily
 be merged with the Paintbrush by adding a "Hard Edges" option.

 Yes, if you appreciate. But the makes the eraser rather useless...
 We could add the eraser features, too and use the same codebase for
 these 2 tools.

-- 

Servus,
   Daniel



Re: The toolbox...

2000-02-05 Thread Daniel . Egger

On  5 Feb, Sven Neumann wrote:

 It works much better now (/me thanks Kelly).

 "much" is a bit too much... :)
 It definitely works better but the current behaviour isn't acceptable
 for the release anyway 

 Well, if you don't see the advantages of a more configurable toolbox
 layout, I can't help you...

 Configurable? If it WOULD work then I'd have nothing against this
 feature but it doesn't i.e. won't allow to change the orientation of
 any of the widgets in it and thus is a decent bug and nothing more.

 We will have much better approaches in 1.3 (I have plans for a fully
 configurable toolbox including menus etc.) and since we can't change
 anything in the toolbar without modifying the code which isn't an
 option for a user I'd really recommend to remove that "feature" or
 at least fix it (I don't get the logic behind it so I won't touch it,
 will you?)...

 Of course this needs to get better before 1.2, but I don't
 hink that lamenting about it will help.

 The only thing I want is a stable featurerich release of GIMP and that
 really soon now. Everything else doesn't matter. Instead of bashing me
 you should rather keep our goal in mind. 

-- 

Servus,
   Daniel



Re: Removing pencil?

2000-02-05 Thread SHIRASAKI Yasuhiro

Hi,

I'm all for removing the Path Tool, the Xinput Airbrush and and merging
Pencil and Paintbrush. If I counted correctly this would reduce the 
number of tools to 24. This is a perfect number of tools since 
24 % [2|3|4] == 0 which means we always get a nicely layed out toolbox.

core and plug-ins feature isn't frozen yet?

--
SHIRASAKI Yasuhiro



Re: Pathtool?

2000-02-05 Thread Sven Neumann

Hi,

  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!

  I'd like to hear the thoughts of developers, too

You hereby finally managed to make your way onto my kill-list. Expect me 
to ignore your mails in the future.


Salut, Sven




Re: Removing pencil?

2000-02-05 Thread Daniel . Egger

On  5 Feb, SHIRASAKI Yasuhiro wrote:

 I'm all for removing the Path Tool, the Xinput Airbrush and and
 merging Pencil and Paintbrush. If I counted correctly this would
 reduce the number of tools to 24. This is a perfect number of tools
 since 24 % [2|3|4] == 0 which means we always get a nicely layed out
 toolbox. 

 core and plug-ins feature isn't frozen yet? 

 This would be a proper cleanup. Do you want to leave old cruft in for
 release rather than removing it?
  
-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-05 Thread Daniel . Egger

On  5 Feb, Sven Neumann wrote:

 Do you have any idea how much work is needed to integrate it with the 
 Paths dialog?

 No, not yet, but I'll have a closer look on this.

 A number of new bugs would certainly be introduced by
 doing so. That's why I say: It's too late!

 Every line of code introduces new bugs...

  I'd like to hear the thoughts of developers, too
 
 You hereby finally managed to make your way onto my kill-list. Expect
 me to ignore your mails in the future.

 Nice way of discussing problems, congratulations

-- 

Servus,
   Daniel



Re: Removing pencil?

2000-02-05 Thread Sven Neumann

 I'm all for removing the Path Tool, the Xinput Airbrush and and merging
 Pencil and Paintbrush. If I counted correctly this would reduce the 
 number of tools to 24. This is a perfect number of tools since 
 24 % [2|3|4] == 0 which means we always get a nicely layed out toolbox.
 
 core and plug-ins feature isn't frozen yet?

Yep, they are. But the Path tool and Xinput Airbrush have only been added 
with the option of being removed before 1.2. Since they are not integrated 
into any other tools, it's only a matter of removing a few files and some
small changes in tools.c and menus.c.

Merging the Pencil and Paintbrush is somehow similar since they are 
practically the same tool with only one parameter changed in the call
to paint_core_paste_canvas (). So we can merge them w/o having to be 
afraid of introducing new bugs.


Salut, Sven




Re: Pathtool?

2000-02-05 Thread Nick Lamb

On Sat, Feb 05, 2000 at 01:46:14PM +0100, Sven Neumann wrote:
 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. Broken stuff with no-one working on it is doomed.

Please do not step forward and say "I'll do it", the time for that was
in November or at the latest December, and there was conspicuous silence
during my last Triage thread from those named to defend their code.

Now is a good time to check-in fixes to code that you left in an
untidy state (expect some File plug-in code in that vein) and to
file bug reports for mysterious occurences that you've been putting
up with during the development cycle.

Nick.



Re: [gimp-devel] Re: Some UI inconsistencies and a patch....

2000-02-05 Thread Marc Lehmann

On Fri, Feb 04, 2000 at 10:01:04AM +0100, Raphael Quinet [EMAIL PROTECTED] wrote:
 I agree with you, Mark.  Knowing the difference between tools and
 plug-ins is rather important, but is not easy for the beginner who has
 several dialogs open and is not familiar with all of them.  If the

The fine thing is, that the solution for:

- macro recording
- repeat last
- tracing (for development tools)
- pdb debugging

Is the same, so fixing one (I suggest the macro recording problem) will
make the others very easy.

Soo... I am very certain that all this will be fixed quite automatically..

 Yup!  I definitely prefer redundancy if it improves the usability.  In
 this case, making sure that all tools contain "Tool" in their title
 (e.g. "Pencil Tool") would avoid some confusion.  Even if this sounds
 a bit ridiculous.

The question is rather, who is responsible for patches that are already
applied but are in a dubious state?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: [gimp-devel] Re: Some UI inconsistencies and a patch....

2000-02-05 Thread Marc Lehmann

On Fri, Feb 04, 2000 at 02:59:11PM +0100, [EMAIL PROTECTED] wrote:
  "Repeat Last" will repeat the last plug-in. Since menus do not provide
   feedback of wether an entry is a plug-in or "built-in" (I think it
  would even be wrong to do so), you have to know this, which is not
  easy for beginners.
 
  Repeat last should repeat anything that makes sense to be repeated
  if it doesn't you should create a bugreport and we'll have to fix this.

Come on... this isn't news, and totally obvious to everybody...

  This is wrong. Many people (like me) rely on text to quickly evaluate
  situation. This is common for unix-type-people. Icons are a much
  slower feedback then text.
 
  Let's replace the icons by text :)

Would suit me. Shall I apply a patch? OF coursem that would be just as
braindamaged as removing text and using icons *instead*.

  I do select them by look, I only know very vague where e.g. Blend sits.
  If it isn't clear to an experienced user what tool lies behind a specific
  icon then the icons are rubbish. 

Please change your attitude: not everybody on the world is a copy of you,
and many people react differently. If something helps somebody else and
does not impair the usability for you than removing that extra redundancy
is wrong.

  Thats not the point. The point is effective user feedback.
  Now, where are the users? :)

Here is one. If you are not a user you should not decide whats best
for them. Especially not if you limit your horizon to a single person
(yourself).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Edit Fille behaviour change?

2000-02-05 Thread Alex Harford

On Fri, 4 Feb 2000, Garry R. Osgood wrote:

 Tom Rathborne wrote:
 
  I just noticed this new CVS entry:
 
  Fri Feb  4 18:27:16 CET 2000  Stanislav Brabec  [EMAIL PROTECTED]
 
  * app/global_edit.c: edit_fill with foreground, not background.
 
  snipped...
 
 Indeed, some of the 1.2 - revised books are well into pre-press
 and some are out in the market.  These books suffer too.
 
 From "Gimp - Essential Reference (Covers GIMP 1.2, GTK 1.2 and
 Script-Fu" by Alex Harford, published by New Riders (Page 32):
 
 "Clear and Fill are simple tools for working with selections
 and entire layers... discussion of Clear omitted ... The Fill
 ([Ctrl+.]) operation adds paint to the current selection. The selection
 is always the *background* color even if there are layers or an Alpha
 channel. emphasis mine Fill is therefore useless when working
 with a flat image without an Alpha channel because it has the same
 effect as Clear..."

Well, the publisher knew that they were rushing this when they released
the book already.  I will note this on my errata page.

--
Alex HarfordAlcohol and calculus don't mix.
http://www.dowco.com/~alexh Don't drink and derive.
[EMAIL PROTECTED] Tel: (604) 225-0601



Re: Removing pencil?

2000-02-05 Thread Garry R. Osgood

Sven Neumann wrote:

 snipped...

 I'm all for removing the Path Tool,

Agreed: In my opinion, there is just too much work to integrate
for March 31 (56 days away and counting).

 the Xinput Airbrush

Agreed: I've just got Wacom Intuos working with GTK+/GDK on SGI,
and on this platform using the Xinput Airbrush with the tablet
crashes Gimp nearly every time.

 and and merging
 Pencil and Paintbrush.

Agree in concept, as part of a more unified paintbrush for 1.3, but
I vote that we do not remove the pencil for the 1.2. About half
the people I speak with think of it as a "hard-edge paintbrush"
and their instincts have them grab the pencil whenever they want
to do "precision" drawing.

I also agree with Nick Lamb in that our energies ought to be
spent in ferreting out unusual behaviour, logging bug
reports, and fixing those that are tractible, given our various
skills and talents. I believe this effort is more important than
rescuing tools that just aren't done yet.

Just this morning I discovered (1) Fuzzy select works
fine with core pointers but with when the tablet is
being used as a pointer device, Fuzzy select can run for minutes,
and its not unusual to find 60 -120 references to the function
find_contiguous_region_helper() on the call stack.
(runaway recursion - don't know why, yet) (2) Confirmed
with Calvin Williamson on Wednesday that the smudge tool
should *never* introduce the color black when  (a) "Keep
Trans=TRUE" AND (b) No black is in the image AND
(c) the user smudges from transparency to opacity. (3)
After switching to the tablet, then using tool icon drag-and-drop
in the Device Status dialog box, I *usually* get a segment violation.

Three bugs in four days. And I wasn't really looking for them,
They just happened when I was trying to have fun.
I don't think we can even begin to claim Gimp Stability yet.

56 days to All Fools' Day.  Must file some bug reports now.

Be good, be well

Garry Osgood




Unnecessary code

2000-02-05 Thread Martin Weber

I found also that app/gimpui.c and app/gimpunit.c contain partially the
same contents as libgimp/gimpui.c and libgimp/gimpunit.c



Saving pbm

2000-02-05 Thread Martin Weber

When I save pbm in GIMP it is not saved as pbm but as pnm.

Martin



Re: Re: Some UI inconsistencies and a patch....

2000-02-05 Thread Marc Lehmann

On Sat, Feb 05, 2000 at 12:53:56AM +0100, "Guillermo S. Romero / Familia Romero" 
[EMAIL PROTECTED] wrote:
 At home 3 of 3 read text better than understand icons. Dunno way, but that
 is the fact (rare family?).

No. Text has much higher information bandwidth than icons for "skilled
people". The conditions are:

a) one can read silent and quickly (i.e. without repeating the words
   they read in their mind). Most computer users are of that type.
b) one is trained in the language (that's why icons are more often found
   at public places like airports)
c) one is trained with the environment (i.e. no absolute gimp beginner)

 Take, for example, the gimp toolbox. Manye of the icons look almost the
 Yes! True, and sometimes by trial and error, or shortcut (faster and never
 fails).

Thank godness we have undo ;- However, you cannot put text there, unless
we use a more horizontal design. (Please: I do not advocate changing these
icons by text!!).

 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.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: important: automatic mirroring to the gimp cvs

2000-02-05 Thread Kevin Turner

On Fri, Jan 28, 2000 at 01:38:32AM +0100, Marc Lehmann wrote:
plug-ins/maze/*
 
 is being written back. This (unfortunately!!) means that changes done to
 these files in the gimp cvs will get overwritten. I've not found a better
 way to synchronize two cvs trees better (maybe CVSup would help, but...)

Oh.  Then maybe this is not so good.  It is true that at some point I
will decide to hack Maze and will appreciate having write-access to it
at that time...  But it looks like there are some folks who have been
hard at work updating plug-ins in the main tree en masse recently.  The
last thing I want to do is make it harder for them...  So I'm commenting
maze out of the PLUGIN_CVS control file until this auto-clobber
situation is resolved, and will only use the Sourceforge services for
unstable plug-ins for now.

-- 
[EMAIL PROTECTED] | OpenPGP encryption welcome here, see X-DSA-Key
  aka Acapnotic



Re: important: automatic mirroring to the gimp cvs

2000-02-05 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 01:38:32 +0100, Marc Lehmann [EMAIL PROTECTED] said:

Ok. I've just enabled automatic mirroring from the sourceforge cvs
back to the gimp cvs.

FWIW, I think this should be used sparingly.  It is my belief that
we should try to move plugins into a separate package from the GIMP
core; I would be quite happy to see the plugin directory go away
_entirely_ from the main GIMP CVS.  This really isn't that big a
deal.  Lots of applications require multiple packages to get
"everything", and GIMP is a _large_ application.

Kelly



One more feature?

2000-02-05 Thread Seth Burgess

I'd really like to see the setting for default brush reappear.  So
much so that I'd do it myself.  

Hows this fit with the freeze?  I hate to violate the freeze, esp
since its been getting better.  But I'm SO SICK OF THAT CALIGRAPHIC 
BRUSH (10x10)!  Comments?

Seth
[EMAIL PROTECTED]

-- 
~/.sig: [E]xit, [H]alt, show [S]tack trace or [P]roceed:



Plugins at Sourceforge

2000-02-05 Thread Garry R. Osgood

In ChangeLog :
 Fri Jan 28 01:16:35 CET 2000  Marc Lehmann [EMAIL PROTECTED]

* PLUGIN_CVS: updated to give Kevin Turner write access to
the maze plug-in (therefore, the maze plug-in is no longer
managable within the gnome cvs server. If you have any
comments/suggestions...)

Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating
where "authoritative source" resides?

Be good, be well

Garry Osgood



Re: important: automatic mirroring to the gimp cvs

2000-02-05 Thread Sven Neumann

Hi,

 Ok. I've just enabled automatic mirroring from the sourceforge cvs back
 to the gimp cvs.
 
 The file gimp/PLUGIN_CVS in the cvs tree controls which paths are mirrored
 and which are not. If anything goes havoc just delete that file and the
 script will stop doing anything.
 
 At the moment, only
 
ChangeLog.plugins
plug-ins/maze/*
 
 is being written back. This (unfortunately!!) means that changes done to
 these files in the gimp cvs will get overwritten. I've not found a better
 way to synchronize two cvs trees better (maybe CVSup would help, but...)

NO!!

Sorry, the idea of developing plug-ins outside the gimp tree is probably 
a good one. But it is absolutely impossible to do that now. We are
approaching a release and we need control over the plug-ins that are going
to be distributed with gimp-1.2.

I liked the whole idea, but I wasn't aware that are you planning to do that
before 1.2. If this is absolutely necessary, we might consider branching the
plug-ins. But doing so will certainly lead to more problems than it solves.

So, if Kevin thinks that Maze has to be worked on before 1.2 is out, he may
either send patches or ask for the maze plug-in being removed from the
distribution.


Salut, Sven



Re: Plugins at Sourceforge

2000-02-05 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 12:40:32 -0500, Zach Beane - MINT [EMAIL PROTECTED] said:

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.

My position is sourceforge should be used at this time only for
plug-ins which are not already in the source tree.  Such plug-ins will
not be a part of 1.2 anyway because 1.2 is frozen at this time.  When
1.3 development begins, we can decide what to do with the plug-ins
currently in the distribution.

Kelly



Re: Plugins at Sourceforge

2000-02-05 Thread Glyph Lefkowitz


On Fri, 28 Jan 2000, Zach Beane - MINT wrote:

 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.

Hear hear.  Let's get Gimp 1.2 out the door please, before we start
mucking with everything's structure?  Keep in mind there are lots of users
waiting for a `stable' release before they get all the new nifty
functionality that 1.2 has to offer.

So get the GIMP 1.2 release out, with the crufty plugins and all, and THEN
start making changes like this.  for 2.0.

---
Even if you can deceive people about a product through misleading statements,
sooner or later the product will speak for itself.
- Hajime Karatsu



Re: Print plug-in

2000-02-05 Thread Nick Lamb

On Mon, Jan 31, 2000 at 11:23:48PM +0100, Marc Lehmann wrote:
 Just to throw in my opinion: gimp is _NOT part of gnome, other than in a
 technical way, and I personally think it is important that it stays so.

From the user's perspective The Gimp is part of GNOME. For 1.2 this
won't be really true, but only because of lack of development time to
handle the changes. Is there serious concern here that user's will
NOT want a GNOME-enabled Gimp in 2001 or 2002 when the 1.3 series
might reasonably be expected to conclude with a new stable release?

I suppose we might conclude that vendors will ship only KDE, in which
case maybe those wacky Qt people will show up again and threaten to
code a replacement Kim*g*sh*p if we won't re-write Gimp in C++ :)

Which reminds me, we were supposed to be separating the core from the
UI in the 1.3.x devel series, so maybe then everyone will have a
better opportunity to evaluate the dependencies of Gimp.

But - back to 1.1.x coding!

Nick.



Re: Translation inconsistency

2000-02-05 Thread Kevin Cozens


If you need to tell USERS something important then it should not be
in these strings, you should rather write a paragraph for the GUM.

  (B) don't mark the strings for translation, not in the core, neither in
  the plug-ins

It depends on what is meant by having something important to tell the 
users. If the information is just letting the user know how to do something 
or what a particular feature does this should be in the manual. If its a 
message as a result of a run time situation (input needed from the user, 
status message, or an error message) this should be translated based on the 
users specified language.


Cheers!

Kevin.  (http://www.interlog.com/~kcozens/)

Internet:kcozens at interlog.com   |"What are we going to do today, Borg?"
   or:ve3syb at rac.ca  |"Same thing we always do, Pinkutus:
Packet:ve3syb@va3bbs.#scon.on.ca.na|  Try to assimilate the world!"
#include disclaimer/favourite|  -Pinkutus  the 
Borg



Re: Print plug-in

2000-02-05 Thread Glyph Lefkowitz


On Tue, 1 Feb 2000, Raphael Quinet wrote:

 My personal opinion: I'm all for using some of the GNOME things
 (especially gnome-font, gtk-pixbuf and gnome-canvas) as long as they
 do not have any dependencies on ORBit or other stuff that is difficult
 to compile on non-Linux systems or stuff that is simply not needed.

Well, the *best* solution would be to try to fix ORBit so that it would
compile on other systems more easily.  I don't think this would be too
difficult, but I don't have any time to volunteer ... so I cast my
sympathies with your suggestion.

Let's keep in mind that all that 'bloat' in gnome actually *does*
stuff.  Once the object-model has solidified and CORBA actually starts
happening between desktop components on a large scale, being able to send
GIMP script commands from other applications, for example, would be
awesome.

I don't know how compatible mico is with ORBit -- but it seems to me like
after these respective implementations have some apps written for them, it
should be possible to write a GNOME/KDE compatibility layer that would
even allow apps from different desktop heritages to talk to each other.  
So when we speak of 'taking a side in the desktop war', keep in mind that
whichever side you're on, you have functionality that the other side can
exploit... it would be easier for KDE to interface with "some GNOME
application" in the future than for it to develop seperate interfaces for
GNOME and the GIMP.  Where would the bloat be then?

---
Even if you can deceive people about a product through misleading statements,
sooner or later the product will speak for itself.
- Hajime Karatsu



Re: Print plug-in

2000-02-05 Thread Raphael Quinet

On Tue, 01 Feb 2000, Kelly Lynn Martin [EMAIL PROTECTED] wrote:
 GNOME claims GIMP as part of GNOME because GIMP is better than any of
 the existing GNOME apps.  They're trying to piggyback on our success.
 Personally, I think this is odious, but hey...

This statement is ridiculous.  They are not claiming that they wrote
the GIMP.  They just state that it will be included as part of the
Gnome-Office suite.  Besides, you should know that several of the
early and current developers of the GIMP are also contributing to
GNOME.  So it's not like the two projects are completely unrelated,
even if they are maintained separately and they do not depend on each
other.  In case you did not know that, will this fact make you stop
using the GIMP completely just because you think that some of the
people on this list have GNOME stamped on their forehead?

Please calm down instead of trying to start a flamewar.  This list is
supposed to be for people who intend to write code or contribute to
the development of the GIMP.  It is not for arguing like kids about
who does things better and whatnot.

My personal opinion: I'm all for using some of the GNOME things
(especially gnome-font, gtk-pixbuf and gnome-canvas) as long as they
do not have any dependencies on ORBit or other stuff that is difficult
to compile on non-Linux systems or stuff that is simply not needed.

-Raphael



Re: Edit Fille behaviour change?

2000-02-05 Thread Tuomas Kuosmanen

On Fri, Feb 04, 2000 at 07:07:37PM -0500, Zach Beane - MINT wrote:
 On Fri, Feb 04, 2000 at 06:59:57PM -0500, Tom Rathborne wrote:
  I just noticed this new CVS entry:
  
  Fri Feb  4 18:27:16 CET 2000  Stanislav Brabec  [EMAIL PROTECTED]
  
  * app/global_edit.c: edit_fill with foreground, not background.
  
  Checked the code. Looks like 'Fill' now uses the foreground. So I
  recompiled the GIMP. Indeed, the changes do what it says.
  
  Fill (by default Ctrl-.) has filled using the background colour in the
  GIMP for as long as I can remember. I don't think it's a bug
 [snip]
 
 I agree. I have grown very accustomed to the existing behavior, and I don't
 think it should be changed.

What? I never noticed that existed.. ?! :) And I _thought_ I knew Gimp
well.. 

However, I seem to use the DND more on this, dragging colors from palette
has turned into a very much used feature for me.. And I first thought the
DND doesnt really matter.. :)

Speaking of that, has anyone else noticed that the DND does not always work
on the current CVS gimp? It has been like that for about a week or so. I can
drag the color there, but it just bounces the color back to the palette.
Bucket fill works fine on the same place though so it cant be that I try to
fill something that cannot be filled with color etc.. weird.

Tuomas

-- 

.---( t i g e r t @ g i m p . o r g )---.
| some stuff at http://tigert.gimp.org/ |
`---'



Re: Removing pencil?

2000-02-05 Thread Kelly Lynn Martin

On Sat, 5 Feb 2000 11:45:16 +0100 (CET), [EMAIL PROTECTED] said:

 I think it's time to remove that useless pencil before the release
of the magic version 1.2. Did anyone use it in the last time?  It
contains no functionality that paintbrush doesn't have except of hard
edges (anyone needing that "feature"?)...

I find it very useful when working on small pixmaps (like icons).

Kelly



Re: Removing pencil?

2000-02-05 Thread Seth Burgess

My vote is for the merge of pencil and paintbrush.  I don't see that 
having a hard-edged paintbrush is really worthy of its own icon, though
it will need an option added in paintbrush.  I don't know of anything
that utilizes pencil in PDB at this point, but maybe I'm mistaken?  I 
doubt removing pencil* would hurt much...

Speaking of PDB, thats something that needs some serious updating - lots
of the abilities are no longer accessible for quite a few of the tools.
gimp-paintbrush for example doesn't include incremental, the fade out
distance, the gradient selection/type, or the units.  I suspect others
have gotten similarly out-of-sync as we madly added niftyness...

I'd hope this would be a pre-1.2 bug-fix, since missing PDB stuff has
traditionally been handled in that manner.

Seth


* Marc Lehmann ([EMAIL PROTECTED]) [000205 16:40]:
 On Sat, Feb 05, 2000 at 07:13:00PM +0200, Tuomas Kuosmanen [EMAIL PROTECTED] wrote:
  in my previous mail on this thread, I use the paintbrush as a "fine tuning"
  tool together with the "real" tool I am drawing with. And if it is the
  paintbrush, then there is no way to toggle fast between those.. clicking a
  checkbox every time instead of pressing a shortcut key sounds clumsy.
 
 I guess the correct fix (in 1.3!!) would be to be able to attach shortcuts
 to checkboxes.
 
 For 1.2 there IMHO shouldn't be a merge.
 
 -- 
   -==- |
   ==-- _   |
   ---==---(_)__  __   __   Marc Lehmann  +--
   --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
   -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
 The choice of a GNU generation   |
  |

-- 
~/.sig: [E]xit, [H]alt, show [S]tack trace or [P]roceed:



Re: story on advogato

2000-02-05 Thread Michael J. Hammel

Thus spoke Shawn T . Amundson
 Just wanted to let you guys know that I wrote up a story
 on advogato.com you guys might want to read for a good 
 laugh: 
 
 http://advogato.com/
 'Andover.Net and the deep pockets of Wilber the GIMP?'

Interesting story, and not really suprising.  I heard some less than
flattering comments about Andover while at LinuxWorld.  VA should have a
better clue, but you never know.

The last comment I saw under this story said that a $2K award was given to
"Wilbur the Gimp".  Since Gimp has no non-profit (or for profit) organization, 
who got that money?  Just curious.
-- 
Michael J. Hammel   The Graphics Muse 
[EMAIL PROTECTED]  http://www.graphics-muse.com
--
One possible reason that things are not going according to plan is that
there never was a plan.  --  Ashleigh Brilliant



Re: story on advogato

2000-02-05 Thread Kelly Lynn Martin

On Sat, 5 Feb 2000 21:00:19 -0700 (MST), "Michael J. Hammel" 
[EMAIL PROTECTED] said:

The last comment I saw under this story said that a $2K award was
given to "Wilbur the Gimp".  Since Gimp has no non-profit (or for
profit) organization, who got that money?  Just curious.

It goes to Yosh, who will decide what to do with it.

Kelly



Re: story on advogato

2000-02-05 Thread Shawn T . Amundson

On Sun, Feb 06, 2000 at 12:44:36AM -0500, Kelly Lynn Martin wrote:
 On Sat, 5 Feb 2000 21:00:19 -0700 (MST), "Michael J. Hammel" 
[EMAIL PROTECTED] said:
 
 The last comment I saw under this story said that a $2K award was
 given to "Wilbur the Gimp".  Since Gimp has no non-profit (or for
 profit) organization, who got that money?  Just curious.
 
 It goes to Yosh, who will decide what to do with it.
 
 Kelly

Wilber t-shirts and hats for everyone!!! ;)

(just kidding)

-Shawn

--
Shawn T. Amundson   [EMAIL PROTECTED]  
Research and Developmenthttp://www.eventloop.com/
EventLoop, Inc. http://www.snorfle.net/

"The assumption that the universe looks the same in every
 direction is clearly not true in reality." - Stephen Hawking



Re: Edit Fille behaviour change?

2000-02-05 Thread Tuomas Kuosmanen

On Fri, Feb 04, 2000 at 08:53:50PM -0500, Kelly Lynn Martin wrote:
 On Fri, 4 Feb 2000 19:07:37 -0500, Zach Beane - MINT [EMAIL PROTECTED] said:
 
 Fill (by default Ctrl-.) has filled using the background colour in
 the GIMP for as long as I can remember. I don't think it's a bug
 [snip]
 
 I agree. I have grown very accustomed to the existing behavior, and I
 don't think it should be changed.
 
 I know it hasn't been customary in the past, but I think such a
 user-visible change should be discussed a little bit.
 
 I also concur and recommend a reversion.

From the logical point Clear should fill the image with background color
(unless we have alpha) and Fill should use foreground. but like I said
earlier, I dont really have an usage pattern on this feature so I cannot say
much..

Tuomas

-- 

.---( t i g e r t @ g i m p . o r g )---.
| some stuff at http://tigert.gimp.org/ |
`---'



Re: Removing pencil?

2000-02-05 Thread Tuomas Kuosmanen

On Sat, Feb 05, 2000 at 11:45:16AM +0100, [EMAIL PROTECTED] wrote:
 Hiho!
 
  I think it's time to remove that useless pencil before the release
  of the magic version 1.2. Did anyone use it in the last time?
  It contains no functionality that paintbrush doesn't have except of
  hard edges (anyone needing that "feature"?)...

Some minor projects like Gnome icons come to mind.. 

I use the pencil every day. And a _lot_. It is way sharper than the
paintbrush even with the 1x1 brush.. I use it as an ultra sharp tool with
low opacity to do microscopic stuff on icons :)

Tuomas

-- 

.---( t i g e r t @ g i m p . o r g )---.
| some stuff at http://tigert.gimp.org/ |
`---'



Re: Removing pencil?

2000-02-05 Thread Tuomas Kuosmanen

On Sat, Feb 05, 2000 at 01:09:13PM +0100, Sven Neumann wrote:
   I think it's time to remove that useless pencil before the release
   of the magic version 1.2. Did anyone use it in the last time?
   It contains no functionality that paintbrush doesn't have except of
   hard edges (anyone needing that "feature"?)...
 
 It is a very important feature, believe me! But the pencil can easily
 be merged with the Paintbrush by adding a "Hard Edges" option. This will
 add all the goodies the paintbrush has (like gradient and fadeout) to 
 the pencil tool for free.

Argh.. I am used to toggle between paintbrush and pencil. Like I pointed out
in my previous mail on this thread, I use the paintbrush as a "fine tuning"
tool together with the "real" tool I am drawing with. And if it is the
paintbrush, then there is no way to toggle fast between those.. clicking a
checkbox every time instead of pressing a shortcut key sounds clumsy.

 
 I'm all for removing the Path Tool, the Xinput Airbrush and and merging
 Pencil and Paintbrush. If I counted correctly this would reduce the 
 number of tools to 24. This is a perfect number of tools since 
 24 % [2|3|4] == 0 which means we always get a nicely layed out toolbox.

Wasnt the path tool intended as a replacement for the current bezier tool
anyway? So it's button was only temporary until it was ready for use. Is it
alive anymore?

Tuomas
-- 

.---( t i g e r t @ g i m p . o r g )---.
| some stuff at http://tigert.gimp.org/ |
`---'



Re: Pathtool?

2000-02-05 Thread Tuomas Kuosmanen

On Sat, Feb 05, 2000 at 01:28:43PM +0100, [EMAIL PROTECTED] wrote:

  There's no
  need to discuss which path tool should make it into 1.2, since there
  is only one that is working.
 
  It works, it may not have all the features that Simon desired but it's
  nice nevertheless...

It doesnt work. You can click to add points, and move them around. It is
very nice start for a new gui for Bezier tool but it is not _working_ since
you cannot really do anything useful with it yet.


Tuomas

-- 

.---( t i g e r t @ g i m p . o r g )---.
| some stuff at http://tigert.gimp.org/ |
`---'



Re: Removing pencil?

2000-02-05 Thread Torsten Rahn



On Sat, 5 Feb 2000, Tuomas Kuosmanen wrote:

 On Sat, Feb 05, 2000 at 11:45:16AM +0100, [EMAIL PROTECTED] wrote:
  Hiho!
  
   I think it's time to remove that useless pencil before the release
   of the magic version 1.2. Did anyone use it in the last time?
   It contains no functionality that paintbrush doesn't have except of
   hard edges (anyone needing that "feature"?)...
 
 Some minor projects like Gnome icons come to mind.. 
 
 I use the pencil every day. And a _lot_. It is way sharper than the
 paintbrush even with the 1x1 brush.. I use it as an ultra sharp tool with
 low opacity to do microscopic stuff on icons :)
 
 Tuomas

Same situation here -- but it's KDE-icons instead ...
I use the pencil most of the time.
;^)

Torsten
 
 -- 
 
 .---( t i g e r t @ g i m p . o r g )---.
 | some stuff at http://tigert.gimp.org/ |
 `---'
 



Re: [gimp-devel] Re: Some UI inconsistencies and a patch....

2000-02-05 Thread Uwe Koloska

You wrote on Fre, 04 Feb 2000:
On Fri, Feb 04, 2000 at 12:48:50AM +0100, [EMAIL PROTECTED] wrote:
  Since the menus were reorganized I am constantly guessing wether
  "Repeat Last" will repeat my last action, the one before or not work
  at all, since you can't tell from the menu anymore.
 
  Huh? Sounds strange, could you provide a snapshot in a private EMail?
  I can't image what this should look like

"Repeat Last" will repeat the last plug-in. Since menus do not provide a
feedback of wether an entry is a plug-in or "built-in" (I think it would
even be wrong to do so), you have to know this, which is not easy for
beginners.


If there was no former plug-in action the menu stays active and suggest that
something will be done.  I think the first plug-in action has to change the
state from disabled to active -- or there has to be a response "no plug-in to
redo / reshow, etc.".

Uwe Koloska

-- 
mailto:[EMAIL PROTECTED]
http://rcswww.urz.tu-dresden.de/~koloska/
----
right now the web page is in german only
but this will change as time goes by ;-)



Re: Edit Fille behaviour change?

2000-02-05 Thread Marc Lehmann

On Sat, Feb 05, 2000 at 07:04:44PM +0200, Tuomas Kuosmanen [EMAIL PROTECTED] wrote:
 (unless we have alpha) and Fill should use foreground. but like I said
 earlier, I dont really have an usage pattern on this feature so I cannot say
 much..

My usage pattern is

Fill = Undo = Swap Colours = Fill = Swap Colours
   ^
   + insert a "this damnit fill braindamage e3stD%$DFZG§ gimp thing"
 here.
   
Apart form the API changes (breaking _some_ plug-ins), I highly welcome
that change. But I'd also say it was not a bug. "but but" now is a good
time to change that.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Shipping which plugins? (was plugins at SourceForge)

2000-02-05 Thread Miles O'Neal

Michael J. Hammel said...
|
|I'm curious why any new plug-ins should be added to the core *at all*.
|Gimp's distribution is fairly large as it is.  Isn't it getting time to
|limit additional plug-ins to the core distribution to plug-ins which are
|considered "vital" in some way?  Even some estoric file plug-ins need not
|necessarily be included with the core package.  Throwing in the kitchen
|sink is what's starting to bloat some Linux distros.

Absolutely.

If anything, we should be looking at whether
some of them might come out.  (Perhaps not
for 1.2, since there are books on the way.)

Otherwise we end up with something like the
USA law, which just grows and gets more
complex until nobody really knows it.

The core distribution should include all the
basic, crucial plugins, and a smattering of
interesting/cool ones.  Beyond that, we
should be looking at how to distribute the
rest.

   - Should we ship packages of somehow
 related (TBD) plugins?
   - Should we just use the registry, but
 with one or more tree views in addition
 to the monolithic, linear view?
   - Just stick with the crurent registry?
 (Good for geeks, too intense for a lot
 of folks)
   - Something else?

If this has been discussed and is being worked on,
and I simply missed it, I apologize.  But at any
rate, I don't think the answer is shipping the
GIMP with every known plugin.  Maybe that could
be an option, but it should *not* be the default.

-Miles



Re: Plugins at Sourceforge

2000-02-05 Thread Robert L Krawitz

   Date: Sat, 5 Feb 2000 12:33:38 -0800
   From: "Michael J. Hammel" [EMAIL PROTECTED]

   I'm curious why any new plug-ins should be added to the core *at all*.
   Gimp's distribution is fairly large as it is.  Isn't it getting time to
   limit additional plug-ins to the core distribution to plug-ins which are
   considered "vital" in some way?  Even some estoric file plug-ins need not
   necessarily be included with the core package.  Throwing in the kitchen
   sink is what's starting to bloat some Linux distros.

Furthermore, look at it from the standpoint of someone trying to
package a Linux distribution (especially vis a vis esoteric file
formats and other things that depend upon external software).  If our
jpeg plugin is part of the core (as an example, I don't want to debate
jpeg per se), then installing the gimp requires installing jpeg.  If
we start forcing a unitary build, then eventually we have everything
depending upon everything else, and we get into the Windows mess all
over again.  It *must* be possible to build and install plugins
separate from the Gimp tree.

Now, that doesn't mean that anything should change *right now*.  It's
entirely too close to the release, as many people have pointed out, to
change something fundamental even if it means an improvement.  It
seems to me that right now everyone except people working on advanced
development should focus on the release.

(And yes, however good Print 3.1 becomes, and even if 3.2 is ready
before Gimp 1.2 is, Gimp 1.2 will contain Print 3.0.  At some point
down the road we might want to put Print 3.2 into a Gimp 1.2 refresh
or point release, but that's another matter.)

-- 
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: Plugins at Sourceforge

2000-02-05 Thread Dean Johnson

Michael J. Hammel spontaneously blurts out:
 
 I'm curious why any new plug-ins should be added to the core *at all*.
 Gimp's distribution is fairly large as it is.  Isn't it getting time to
 limit additional plug-ins to the core distribution to plug-ins which are
 considered "vital" in some way?  Even some estoric file plug-ins need not
 necessarily be included with the core package.  Throwing in the kitchen
 sink is what's starting to bloat some Linux distros.
 

I totally agree! Ideally Gimp should have a connection to some plug-in
registry so that needed esoteric (or not so esoteric) plug-ins could
be downloaded and installed without restarting gimp. Have the simple
plugin's with the distro and then have a series of "power packs" that
roughly align with usage domains (i.e. "import powerpack","export powerpack",
fine art powerpack", "prepress powerpack", etc).

-Dean Johnson
 Tool Hooligan
 Cluster Admin Tools  Jessie Project
 Silicon Graphics Inc.Eagan,MN  (651) 683-5880

 
  "I am Dyslexic of Borg, Your Ass will be Laminated"-- unknown
 



Re: Plugins at Sourceforge

2000-02-05 Thread Kelly Lynn Martin

On Sat, 5 Feb 2000 12:33:38 -0800, "Michael J. Hammel" [EMAIL PROTECTED] 
said:

I'm curious why any new plug-ins should be added to the core *at
all*.  Gimp's distribution is fairly large as it is.  Isn't it
getting time to limit additional plug-ins to the core distribution to
plug-ins which are considered "vital" in some way?  Even some estoric
file plug-ins need not necessarily be included with the core package.
Throwing in the kitchen sink is what's starting to bloat some Linux
distros.

I couldn't concur with you more.  I'm radical enough to suggest taking
all the plugins out of the standard distribution entirely. :)

Kelly



Re: One more feature?

2000-02-05 Thread Tuomas Kuosmanen

On Sat, Feb 05, 2000 at 12:22:49PM -0800, Seth Burgess wrote:
 I'd really like to see the setting for default brush reappear.  So
 much so that I'd do it myself.  
 
 Hows this fit with the freeze?  I hate to violate the freeze, esp
 since its been getting better.  But I'm SO SICK OF THAT CALIGRAPHIC 
 BRUSH (10x10)!  Comments?
 
 Seth
 [EMAIL PROTECTED]
 
 -- 
 ~/.sig: [E]xit, [H]alt, show [S]tack trace or [P]roceed:

Make a new brush and call it 0001_Seth, it should always be the first one..
Though the tools do remember the last brush, I think (see that you have
"restore session" selected in preferences)

Tuomas

-- 

.---( t i g e r t @ g i m p . o r g )---.
| some stuff at http://tigert.gimp.org/ |
`---'



Re: Removing pencil?

2000-02-05 Thread Marc Lehmann

On Sat, Feb 05, 2000 at 07:13:00PM +0200, Tuomas Kuosmanen [EMAIL PROTECTED] wrote:
 in my previous mail on this thread, I use the paintbrush as a "fine tuning"
 tool together with the "real" tool I am drawing with. And if it is the
 paintbrush, then there is no way to toggle fast between those.. clicking a
 checkbox every time instead of pressing a shortcut key sounds clumsy.

I guess the correct fix (in 1.3!!) would be to be able to attach shortcuts
to checkboxes.

For 1.2 there IMHO shouldn't be a merge.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |