Re: [Gimp-developer] on moving toward a 2.4 release

2006-08-12 Thread Alan Horkan

On Fri, 11 Aug 2006, Robert L Krawitz wrote:

GIMP 2.0 was released on March 23, 2004, and then GIMP 2.2 on
December 19, 2004.  This was a 9 month release cycle, which is
quite reasonable.  Howver, it has been over a year and a half since
the 2.2 release, and we are still not visibly nearing a 2.4
release.  This slow progress is holding up important things,
including, especially, GEGL integration.  What can be done?

 Compared with us (Gutenprint), that's still positively speedy.

Compared to Debian stable ...  life cycle of Giant turtles ... etc.

The longer the cycle continues without a release the more often users get
told thing are fixed in CVS or the unstable branch but if they are not
sure what they are doing then they should not use the unstable branch for
important work.

 If GEGL integration really is a hard problem, it's going to come out a
 lot better if you take the time to do it right rather than rushing it.

If I remember the dicussions correctly 2.4 was planned, to be followed by
the integration of the Google summer of code results and then GEGL after
that.  Where you suggest more 2.2 releases more 2.4 was what was
previously suggested.

-- 
Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Script-Fu procedure blurb review

2006-08-02 Thread Alan Horkan

On Wed, 2 Aug 2006 [EMAIL PROTECTED] wrote:

 Even if I didn't completely screw it up, I imagine there will be some
 discussion. I have many doubts about my wording myself. Some issues as
 I see them:

 2. In a couple of places I employed the term selection frame in
 order to differentiate operations that affected the selection mask
 versus those that affected the selection's contents

The selection contents is the image or the drawable.
No new terminology needed.

-- 
Alan H

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] menu cluttage

2006-07-08 Thread Alan Horkan

On Wed, 5 Jul 2006, Joao S. O. Bueno Calligaris wrote:

 Date: Wed, 5 Jul 2006 21:36:51 -0300
 From: Joao S. O. Bueno Calligaris [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] menu cluttage

 On Wednesday 05 July 2006 04:47 pm, Sven Neumann wrote:
  Hi,
 
  On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote:
   Now that GIMP handles registration of the same menu item from
   different plug-ins, I am just waiting for the time a user reports
   a bug in Whirl and Pinch (for example) and doesn't realize which
   version they were using (as in the Python version or the C
   version).
 
  The Python version will of course not be in any stable release.
 
  And so far I don't see anyone complaining about my proposal to not
  install any Python scripts at all with GIMP 2.4.
 Hey.
 It is allright for me if you do not install then- but I had
 complained. - At least count that.

 Actually we could think of then case by case. Almost all of then are
 just clones of other plugin/scripts, buyt, py-slice, for example, has
 only an equivalent in gimp-perl, and currently py-slice is far more
 capable.

There is an equivalent web slice written in Script-fu.  I have my own
modofied copy lying around somewhere but if I recall correctly you can
find the original in the gimp plugin registry.

It will be good to have the Python support turned on by default on windows
so that developers (script writers) can count on it being there but not
including the redundant scripts isn't any great loss.

--
Alan H.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] menu cluttage

2006-07-08 Thread Alan Horkan

On Wed, 5 Jul 2006, Jakub Steiner wrote:

 Date: Wed, 05 Jul 2006 12:57:49 +0200
 From: Jakub Steiner [EMAIL PROTECTED]
 To: Fennec [EMAIL PROTECTED]
 Cc: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] menu cluttage

 On Tue, 2006-07-04 at 11:13 -0400, Fennec wrote:
  [EMAIL PROTECTED] wrote:
   Currently the GIMP on Windows has 1 icon that is used for all file formats
   associated with it. It would be possible to have separate icons for every
   format handled by the GIMP, but somebody would have to create them.
  I don't suppose the Tango project has anything we could swipe, does it?
  We should ask them to do it. :)

 Hi.
 Actually I've been trying to avoid the mimetype hell and only drawn
 generic types for now. Making a distinct icons for XCFs may sound like a
 usable thing to do. But I don't think having a distinct icon for each
 and every image type out there will bring us any good.

It is certainly useful to have icons for the major types.
One icon to rule them all is not enough.

There was some concern when the icons were changed so that PNG and JPEG
had the same icons since it is particulaly useful to distinguish the
losless and lossey formats.  (I'm not sure if that was Tango/Ubuntu/Gnome
exactly and this may well have been fixed already since I last noticed
it.)

I understand you dont want to create icons for every type of graphics file
format but it might also be useful to have an icon for XCF, PSD, MNG and
perhaps other layered image file formats.

The icons in Windows were rubbish but Windows/Internet explorer did at
least provide 'picture frame' style icons for GIF, JPEG, and PNG with each
having a different central colour (green, red and pink respectively).
One option might be for the windows installer to leave the default icons
alone for these types (use the default icons provided by windows) and only
set the gimp document Icon for XCF and a few other gimp specific formats?
I've manually changed the icons like this in the past but other programs
have long since stolen the file associations back again and now only a few
of my files have the gimp icon on them.  If this sounds like what windows
users want they should talk sweetly to the developer who puts together the
windows installer.

-- 
Alan
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] menu cluttage

2006-07-05 Thread Alan Horkan

On Tue, 4 Jul 2006, Fennec wrote:

 Date: Tue, 04 Jul 2006 11:13:47 -0400
 From: Fennec [EMAIL PROTECTED]
 Cc: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] menu cluttage

 [EMAIL PROTECTED] wrote:
  Currently the GIMP on Windows has 1 icon that is used for all file formats
  associated with it. It would be possible to have separate icons for every
  format handled by the GIMP, but somebody would have to create them.

 I don't suppose the Tango project has anything we could swipe, does it?
 We should ask them to do it. :)

The gnome (and tango) icons sizes aren't particularly useful on Windows.

You might be better off to try checking the gimp Windows mailing list, I
vaguely recall previous attempts to create a suitable set of document
icons but I dont know if anything came of it.

-- 
Alan
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Script-Fu procedure blurb review

2006-07-01 Thread Alan Horkan

On Thu, 29 Jun 2006, Sven Neumann wrote:

 Date: Thu, 29 Jun 2006 19:16:33 +0200
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: gimp-devel gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Script-Fu procedure blurb review

 Hi,

 On Wed, 2006-06-28 at 10:16 +0100, Alan Horkan wrote:

  Plugins have both a short summary description (blurb)  be and a longer
  more descriptive help.  It might be worth making things consistent and
  doing the same for scripts.

 As I already explained,

Only read your message after I had sent mine.

 we can't easily do that without breaking backwards compatibility.

The switch over to Tiny-Fu will result in a certain amount of
incompatibilities anyway so it might be a good time to reconsider.

 it makes a lot of sense to clean up the short strings now. Other changes
 can be considered after 2.4.

CVS will still have the long descriptions if anyone wants to go back and
add then in again.

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Script-Fu procedure blurb review

2006-06-28 Thread Alan Horkan

On Wed, 28 Jun 2006, Kevin Cozens wrote:

  That's nice, but the task is to come up with a short string that must
  fit into a single line and is oriented towards the user, not towards a
  script programmer. The string will be visible in the status bar when
  browsing the menus. Something like the following would be appropriate
  for your example:
 
Generate a repeating pattern of Truchet tiles

 Is there a particular need for these blurbs to be short one liners other than
 making things easier for the translaters? I don't think they should be

Plugins have both a short summary description (blurb)  be and a longer
more descriptive help.  It might be worth making things consistent and
doing the same for scripts.

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Script-Fu procedure blurb review

2006-06-27 Thread Alan Horkan

On Sat, 24 Jun 2006 [EMAIL PROTECTED] wrote:

 Date: Sat, 24 Jun 2006 15:34:52 -0700
 From: [EMAIL PROTECTED]
 To: gimp-developer@lists.XCF.Berkeley.EDU
 Subject: Re: [Gimp-developer] Script-Fu procedure blurb review


 initially set the generated image to clean. It seems unnecessary to
 prompt for save when closing an unmodified logo; the logo can easily
 be regenerated with the same values by re-running the script.

I've considered this before, it would probably be a good idea.  The only
reason I could come up with as to why you might want to mark the image as
dirty/modified was in cases where there was a stack full of undo steps the
user might want to play with.  I generally prefer to allow easier
modification of things laterby providing seperate layers.

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: Old and new [Re: [Gimp-developer] new default icon theme proposal]

2006-06-18 Thread Alan Horkan

On Sun, 18 Jun 2006, Sven Neumann wrote:

 Date: Sun, 18 Jun 2006 20:01:00 +0200
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED], Not Photoshop gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: Old and new [Re: [Gimp-developer] new default icon theme
 proposal]

 Hi,

 On Sat, 2006-06-17 at 09:54 +0100, Alan Horkan wrote:

  Will the old icons be offered as a seperate theme set?

 If someone wants to create such a theme, we might consider to include
 it.

I was thinking that if Jimmac created his new theme independently -
something he might have already done - it would remove any need to delay
its introduction.  The theme could be added now it could be made the
default later when it was completely ready.

If you are happy to make it the default in the next release then it
wouldn't be worth doing any extra work.

 I would suggest however that is it being shipped as a separate package.
 Perhaps we could have a package gimp-themes and one of the themes it
 provides would be Classic

Could it be included in gimp-data extras, might save you having to create
another package?

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Old and new [Re: [Gimp-developer] new default icon theme proposal]

2006-06-17 Thread Alan Horkan

On Thu, 15 Jun 2006, Jakub Steiner wrote:

 Date: Thu, 15 Jun 2006 14:16:26 +0200
 From: Jakub Steiner [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: [Gimp-developer] new default icon theme proposal

 Hi GIMP developers,
 I write to propose a new default icon set for GIMP 2.4. As GIMP is a
 multiplatform application it will in my view benefit greatly from an
 icon set that follows the Tango style guidelines [1].

Will the old icons be offered as a seperate theme set?

If the answer is yes then I look forward to seeing both themes included
soon.  Even if your new Tango theme is not ready/complete enough to be
immediately set as the default it would be great to have the option to
start live testing it alongside the existing icons.

-- 
Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: Old and new [Re: [Gimp-developer] new default icon theme proposal]

2006-06-17 Thread Alan Horkan

On Sat, 17 Jun 2006, Dalai Felinto wrote:

 Date: Sat, 17 Jun 2006 11:00:13 -0300
 From: Dalai Felinto [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED], Not Photoshop gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: Old and new [Re: [Gimp-developer] new default icon theme
 proposal]

 This theme:
 http://art.gnome.org/themes/icon/1261

 Is based in Tango too, what is the differences??

That is a Gnome theme.

Jimmac is working on a theme to replace the icons in the GNU Image
Manipulation Program which is more specific and has its own internal icon
themes.

-- 
Alan
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp-python: Artefacts when creating layer

2006-06-03 Thread Alan Horkan

On Sat, 3 Jun 2006, Simon Budig wrote:

 Date: Sat, 3 Jun 2006 14:29:02 +0200
 From: Simon Budig [EMAIL PROTECTED]
 To: gimp-developer@lists.XCF.Berkeley.EDU
 Subject: Re: [Gimp-developer] Gimp-python: Artefacts when creating layer

 Sebastian Breuers ([EMAIL PROTECTED]) wrote:
  The plug-in, I'm writing, creates a number of layers, every layer receives 
  an
  object, for example a circle (created by ellipse selection, an selection
  fill), but somewhen, don't know why, the layer contains not only the desired
  circle but also some artefacts. Stripes, areas of white, the mouse cursor,
  things they should not be there.
  Is that a problem that can be solved by a certain programmable handling or 
  do
  I have to remove these artefacts by hand?

 That sounds as if you don't clear the layer before you use it for the
 first time. Layers created from a Plugin are not initialized from the
 very beginning. They need to be cleared using e.g. gimp_drawable_fill.

I remember getting caught out by this too.  Why is necessary to manually
clear a new layer rather than have it done automatically?

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] New microsoft image format

2006-05-27 Thread Alan Horkan

On Fri, 26 May 2006, Nathan Summers wrote:

 Date: Fri, 26 May 2006 18:52:44 -0400
 From: Nathan Summers [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: Not Photoshop gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] New microsoft image format

 On 5/26/06, Alan Horkan [EMAIL PROTECTED] wrote:

  If you hit the Do not agree option it will still let you read the
  specifications without agreeing.  I expect they'll change that soon
  though.

 Is there anything interesting in there?

In my opinion no, not really but you might find it more interesting.  The
ideas all seem to be more or less covered by other existing standards like
JPEG 2000 primarily and various others.

(Frankly I'm more interested in XPS/Metro which attempts to replace PDF,
and XAML/WVG/Avalon/whatever-they're-calling-it-this-week attempt to
replace SVG.)

--
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] New microsoft image format

2006-05-27 Thread Alan Horkan

On Sat, 27 May 2006, Michael Natterer wrote:

 Date: Sat, 27 May 2006 10:51:22 +0200
 From: Michael Natterer [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: gimp-developer@lists.XCF.Berkeley.EDU
 Subject: Re: [Gimp-developer] New microsoft image format

 On Sat, 2006-05-27 at 08:08 +0100, Alan Horkan wrote:
  On Fri, 26 May 2006, Nathan Summers wrote:
 
   Date: Fri, 26 May 2006 18:52:44 -0400
   From: Nathan Summers [EMAIL PROTECTED]
   To: Alan Horkan [EMAIL PROTECTED]
   Cc: Not Photoshop gimp-developer@lists.xcf.berkeley.edu
   Subject: Re: [Gimp-developer] New microsoft image format
  
   On 5/26/06, Alan Horkan [EMAIL PROTECTED] wrote:
  
If you hit the Do not agree option it will still let you read the
specifications without agreeing.  I expect they'll change that soon
though.
  
   Is there anything interesting in there?
 
  In my opinion no, not really but you might find it more interesting.  The
  ideas all seem to be more or less covered by other existing standards like
  JPEG 2000 primarily and various others.

The summer of code work on Jpeg 2000 support should provide a good counter
point and give one less reason for the new Microsoft image format to
gain an audience.

More contributors are preferable to non contributing users but if it keeps
them away from proprietary formats which hurt us in the long run the
network effect of many users turn a small difference into a big defense.

  (Frankly I'm more interested in XPS/Metro which attempts to replace PDF,
  and XAML/WVG/Avalon/whatever-they're-calling-it-this-week attempt to
  replace SVG.)

 Really? I'm not interested at all. Zero percent.

 To me that looks like the usual M$ attempts to replace
 just about anything that other people have done.

That is the part that interested me, I'll be interested to see it fail
hopefully.  I'm not saying the format is necessarily any good but it is
interesting to see Microsoft try to reinvent the wheel.  I hope the
drawing part of XAML to end up deader than VML.  Since acrobat reader is
so horribly slow by default I think XPS might stand a decent chance of
carving out at least a small niche but perhaps a windows port of Evince
(or KPDF or or ...) would give diserning users a faster alternative to
Adobe and reduce there interest in what Microsoft might offer.

 It's already ambivalent to have GIMP running on windows
 at all,

I wholeheartedly support more Free Software for those still stuck on a
proprietary Operating System.  It is what put me on the path to using more
Free Software and a free operating system.  There are times when I
dont have the choice of operating system but I do still have the option of
installing additional software.

 I'm not interested in taking this any further by supporting these
 formats, and thereby supporting M$.

I wonder if creating importers for these formats would reinforce them or
help get users away from them?  Of course it all depends on if a
developer decides it is interesting enough to implement.

Free and open standards are very important.  It is shame we dont yet have
a suitable standard for sharing layered raster images.

--
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] New microsoft image format

2006-05-26 Thread Alan Horkan

On Thu, 25 May 2006, Nathan Summers wrote:


  I di dnot download it, bu I read the agreement for ownlaoding it. One
  keep his soul and his mother in doing so. I mean- there is no nasty

  They announce  a lot of miracles for this format, and it would be nice
  to be able to read and write to it if half of then hold true.

 They lost me with the first sentence of the first clause:

If you hit the Do not agree option it will still let you read the
specifications without agreeing.  I expect they'll change that soon
though.

-- 
Alan
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] SoC Q: SDI vs MDI?

2006-05-23 Thread Alan Horkan

On Tue, 23 May 2006, Michael Schumacher wrote:

 Date: Tue, 23 May 2006 00:51:56 +0200
 From: Michael Schumacher [EMAIL PROTECTED]
 To: GIMP Developer gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] SoC Q:  SDI vs MDI?

 Michael J. Hammel wrote:

  Is the SoC page correct where it asks for an SDI manager widget?
  Wouldn't that be an MDI manager widget?

 AFAIK this is mixed. The project wasn't taken, btw.

  MDI:  http://en.wikipedia.org/wiki/Multiple_document_interface
  SDI:  http://en.wikipedia.org/wiki/Single_document_interface

  Or does the Wikipedia have it backwards?

 I don't think so.

GIMP has what I would describe as CSDI, Controlled Single Document
interface.  The toolbox acts as a control window but each document has a
signle window of its own.  (Photoshop on the Mac would also be CSDI but
the menubar acts at the control window.  I've seen other programs
which have a seperate menubar as the control window, including
a version of Mathematica and various IDE.

Inkscape has what I would call straight SDI.

I dont think Wikipedia is entirely clear without necessarily being
inaccurate, it just needs more information.

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Suggestion: Make the 'New layer'commanddefaultto 'New lay

2006-05-17 Thread Alan Horkan

On Wed, 17 May 2006, Alexandre Prokoudine wrote:

 Date: Wed, 17 May 2006 16:52:08 +0400
 From: Alexandre Prokoudine [EMAIL PROTECTED]
 To: GIMPDev gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Suggestion: Make the 'New
 layer'commanddefaultto 'New lay

 On 5/17/06, Martin Nordholts wrote:
  I think like this:
  For maximum workflow, one should be able to do as many things simultaneously
  as possible, wouldn't you agree with that?

 What else can I do while creating a new layer except scratching my
 poor head and holding a paper? :)

 Again, I would like consistent user interface. If GIMP uses
 Shift+Click for using last settings and bypass an extra dialog in
 several places, I want it to always work that way, throughout UI.

It works for Layers, Channels, and Paths.  Good consistency.

Doesn't seem to work for the Templates dialog.
Doesn't work for brushes or gradients but in that case it is more like
Edit gradient than New gradient so it probably isn't applicable.

Cannot think of other places to test.

 If you point is in bypassing all extra dialogs by default, then it
 is a subject to a usability study. I can't see how possibly we can

I couldn't agree more with the point Simon made about discoverability and
the workflow optimisation should take second place in this situation,
especially since this was all based on trial and error and the developers
came to this decision the hard way.

 decide changing what many people already got used to without studying
 user experience of at least part of them.

It is a tough burden to require usability testing to prove every suggested
change but in this there effectively has been a substantial body of
testing already.

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp connotations ?

2006-05-16 Thread Alan Horkan

On Mon, 15 May 2006, Fennec wrote:

 Date: Mon, 15 May 2006 15:11:17 -0400
 From: Fennec [EMAIL PROTECTED]
 To: GIMP Developer gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Gimp connotations ?

 Well... I don't think I've even seen an IBM product with a name as bad
 as The GIMP. I think a name change would be a good idea- it might be a

As you can see from this discussion non-English speakers aren't bothered
by the name.  More often a project picks a name without realising it means
something rude in another language.

Distributions have already tackled the problem of confusing project names
by showing a generic description such as Image Editor instead.

 little damaging in the short term, yes - just imagine all the fun that
 the various Linux distros would have, for instance - but would probably
 lead to a brighter future.

Using the full title GNU Image Manipulation Program is cumbersome but an
adequate workaround in the meantime.

 You'd need a real initiative from the real Top Brass people to change
 the name, though, or it would never happen - until then, arguments about
 it are just so much hot air.

I wasn't arguing.  I was stating the fact that the name causes problems
since in English gimp is more often known as to mean person with a limp or
interested in bondage than it is a type of knot (a meaning I only learned
after looking it up in a dictionary after a similar discussion on this
list_.

Sven has already made it very clear he doesn't want to change the name and
would not even accept patches which made it easier to change the name.
(Firstly I'd like to remove the over use of the word within the
application lables but if I were allowed I would try to make it a
configuration option.)

Certification (as this thread was originally about) would be best handled
by a third party who already do other certification.

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp certification

2006-05-14 Thread Alan Horkan

On Sun, 14 May 2006, David [utf-8] Gómez wrote:

 Date: Sun, 14 May 2006 12:51:52 +0200
 From: David [utf-8] Gómez [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: GIMPDev gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Gimp certification

 Hi Alan,

 On May 14 at 12:25:59, Alan Horkan wrote:
  In all seriousness I would not risk putting the word gimp anywhere on my
  CV and I have had funny reactions (funny weird, never funny ha ha) when
  explaining the GIMP to users not already familiar with it.

 Remember that not in all languages the gimp word has funny connotations,

Which doesn't change the point I was making one bit.  The original authors
were English speakers and in the unlikely event they were university
students and somehow unfamiliar with the film Pulp Fiction (1994) it is
even more unlikely they didn't know of the dictionary definations of the
word.  Point it is the name does cause embarassment to some who have to
explain it to other English speakers more familiar with the other meanings
of the word and the attempt at humour in the name just makes it that
little bit harder to get the GIMP taken seriously.

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp certification

2006-05-13 Thread Alan Horkan

On Sat, 13 May 2006, Joao S. O. Bueno Calligaris wrote:

[...]

 Besides that, certifications are sometimes sought for those without
 the abilities or application to stand by themselves, either in their
 C.V. or personally.

Listing GIMP [1] as one of your qualifications on a resume is more
likely than usual to result in misunderstandings over the project name.
I wouldn't risk it, you never know what the evil people in Human Resources
might do to you.

-- 
Alan


[1] As it is widely known to mean something else thanks to the Quentin
Tarantion film Pulp Fiction.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp certification

2006-05-13 Thread Alan Horkan

On Sat, 13 May 2006, Carol Spears wrote:

 Date: Sat, 13 May 2006 15:55:39 -0700
 From: Carol Spears [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED],
  GIMPDev gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Gimp certification

 On Sat, May 13, 2006 at 08:21:50PM +0100, Alan Horkan wrote:
 
  On Sat, 13 May 2006, Joao S. O. Bueno Calligaris wrote:
 
  [...]
 
   Besides that, certifications are sometimes sought for those without
   the abilities or application to stand by themselves, either in their
   C.V. or personally.
 
  Listing GIMP [1] as one of your qualifications on a resume is more
  likely than usual to result in misunderstandings over the project name.
  I wouldn't risk it, you never know what the evil people in Human Resources
  might do to you.

 this is an interesting idea/observation.  i wonder if you can clarify by
 either presenting a real life example of this or by stating clearly that
 this is what you imagine might happen.

In all seriousness I would not risk putting the word gimp anywhere on my
CV and I have had funny reactions (funny weird, never funny ha ha) when
explaining the GIMP to users not already familiar with it.  If you really
wanted to make a point and include it then GNU Image Manipulation
Program would get the job done.  Besides if one was applying for a
graphics job it would be your portfolio which was important not your
familiarity with particular software, although I'm sure it would be a
bonus to know a variety of creative tools.  (I do list that I am familiar
with scripting in scheme.)

 a statement like this, if it really could happen, would clearly show how
 completely unprofessional the professional world would be and would be
 a very good reason for good people to take things over.

Interviewers are notoriously shallow, how few people risk going to a job
interview not wearing a suit?  (Rhetorical question.)

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] RFC: three questions for the LXF article

2006-05-11 Thread Alan Horkan

On Wed, 10 May 2006, Michael J. Hammel wrote:

 Date: Wed, 10 May 2006 13:52:24 -0600
 From: Michael J. Hammel [EMAIL PROTECTED]
 To: GIMP Developer Mailing List gimp-developer@lists.xcf.berkeley.edu
 Subject: [Gimp-developer] RFC:  three questions for the LXF article

 If anyone wants to comment on these, please feel free.

 1. Developer Wishlist

 A lng time ago there was a wish list of features for GIMP.  Is there
 any such thing now, specifically as seen from the developers point of
 view?

Anything and everything marked as enhancement in Bugzilla?

 2. The 5 most annoying GIMP bugs

 Totally subjective, but please feel free to comment on these.  I know
 the two I've heard the most are that GIMP uses SDI instead of MDI and
 that the menus don't read like Photoshops (two that I, personally, think
 are irrelevent, but who am I to say what's relevent?).

I'd qualify that complaint a little further.  The GIMP uses CSDI, a
controlled Single Document Interface, where the Toolbox is the control
window[1] unlike the SDI used in Inkscape and various Gnome applications.
This makes the GIMP quite unusual and unfamiliarity is enough to put off
many users (but then there are other issues besides that).
The biggest supporters of this scheme are users with dual head setups or a
complex window manager (ie not Metacity or Windows).  I would not mention
the instead of MDI (Window in Window like Photoshp for Microsoft
platforms)  because that presumes too much about the best alternative.

The menus not reading like photoshop increases the learning curve allowign
users to leverage existing knowledge and makes it more difficult to reuse
all those photoshop tutorials out there.  The point I regularly make is
that I'd be a lot happier if things were _the same or better than
photoshop_ i.e. unless there was a specific reason to do things
differently they would be the same.  However the default position remains
to only copy photoshop when there is a distinct benefit to doing so.  I
don't think this is a particularly significant problem in the grand scheme
of things but it is a realtively easy complaint for users to identify and
put the blame here for other difficulties they might be having trying to
learn the software.

-- 
Alan H.

[1] The old version of Mathematica I had on windows used the menubar as a
control window.  I think Delphi did too.  Macintosh applications use the
menubar as the control window which is slightly different.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Search of Filters [Re: [Gimp-developer] GIMP and Google SoC]

2006-04-21 Thread Alan Horkan

On Fri, 21 Apr 2006, Jakub Steiner wrote:

 Date: Fri, 21 Apr 2006 14:24:34 +0200
 From: Jakub Steiner [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] GIMP and Google SoC

 Few tips for SOC:

   * Something I am guilty of never getting to was speccing out a
 search based interface to filters (plugins). I believe a search
 based interface will be more efficient than navigating through a
 nested structure of a menu.

I was using the PDB browser for this purpose.  I tried to add a button
which would bring up the currently selected filter but I didn't get very
far with it, although I do think it should be possible to hack together
soemthing.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: GIMP and Google SoC

2006-04-19 Thread Alan Horkan

On Wed, 19 Apr 2006, Sven Neumann wrote:

 Date: Wed, 19 Apr 2006 21:02:47 +0200
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: Not Photoshop gimp-developer@lists.XCF.Berkeley.EDU
 Subject: Re: [Gimp-developer] Re: GIMP and Google SoC

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  I'd love to see a single unified interface shared by the various
  Python-fu, Script-fu, Perl-fu etc and it might make a suitable project
  since it is a limited self contained task.

 Can you elaborate on this? Single unified interface sounds great but I
 have no idea what you mean here.

Script-fu does not look like Python-fu or Perl-fu.  Users should not be
able to tell from the user interface that a different programming langauge
was used.  They all have automatically generated user intefaces* but the
results look different, and some widgets such as a Radio list are
supported in Python-fu but not in script-fu.

Not sure I can make it any clearer but hopefully someone else can help
explain it.

-- 
Alan H.

* Okay some of the Perl scripts have manually written graphical users
interfaces but that is a side issue.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Background window [was Re: [Gimp-developer] GIMP and Google SoC]

2006-04-18 Thread Alan Horkan

On Tue, 18 Apr 2006, William Skaggs wrote:

 Date: Tue, 18 Apr 2006 09:41:40 -0700
 From: William Skaggs [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] GIMP and Google SoC

 5) Create a manager widget that will allow all of GIMP's windows to be
 contained in a single parent window, as requested hundreds of times by
 Windows users.  (This would be optional, not forced on people who don't
 want it.)

Is there a good reason why something this would need to be done as a whole
new project?

Gimpshop uses:
Gimp Background window version 2.1, Copyright (C) 2004

As far as I can tell is what is less flatteringly but better know as the
GIMP Deweirdifyer since the source archive for it is labelled
BackgroundWindow.

Is there some techincal reason making it impractical to integrate this
instead?

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Open Clip Art http://OpenClipArt.org
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Can we redearch end user needs and come up with a long term developement solution.

2006-04-18 Thread Alan Horkan

I understand English may not be your first language but your writing is
somewhat difficult to read and understand, a spellcheck would really help
and allow you to make your points without distraction.

On Tue, 18 Apr 2006, Tomasz Witko wrote:

 Date: Tue, 18 Apr 2006 14:10:17 -0400
 From: Tomasz Witko [EMAIL PROTECTED]
 To: Gimp Development [EMAIL PROTECTED]
 Subject: [Gimp-developer] Can we redearch end user needs and come up with
 a long term developement solution.

 Hi I am new to the development list and have some quetions pertaining to the
 direction of developement of Gimp, I realy like Gimp and use it frequesntly
 and have some vaige suggestions for what the developent path of Gimp may

 follow to give it an advantage and hopefully bring in new Gimp users and

Some developers have expressed the opinion that bringing in new users is
not a priority.  The underlying assumption is that more users will result
in more developers but that doesn't seem to


 better the usablity of Linux in general.

  First off Most people compare Gimp to photoshop wich is a good direction to
 follow as they set the standard by addressing user needs though I feel Gimp
 should not be a Photoshop knock off and sort of develop in its own direction
 pertaining to the end users needs which I feel it does and seperated the
 knock off idea as GImp is following the needs of the user.

  Anyways there are a few directions where GImp may gain an advantage over
 other editing software by combinning user needs and there for features that
 would give it an advantage over other Graphical programs but this has to  be
 waighed against program bloat. Bloat may be eliviated by seperating Gimp
 into sections such as Photo editing and say for argument a Gimp paint shop
 and be able to make the open graphics window inteact with the different
 sections.

  Basicly what I am getting at is it may be possible to combine many user
 needs into one segmented package filling the needs of many users with such
 features found in other praphics programms such as Photo Shop, Paint shop

 pro and a biggie that I used to use which was the old COral Draw which I
 found very usefull in making custom banner adds etc from scratch.

Corel Draw is a vector graphics program, quite different from the GNU
Image Manipulation program, perhaps you meant a different program from
Corel?

If vector graphics is what you really want you might be better off looking
at Inkscape:
http://inkscape.org

 very useable now but I feel it may do so much more as Linux developement

[usable]

 programs are a bit scarce though rumor has it that this is changing.

More programs does not necessarily mean better programs.  The ability to
get involved in development means people are can work to try and improve
the best programs available instead of starting from scratch unless they
really want to.  combine that with the option of running windows programs
using Wine http://winehq.com I'm not sure I agree with your assertion
about programs being scarce.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Customzing GIMP

2006-04-18 Thread Alan Horkan

On Mon, 17 Apr 2006, Nathan Summers wrote:

 On 4/17/06, digi artist [EMAIL PROTECTED] wrote:

  All I really want to do is to hide some menu items (especially when the
  picture has been opened) and rename some items on the 'Filters' menu.
  period.
  I would really appreciate your help.

 Actually, we would be interested in hearing your input on how the menu
 items can be improved in general.  One of the goals for the next
 version of GIMP is to have better menus.

The definately not recommend but quick and dirty way to change menu lables
is to edit the en.po file.  There is an XML file you can edit to change
the menu layout, you will need to ask nicely or rummage through the
archives to get more details (I dont memorize these kinds of details).

-- 
Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Customzing GIMP

2006-04-17 Thread Alan Horkan

On Mon, 17 Apr 2006, digi artist wrote:

 Date: Mon, 17 Apr 2006 07:42:59 -0700 (PDT)
 From: digi artist [EMAIL PROTECTED]
 To: Gimp-developer@lists.XCF.Berkeley.EDU
 Subject: [Gimp-developer] Customzing GIMP

   Hi,

 I have just found GIMP and would need some help with customizing it.
 What I would like to do is to change the names of some menu items
 and the Title bar.

The title bar can be customised from the preferences dialog.  You may need
to lookup the documentation to find out what the cryptic keywords actually
stand for though.

Changing the names of menu items isn't such a good idea and may cause
problems explaining what is happening if you need help later.  There are
ways to do this but they are either ugly or not easy and I would prefer
not to suggest them unless you are absolutely sure you need to do it.

What changes do you have in mind?

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Plea for a new interface...

2006-04-02 Thread Alan Horkan

On Sun, 2 Apr 2006, Roland Wild wrote:

 Date: Sun, 2 Apr 2006 04:00:35 -0400
 From: Roland Wild [EMAIL PROTECTED]
 To: gimp-developer@lists.XCF.Berkeley.EDU
 Subject: [Gimp-developer] Plea for a new interface...

 Carol,

 I can't understand your response. (maybe a little because of the english
 language)
 Carol, i think you minimize the importance of users opinions in the
 development of a software... or maybe it's me who maximize it.

I think it might be good to say that Carol has liked and used the GIMP for
a long time and is concerned that changes others want might not turn out
to be improvements, and is a good representative of long term users.

 If you truely think that my intervention was useless I apologize because I
 made you waste your time.

Many people make many suggestions but very few help out.  People who quite
like things the way they are tend to get a little annoyed and not
understand why people complain so much and do so little about it.  It is
very difficult for developers and existing users to be as nice to the
first person as the hundreth person to ask the same thing.

Me, I'm not content with thing the way they are but things are improving
(compare version 1.2 to now).  There are very few good alternatives if you
want to use GNU Free Software and complaining doesn't really help anyone.
I would prefer if people were more willing to copy Photoshop unless there
were specific reasons not to copy certain details, instead of the default
position being to judge suggestions in isolation but I'll keep trying to
nudge things along.  (For example: I think showing the text labels on the
palettes would make things easier to learn, and the bigger targets easier
to hit.  I usually have icons and text showing, or sometimes status and
text a neat feature you might not have discovered yet.  Might file a
request later.)

 and another where people could come and say how they are happy with the

Happy people tend to get on with creating artwork.  Sometimes the feedback
developers get might not be representative but hopefully things can be
improved without upsetting existing users.

 suggestions I made was interpreted as a critic (what I can understand
 because unlike in french the words review and critic are synonymous in
 english) I excuse me another time.

They are almost the same in Engish, we borrow the word 'critique'.  The
problem is probably more to do with it being difficult to express things
in writing, I often find people on the internet to be rude and excessively
blunt when apparently they aren't doing it on purpose (again and again and
again).

 I will continue to use and promote this program because I like it and it do
 me good turns. Actually as I said in a precedent mail others have answered
 to my questions (Robert, Alexandre, etc). I don't insist in this way (the
 review i proposed) anymore. I will try to made a little video to show if
 the suggestions they gave me can be efficient. Another time I thank them.

Stick around, perhaps you can still suggest changes that enough people
will like and maybe you could help out some way towards helping get those
changes made.

-- 
Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] A few suggestions forThe Gimp

2006-04-01 Thread Alan Horkan
 they are more nice suggestions which might not go anywhere.

Sincerely

Alan Horkan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] What is this list?

2006-04-01 Thread Alan Horkan

On Sat, 1 Apr 2006, George Rice wrote:

 Date: Sat, 1 Apr 2006 10:17:44 -0500
 From: George Rice [EMAIL PROTECTED]
 To: gimp-developer@lists.XCF.Berkeley.EDU
 Subject: [Gimp-developer] What is this list?

 Could you please tell me what this mailing list is?

How (and why) did you subscribe to the list without knowing what it was?
Have you read any of the website?  http://www.gimp.org/

This list is for discussion of the GNU Image Manipulation Program.

 Do I post my buisness on this mailing list?

This question is not clear.  Could you please try rephrasing it.

You may ask questions but you might not always get answers.

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] make a test

2006-03-31 Thread Alan Horkan

On Fri, 31 Mar 2006, Roland Wild wrote:

 Date: Fri, 31 Mar 2006 11:07:59 -0400
 From: Roland Wild [EMAIL PROTECTED]
 To: gimp-developer@lists.XCF.Berkeley.EDU
 Subject: [Gimp-developer] make a test

 Bonjour,

Bonjour.  Ca va?

Lisez les regles de la liste s'il vous plais:
http://gimp.org/mail_lists.html
Use the English language

It may not be in the rules but there is a rule on Internet Relay Chat
(IRC) and it applies equally well to the mailing lists:
Do not ask permission to ask a question, just ask.

Sincerely

Alan Horkan


P.S. I tried but had to resort to help to make sure my French was correct.

P.P.S. Now that I read the rules for the list I wonder if
Try to be grammatical is in fact a grammatically correct sentence.
Moen's law of corrections strikes again?
http://linuxmafia.com/~rick/lexicon.html#moenslaw-corrections
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Déj à vu? (Re : Why be cryptic? 'Xtns' should be name 'Extensions')

2006-03-27 Thread Alan Horkan

On Mon, 27 Mar 2006, Marc Lehmann wrote:

 Subject: Re: [Gimp-developer] [iso-8859-1] D?j[iso-8859-1] ? vu?
 (Re[iso-8859-1] : Why be cryptic? 'Xtns' should be name 'Extensions')

 On Sun, Mar 26, 2006 at 08:18:22PM +0100, Alan Horkan [EMAIL PROTECTED] 
 wrote:
   Personally, I am pretty much tired of all the UI/change name/cosmetic
   games,
 
  Could more be done to allow these cosmetic changes without forks being
  necessary?

 Of course. There have been plans to separate ui from graphics core since
 ancient times now, which would allow such changes in a relatively clean way.
 And lots has been done, too.

 But!

 Somebody has to do the work!

 There is no way around that.

 And this is what killed such efforts in the past.

  without needing a recompile and this was a great idea but Sven point
  blank rejected even the possibility of accepting patches which might
  rebranding easier.

 I must admit that I don't know of these incidents, but I do trust that Sven
 would not reject a patch unless its incorrect and a better way exists.

Sven explained his position on branding here and why patches to make
the name easier to change would not be accepted:
http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg08677.html

The GIMP name is mentioned in a lot of error messages, other places where
it is definately not necessary, but if I thought a patch would be
considered I would start on a patch for that.  (I've been reviewing the
en_GB.po already recently looking at other string changes.)

-- 
Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Déjà vu? (Re: Why be c ryptic? 'Xtns' should be name 'Extensions')

2006-03-26 Thread Alan Horkan

On Sun, 26 Mar 2006, GSR - FR wrote:

 Date: Sun, 26 Mar 2006 18:48:23 +0200
 From: GSR - FR [EMAIL PROTECTED]
 To: gimp-developer@lists.XCF.Berkeley.EDU
 Subject: [Gimp-developer] [iso-8859-1] D?j? vu? (Re: Why be c[iso-8859-1]
 ryptic? 'Xtns' should be name 'Extensions')

 Hi,
 [EMAIL PROTECTED] (2006-03-23 at 1032.39 +0200):
  Brendan writes:
Please, oh Lord, someone fork Gimp.
  I can imagine the scenario: (This is a parody, not a flame)
  Someones forks GIMP, sets up a project on (say) SourceForge. He spends
  lots of effort on the project's web page. (He is a c00l web designer.)
  It has a long list of features that this forked GIMP will have. The
  small print at the bottom says looking for developers.

 Someone did it... but failed to fulfill completly your prophecy this
 time, it seems they are already providing working code. ;]
 http://seashore.sourceforge.net/

The web pages do say last updated February 2006 and for Mac addicts who
absolutely must have the standard Mac style menubar it might still provide
something useful and it looks like they may have kept things largely
compatible.

 Personally, I am pretty much tired of all the UI/change name/cosmetic
 games,

Could more be done to allow these cosmetic changes without forks being
necessary?  I recall work was done to make it easier to make menu changes
without needing a recompile and this was a great idea but Sven point
blank rejected even the possibility of accepting patches which might
rebranding easier.

It was a shame people rushed to brand Gimpshop a fork, as opposed to an
interesting hack (which is how the author described it) and an opportunity
to get attract another developer to help out.  Perhaps it is not too late
to encourage him to remake the changes in a more maintainable way rather
than continuing to berate the author for his efforts.

This doesn't even include the patches and changes distributions make to
their version of the GIMP which I doubt they really want the extra hassle
of maintaining.

 as what I see is lack of some interesting (oh, maybe I should
 had said useful, otherwise the chat will spread even more into that
 is not needed yes it is blah blah) features... yeah, other apps
 have them, no, having those features does not mean copying the other

Looking at the GIMP, the GIMP Animation Package, gimp-perl, gimp-python,
gimp-data-extras, pspi and the wealth of third part plugins out there
people could already create lots of quite different installations of the
GIMP or different distributions, setup by default to serve lots of
slightly different audiences.  (Does the windows version of the gimp
include exactly the same plugins?  I think it used to include one or two
extras like the Resythesizer plugin.)

Would doing a Firefox on the GIMP be a good move?  If mainline
GIMP was slimmed down further would that be a good thing?  (Just in terms
of disk usage GImpressionist, Gfig and Gflare add quite a bit of extra
bulk.)  Maybe this would be more hassle than it is worth?

 I just remembered I had a small shot of the image in which one can
 guess the layer stack size (yes, that is 1.2, last sessions were in
 different machines, some had 2.x and one was still going with 1.2):
 http://www.infernal-iceberg.com/gimp/tmp/hs129-layers-and-miniview.png

Sorry, I'm not sure exactly what detail in this screenshot you are
pointing out.

Later

Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Why be cryptic? 'Xtns' should be name 'Extensions'

2006-03-23 Thread Alan Horkan


  We can improve the GIMP UI and it will improve. But if you really
  think that the only acceptable user interface is a perfect clone of
  Photoshop, then why don't you go ahead and start a project that aims
  to create such a clone?

Weren't people complaining about Gimpshop forking instead of trying to
help change the GIMP?

 I am primarily a KDE hacker. I already donate piles of time to that effort,
 including writing docs. I use Gimp almost every day, but I hear it
 continuously about the need to have it at least have a PS compatibility mode,
 from graphic designers who would love to use it.

Are they aware of the psmenurc which can be used to give photoshop like
keybindings?  I find it very useful but unfortunately there is no way to
set this in the user interface which is probably enough to guarantee most
users never discover it (I've added similar comments to a few bug reports
over the years).  There are a few other extension and plugins which can
help smooth the transition.

Instead of all those Versus articles it would be nice if a journalist
could for a change write about similarities and what functionality most
closely corresponds to what they are expecting which might help users to
adapt.  (Although like others I'd prefer if users didn't have to adapt
quite so much and if more changes were made to meet peoples expectations
unless there was a specific reasons not to accept changes.)

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: Image exchange format [was Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec]

2006-03-03 Thread Alan Horkan

On Thu, 2 Mar 2006, Alexandre Prokoudine wrote:

 Date: Thu, 2 Mar 2006 21:36:42 +
 From: Alexandre Prokoudine [EMAIL PROTECTED]
 To: GIMPDev gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: Image exchange format [was Re: [Gimp-developer] Photoshop
 PSD 6 format Spec / Gimp XCF format Spec]

 On 3/2/06, Alan Horkan wrote:

  Rather than mentioning a future possible ideal format I'd like to mention
  MNG, which although far from perfect for all graphics tasks (print
  graphics).  This is less than ideal but still a small improvement over PNG
  because at least you get to keep your layers intact (and gimp does already
  have some support for MNG).

 IIRC, MNG is animated PNG + some minor features.Can't see much
 relation in this case

It isn't just about the animation, you can also think of it as a layered
PNG even though it does more than that.

- Alan

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] support for the PSD

2006-03-03 Thread Alan Horkan

On Fri, 3 Mar 2006, Florent Monnier wrote:

 Date: Fri, 3 Mar 2006 17:27:30 +0100
 From: Florent Monnier [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: [Gimp-developer] support for the PSD

  It is somewhat futile to point out that support for the PSD format
  needs to be improved. We know that. We know that for several years
  now. We simply need someone who invests the time to improve it. No
  need to convince anyone that it is a good idea.

 rather than doing this job in the gimp, what would you think about
 extract the current related code to initialize the project of a lib for
 reading psd?

 just an idea...
 ... perhaps more people would be able to get in this projet this way

Still faces of the problem of finding a developer interested in working on
it.  I wouldn't even know where to start.

- Alan
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec

2006-03-02 Thread Alan Horkan

On Thu, 2 Mar 2006, Manish Singh wrote:

 Date: Thu, 2 Mar 2006 11:11:42 -0800
 From: Manish Singh [EMAIL PROTECTED]
 To: John Cupitt [EMAIL PROTECTED]
 Cc: GIMPDev gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF
 format Spec

 On Thu, Mar 02, 2006 at 03:30:03PM +, John Cupitt wrote:
   Of course, OpenDocument document structure (ZIP archive with multiply
   files inside) could be followed.
 
  Yes, this sounds much more sensible.

 As a concept, yes. Actually using ZIP is a stupid decision,

It is a decision with some trade-offs.

I'm surprised you would dimiss it as stupid without knowing more about
what problems they were trying to solve, obviously the smallest
compression wasn't their only priority.

One thing Zip has that other archive formats don't seem to have is an
internal filesystem, and some files inside the zip can be more
compressed than others making it a good container format.  An index or
manifest can be left uncompressed, whereas other files within the archive
can be more heavily compressed if desired.

 and I wonder what the rationale for using it was.

There are more detailed explainations available (I read one very long and
detailed report on it when it was first added to OpenOffice) but if you
can find the list of requirements they had it should become clear.

No need to say unpleasant things about OpenDocument.

-- 
Alan H.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Image exchange format [was Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec]

2006-03-02 Thread Alan Horkan

On Thu, 2 Mar 2006, Simon Budig wrote:


 There were plans to work on a next-generation XCF resolving these
 issues. I too see the need for a widely accepted exchange format for
 multilayered images with a lot of additional information, but the

As things stand the main option for image exchange besides XCF seems to be
a flat lossless format like PNG.  There is also PSD but that is not a
great choice either and one I thinke we'd prefer not to recommend.

Rather than mentioning a future possible ideal format I'd like to mention
MNG, which although far from perfect for all graphics tasks (print
graphics).  This is less than ideal but still a small improvement over PNG
because at least you get to keep your layers intact (and gimp does already
have some support for MNG).

I hope you will keep MNG in consideration as it might be useful until a
more appropriate format is developed.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] [OT] Adobe Developers have a sense of humour

2005-07-05 Thread Alan Horkan

I never knew Adobe Developers had a sense of humour.  They have been
hiding easter egg splash screens in Adobe Photoshop for ages:
http://www.aresluna.org/guidebook/apps/photoshop/aboutboxeasteregg

Although this might be a little bit off topic I think the site provides a
useful collection of screenshots which should come in handy if anyone
needs a reference or wants to make any comparisions in future
http://www.aresluna.org/guidebook/apps/photoshop

(Pointed out to me by Krita developer Boudewijn Rempt.)

Hope some of you find it interesting or even useful.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [OT] Adobe Developers have a sense of humour

2005-07-05 Thread Alan Horkan

On Tue, 5 Jul 2005, Sven Neumann wrote:

 Date: Tue, 05 Jul 2005 21:50:14 +0200
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: The GNU Image Manipulation Program
 gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] [OT] Adobe Developers have a sense of humour

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  I never knew Adobe Developers had a sense of humour.  They have been
  hiding easter egg splash screens in Adobe Photoshop for ages:
  http://www.aresluna.org/guidebook/apps/photoshop/aboutboxeasteregg

 Guess what the GIMP developers have been doing (well, perhaps not for
 ages)...

I knew the Toys: GeeZoom, and Gee Slime; were Easter eggs but I've never
looked for or accidentally discovered any easter eggs in the GIMP.

A quick web search later [1] and I see holding Ctrl+Alt and then choosing
Help, About will reveal a special About dialog in the GIMP as well as in
photoshop.

Must mention this to the Inkscape developers, they are having
difficulty choosing a new splash screen from the wonderful entries
they have received:
http://inkscapers.deviantart.com/journal/5828886/#inkscape-splash


Sincerely

Alan Horkan

Inkscape http://inkscape.org
Open Clip Art http://OpenClipArt.org

[1] http://user.fundy.net/morris/photoshop13.shtml
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Krita news

2005-06-30 Thread Alan Horkan

On Wed, 29 Jun 2005, David Neary wrote:

 Date: Wed, 29 Jun 2005 21:35:53 +0200
 From: David Neary [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: [Gimp-developer] Krita news


 Hi,

 So since planet.gnome.org was down, I went over to planetkde.org to see
 what was happening over there, and I saw this blog entry:
 http://www.valdyas.org/fading/index.cgi/hacking/krita/16bits.html

 Yesterday, Krita reached a major milestone. We can now load, manipulate
 and save rgba images with 16 bits to the channel.

 I thought that might interest some of you - we're not the only game in
 town anymore, I think.

http://www.koffice.org/krita/
It is worth mentioning that Krita is intended for Painting, more along the
lines of Corel Painter and their stated interest is in creating new images
with realstic painting effects, more so than Image Manipulation although
there will be overlap.

Krita uses ImageMagick to allow it to support more file formats, in
particularly the GIMP native XCF.  There may be opportunities for both
projects to help each other by sharing resources like brushes, gradients
and patterns at least or maybe more.

I think the true strength of Krita will be tight integration with the rest
of the KOffice suite, particularly the Karbon 14 Drawing application.
A suite makes it easier to simply take it all and that gives added
momentum.

Although Krita, formerly Krayon, formerly KImageshop has been around for
many years it has not been actively developed all that time and the
maintainer describes it as still a young app with lots of work to do.

I've really been wanting to give Krita try but I've had troubles getting
it to build.

Certainly worth keeping an eye on.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Open Clip Art http://OpenClipArt.org



___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-26 Thread Alan Horkan

On Sun, 26 Jun 2005, Thorsten Wilms wrote:

 Date: Sun, 26 Jun 2005 10:17:46 +0200
 From: Thorsten Wilms [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Layer locking proposal

 On Sat, Jun 25, 2005 at 08:19:16PM -0300, Pedro Kiefer wrote:
 
  I've just made this mockup (attached) of how the locking mechanism
  should appear to the user in the layers tab. But that could be wrong, in
  not really familiar with the GNOME HIG. Clicking in an unlocked lock
  will lock the layer, clicking in a locked lock will unlock it.

 I think the lock should be in front of the layer names, right after
 visibility but before chaining, as it will block the later mechanism.
 There should be a third state for chaining, showing the symbol halfway
 faded out or something like that, to indicate it having no effect when
 the layer is locked.


 But I'm in doubt if locking is worth the space and additional visual
 complexity.

I believe locking is a necessary feature and I would not like to
discourage a developer who is willing to make the effort required to add
it.  It is better to include the feature then work out how to improve the
user interface as needed.

If people are concerned about the use of space and visual complexity of
the Layers dialog I'd like to suggest a string change (I may have
suggested it before though).  I'd like to see New Layer shortened to
just Layer (once you've created it, aint new no more) and the numbering
format changed to simply use  N which is more aethetically pleasing to
me than the pound/hash/sharp # symbol which I find a little distracting.

Turning the Layer label into a Text Area instead of one line Text Entry
might also help.  Side scrolling can be annoying and if you have Layer
preview thumbnails enabled (especially larger ones) there is quite a bit
of dead space.


Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Integrated Scripting (fwd)

2005-06-24 Thread Alan Horkan

To: Nathan Summers [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Integrated Scripting

 I've used plenty of applications where the Windows menu does
 double-duty, with the kinds of windows that can be opened, followed by
 a separator, followed by the current open windows.  Come to think of
 it, I'd say the only apps that I've used that don't do it that way are
 ones were all the windows are the same kind, anyway.

  what windows/dialogs are shown or not shown but in this case it is not at
  all pratical.

 At least to me, the View menu is for stuff that affects this
 particular view of this particular image, not dialogs and windows
 unrelated to it.

Some simpler applications use the View items globally so that if you turn
off the View of the status bar the next window will not have a statusbar
but already open windows will remain unaffected.  (this is a
simplification I'd like to seem more applications make use of, but it
slightly reduceds flexibility so I have been reluctant to suggest it for
the gimp)

   And we should actually consider to add a Windows menu that lists all
   open GIMP windows.
 
  Listing all the open window list might help reduce the requests for a
  tabbed interface to the gimp many of which seem to be due to difficulties
  in managing lots of open windows.

 That would be a nice feature to have, but I don't think it would be a
 complete substitution for tabs.

I'm not a fan of tabs.  All too often the task list and window management
are being reinvented for every app.  My comment was basically a bit of a
pot shot at Tabbed interfaces (a lot of users want them everywhere because
they work well in the web browser) and encouragement to anyone who might
want to implement the feature because I do agree it is a useful feature.

Later

- Alan H.

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] pygimp on windows? success!

2005-06-24 Thread Alan Horkan

On Fri, 24 Jun 2005, Michael Schumacher wrote:

 Great work! Seems like we will finally have pygimp 2.4 for GIMP 2.4 on each
 of the officially supported platforms. Hm, how about letting
 Script-Fu/Tiny-Fu die in favor of it? ;)

The best thing about Script-Fu has been knowing it would be available and
included in the 'default install'.  Many existing scripts are written in
Script-Fu and as you know we still regularly get users asking how to get
and old script to work with the current version.

From a technical standpoint it is great that Python and Perl subsystems
are well achitectured and entirely seperable but the failure of
distributors to include them in the 'default install' or even bother to
build them has dicouraged people from using them.  Making it possible to
leave things out is different from it being a good idea to leave things
out and I do not think users are given the best impression of the GIMP
because to the ordinary user if it is not installed it may as well not
exists.

My point is Script-Fu remains useful despite it's flaws and I am concerned
by the potential side-effects of killing it off.

Better go and improve my python skills...

- Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Integrated Scripting

2005-06-23 Thread Alan Horkan

On Thu, 23 Jun 2005, Sven Neumann wrote:

 Date: Thu, 23 Jun 2005 00:14:55 +0200
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: The GNU Image Manipulation Program
 gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Integrated Scripting

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

   The thing is that there are plenty of exceptions to that rule.
   File|Dialogs being a big source of stuff that doesn't need an image,
 
  I'm irked that we have both Dialogs and Dialogues

 Sorry, would you mind to explain that? We only have a menu called
 Dialogs. Everything else is a translated menu entry.

It is ugly little localisation issue that I wish was not an issue at all.
I should probably take it up with the en-GB translation team but if the
menu item used a word that was the same in both American and British
English my problem would go away.

Seeing the most recent version of the gimp with the word Dialogs localised
to Dialogues looks really really weird and disturbing.  I've always
thought of Dialogs  (American spelling) as the computer kind and
Dialogues (British spelling) as the conversation kind.  Software
manufacturers so rarely bother to fully localise computer terminology I
have grown to think of the American way of spelling things to refer to the
computer terminology.  I wish I could find other examples of using local
spellings to have a subtely different meaning but off the top of my head I
cannot think of any non computing related examples (analogue, dialogue,
programme, favourites, etc) but maybe you can think of examples of German
words that have ambiguous meanings depending on which German speaking
country they come from.  I hope that makes some sense.

  and I would like to see it replaced with a term that doesn't require
  extra localisation work and yes I wouldn't be averse to slapping the
  slightly inappropriate Windows label on it (benefit of consistency
  with other software) but Palettes or even Docks which actualy
  describes the type of dialogs might be better.

 Windows is usually used for a list of opened windows.

Photoshop is a bit weird I admit but the Windows menu is where it puts the
menu items to control what Palettes are shown.  The list of Open Windows
is also included in there somewhere, and also an option to save
workspace which will make sure window positions are remembered and a few
other bits and peices (like maybe Close All, but I dont have convenient
access to Photoshop so I'm really not sure what is in there).

 So if we used that we would use a term that is consistently used in
 other applications for something completely different.

In theory the View menu would be the place to put menu items to control
what windows/dialogs are shown or not shown but in this case it is not at
all pratical.  It may not be consistent in the general sense but
graphics applications do what is consistent with Photoshop for better
or worse.  The menus are being reorganised anyway and this
would be one less thing for them to complain about, so if ever there was
an appropriate time for me to mention it I think this is it.

 And we should actually consider to add a Windows menu that lists all
 open GIMP windows.

Listing all the open window list might help reduce the requests for a
tabbed interface to the gimp many of which seem to be due to difficulties
in managing lots of open windows.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread Alan Horkan

to the number of happy users? We can hardly decide anything unless
we know the answer to these questions.

 I've seen quite a number of people -- Marc, Alastair Robinson, Bill
 Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael
 Thaler, and myself -- complain more or less vociferously about this,
 for what appears to be more or less the same reason.  Alan Horkan
 appears to have at least some complaints about it,

I do not disagree with Sven on this.  Please do not count me in on this
arguement, I probably should not have commented at all.  On balance the
new file chooser is better, it just happens to be worse in some of the
ways the old file chooser was good and I do recognise it has issues.

On balance I support the new File Chooser.  I see the problems with it as
mostly GTK problem.  You cannot really argue against the merits of a clean
API that allows you to go ahead and write your own replacement.  Now that
i think if it GPE are one of the few groups who have gone ahead and done
this, and I am increasingly tempted to attempt it myself (but dont hold
your breath it would take me a long time to develop something I would be
willing to show in public).

- Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Integrated Scripting

2005-06-22 Thread Alan Horkan

On Tue, 21 Jun 2005, Akkana Peck wrote:

 Date: Tue, 21 Jun 2005 17:38:36 -0700
 From: Akkana Peck [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Integrated Scripting

 Nathan Summers writes:
  On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote:
   different levels of artificial intelligence; are there opinions of ways
   to rearrange the Xtns portion of the menu system?

 Great topic. Personally I'd love to see the Script-Fu and Python
 entries go away, for the same reason as in the Filters menu:
 the user shouldn't have to know.

Agreed.

  The thing is that there are plenty of exceptions to that rule.
  File|Dialogs being a big source of stuff that doesn't need an image,

I'm irked that we have both Dialogs and Dialogues (I prefer generic
English) and I would like to see it replaced with a term that doesn't
require extra localisation work and yes I wouldn't be averse to slapping
the slightly inappropriate Windows  label on it (benefit of consistency
with other software) but Palettes or even Docks which actualy describes
the type of dialogs might be better.

 File-Dialogs doesn't make a new image. I'm with Carol, most of the
 stuff in Xtns makes a new image, and should be grouped together
 accordingly.

 Right. If it were up to me, I'd split Xtns into two menus:

 1. Development (or something similar): all the entries that have to
 do with mechanics of the languages (including C). It would look like:

Mozilla uses a De_bug menu which is hidden in release builds and something
similar (like Developement as you suggested) might be a good approach as
these tools are mostly used for development and debugging of scripts.

Module Manager
Plug-in Browser
Procedure Browser
Unit Editor

Script-Fu Console...
Refresh Script-Fu
Start Script-Fu Server...

Python-Fu Console...
Python-Fu Browser...

I think the Procedure browsers have been unified and I think we are
arleady down to just one Procedure browser.

Python-Fu does not require a Refresh.
Does Tiny-Fu require manual refresh?

It is my understanding you set the Units and do not often need to change
them.  For a long time I have thought the Unit Editor would make an
approrpriate section of the Preferences dialog.

 2. All the things that actually make new images. I don't know what
 to call this menu. Xtns or Misc or Generate (because it generates

One of the minor complaints about Xtns is it being an abbreviation.  This
makes it harder to translate and difficult to understand not just for
begninners but for anyone who may be using the GIMP in English but not
have English as their first language.  Space will always need to be
considered for langauges with longer labels so there is little point
trying to pick short words rather than picking the most approrpriate
words.

 new images) or Create or New Images or ??  This would include all the
 submenus that are currently under Script-Fu, without any reference to
 the word Script-Fu. Any Python scripts (or C plugins or anything else)
 that gets added would merge into these menus too.

The logo browser suggested by Sven may provide an alternative way to clean
things up.
http://bugzilla.gnome.org/show_bug.cgi?id=158980

A Dialog/Palette devoted entirely to Scripts (similar to what Adobe does
to hide away their Actions) might work but hiding away the scripts like
that isn't the best solution either.

 There was some suggestion on IRC that not all the items in the
 Xtns-Script-Fu submenus create new images. I haven't gone through
 them yet to look for counterexamples; if there are some, maybe they
 should go somewhere else. Likewise, if there are items in Filters
 which create a new image rather than working on the current one
 (I don't know of any) then they should move here.

All of the pattern scripts could be moved to the current image and they
would be more useful there, the following bugs attempt to address that:
http://bugzilla.gnome.org/show_bug.cgi?id=145145
http://bugzilla.gnome.org/show_bug.cgi?id=145146

(I never got around to finishing Truchoid exactly as I wanted but I should
be able to make a quick fix to complete moving all the scripts)

   Logos
   Make Brush
   Patterns

(as I tried to explain above only a little work is needed to finally
moves these pattern out of the toolbox)

   Web Page Themes
   ---
   Custom Gradient...
   Font Map...
   Round Button...
   Simple Bevelled Button...
   Sphere...

 Thoughts?

More later probably ...

- Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Alan Horkan

On Wed, 22 Jun 2005, Robert L Krawitz wrote:

 Date: Wed, 22 Jun 2005 07:32:11 -0400
 From: Robert L Krawitz [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of
 GIMP

From: Sven Neumann [EMAIL PROTECTED]
Date: Wed, 22 Jun 2005 10:12:05 +0200

Robert L Krawitz [EMAIL PROTECTED] writes:

 Sven, you've been offered a solution -- just add an entry with tab
 completion.  You may not agree with it, but it's not accurate to say
 that noone has made a proposal on how such an entry should be
 integrated with the current dialog.  Just stick it on the bottom of
 the dialog, just above the OK/cancel boxes, and Marc and I will be
 happy to shut up.

This is not about making you and Marc shut up. This is about
designing a user interface that works for the majority of
users. Whatever we do, there will always be someone complaining. I
don't really care who that is.

 This one seems to be attracting a disproportionate share of
 complaints.  Usually with other controversial interface issues I see a
 few comments, and then people start to converge.  This one is
 different.

It is unfortunate that the new file chooser is bad at exactly the things
the old file chooser was good at, a case of six of one half dozen of the
other.  (I always have a terminal open and make frequent use of
gimp-remote so I dont mind to the new file chooser too much.)

 In what way is just adding an entry with Tab completion going to
 ruin the whole thing?  If it's there, but isn't used, it isn't
 going to interfere with anything else, is it?

It does indeed interfere with the rest of the dialog, otherwise it
would probably have been added a while ago already. But I already
explained the problems of this approach in another mail that I sent
last night.

 If I understood correctly, it's a conflict between the use of tab for
 completion and tab for jumping between widgets?  If so, how about
 using a different keystroke for completion (escape or ctrl-tab, for
 example)?

 Perhaps another approach would be for the integrated text input to be
 initially hidden, but with a More button that makes it visible.
 The state of the More button is saved, so that the next time the
 dialog is popped up it has the same components as it did before.

 And why is it so important that there be a concept for the entire
 dialog beyond what works best for people?  The problem (to me,
 and I daresay to Marc) is very simple -- there's no obvious way
 to simply enter a pathname with a simple form of completion
 that's only activated on demand.  A file dialog without this is
 just plain fatally flawed.

The problem is to find out what works best for people. Trying to
decide this in an argument among developers is very certainly going
to fail.

 The problem is that there's no one method that works best for
 people.  People like Marc and I find the old dialog much more suited
 to our needs than the new one.

 Obviously the problem is a GTK issue, not a GIMP issue.

There seems to be a big benefit to developers in using the new File
Chooser API.  I am a little surprised no one has ported the old file
chooser to the new API, or written any alternative file choosers that work
with the new API.  (There was definately some talk of adding support for
the KDE file chooser to use the Gtk File Chooser API by developers
connected with Freedesktop.org or Redhat I think but I am pretty sure
nothing ever came out of those wild ideas but the Gtk Developers would be
the ones to ask I guess.)

I notice some projects have added support for the new file chooser to make
it a compile time option but mostly as a way to avoid forcing their users
to use the latest version of GTK.  I expect the gimp requires an up to
date version of GTK for other other reasons but perhaps support for the
old file chooser could be added as a compile time option (horribly
inelegant and another unpleasant configuration option I know but I wanted
to put it out there as a possibility).

- Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-18 Thread Alan Horkan

On Fri, 17 Jun 2005, Leon Brooks wrote:

 Date: Fri, 17 Jun 2005 09:05:30 +0800
 From: Leon Brooks [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

 This may seem like an oxymoron, given GIMP's heavy defacto relationship
 with GNOME-flavoured GTK, but is there any GIMP equivalent to
 OpenOffice's KDE integration (http://kde.openoffice.org/)?

 The closest I could find was a vague reference to a pre-2.0 KDEified
 version of The GIMP, apparently called KIMP...

 http://dot.kde.org/1096230607/1096270511/

 ...and this discussion, which is obviously approaching the issue from
 the KDE end and not the GIMP end of things (IMESHO, starting from the
 wrong end):

 http://lists.kde.org/?l=kde-develm=92756018422117w=2

 I am guessing that a zero overhead (at least for GTK, I'd envision
 this as a 1:1 mapping using #defines) toolkit mapping layer at the
 source-code level would make ports for Qt/KDE, Carbon, wxWidgets or
 whatever considerably easier. Then there'd be only alternative shims to
 maintain, not a whole raft of debris integrated with The GIMP proper,
 and toolkit bugs would all be located in very few files.

I am optimistic project like metatheme will help improve consistency
between Gtk and KDE applications and help leave the choice of toolkits to
the developers.  If you are interested in looking into it futher here is
their website:

http://metatheme.advel.cz/

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] GIMP is not a GNOME application

2005-06-18 Thread Alan Horkan

On Fri, 17 Jun 2005, Sven Neumann wrote:

 Date: Fri, 17 Jun 2005 23:11:25 +0200
 From: Sven Neumann [EMAIL PROTECTED]
 To: Leon Brooks [EMAIL PROTECTED]
 Cc: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of
 GIMP

 Hi,

 Leon Brooks [EMAIL PROTECTED] writes:

  This may seem like an oxymoron, given GIMP's heavy defacto relationship
  with GNOME-flavoured GTK, but is there any GIMP equivalent to
  OpenOffice's KDE integration (http://kde.openoffice.org/)?

 GIMP is not a GNOME application,

This point has been made before and I hope Sven is willing to clarify this
point a little more as I do not entirely understand his purpose in saying
it or putting it exactly that way.

People have different ideas of what it means to be a Gnome application.
For a long time the prevailing view has been a Gnome application is
an application which uses Gnome libraries and applications that are
part of the Core Gnome desktop.  In this sense the GIMP is not a Gnome
application as it does not require libraries outside of GTK.

 it uses GTK+, the GIMP toolkit. This is by chance the same toolkit that
 GNOME uses, so integration with GNOME is easier to achieve. That doesn't
 mean though that we wouldn't try to make GIMP work well on KDE.

Most mature developers recognise the benefits of working closely with KDE,
following standards from Freedesktop.org and making applications integrate
better.  A desire to work well with both Gnome and KDE is no certainly
barrier to an application becoming a Gnome application.

 GIMP supports most of the cross-platform specs that the KDE and GNOME
 people are developing to make this happen. What is missing to achieve
 better KDE integration is someone who tests GIMP on KDE, gives feedback
 and points out what's working and where there are problems.

There is the strict sense of what it means to be a Gnome application which
I described above and is what I believe Sven means and then there is the
broaders sense of Gnome applications I will now try and describe.

Some people carelessly refer to all GTK applications as Gnome
applications, acronyms dont slip off the tongue quite as easily as words
do but this really is not accurate or helpful.  (Acrobat Reader 7 and
Realplayer 10 are Gtk applications but about as far away from Gnome as you
can get.)

Increasingly there are many Gnome applications which no longer require any
Gnome specific libraries and even the concept of Gnome libraries has
changed with more and more work being done to improve Gtk instead of
rebuilding uncessary layers on top of it.  The older technical distinction
is not as obvious or as clear anymore and many applications optionally use
gnome libraries (compile time options) and can be quite different
depending on what you choose.

Gnome has a wider community beyond the core desktop applications and there
are other vaguely defined areas such as Gnome Office, Fifth Toe, and
others which are sometimes considered to be Gnome based on developers
showing an interest and being willing to consider themselves as part of
Gnome in the much wider sense.  The GIMP is sometimes described as being
part of the Fifth Toe, part of the wider community and well integrated
with Gnome.

Following the Gnome Human Interface Guidelines is something by itself
which many people consider enough for any application to consider itself a
Gnome application.

Some people think applications which use Gnome CVS, and Gnome Bugzilla,
the Gnome Translation Project and maybe evne the Gnome Help browser to be
a part of Gnome.  If a developer has asked for their journal to be
included on Planet Gnome one might be forgiven for getting they impression
they considered themselves part of the wider Gnome community.

If the GIMP developers decided tomorrow to start saying the GIMP was a
Gnome application without chaning anything else I sincerely doubt any
Gnome supports would disagree and in fact I think many would welcome the
gesture.

Making a firm commitment to supporting the needs of KDE users and make
promises not to require Gnome libraries certainly does not mean the GIMP
needs to publically distance itself from Gnome.  I firmly support efforts
for better interoperability and work to keep the GIMP clean and portable.

Perhaps Sven can clarify, I hope when he said GIMP is not a GNOME
application he was describing it from a strict technical point of view
and did not mean to distance the GIMP from the wider Gnome community which
unfortunately was the impression I got in the past and one I think others
might have also mistakenly gotten too.

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[OT] RE: [Gimp-developer] Re: Akanna Menu patch

2005-06-10 Thread Alan Horkan

On Thu, 9 Jun 2005, Phil Lello wrote:

 Date: Thu, 9 Jun 2005 00:48:29 +0100
 From: Phil Lello [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: RE: [Gimp-developer] Re: Akanna Menu patch

 And of course, not everyone has a right mouse button... or do new
 Macs have more than one button?

Rather than picking on Apple for choosing a single button mouse (which I
actually like for reasons not worth going into again) point is not all pen
and tablet devices have a convenient equivalent to right click which I
think you will agree is more relevant to the gimp.

- Alan
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Script Fu and stuff [was Re: Akanna Menu patch]

2005-06-10 Thread Alan Horkan

On Thu, 9 Jun 2005, Kevin Cozens wrote:

 Date: Thu, 09 Jun 2005 17:57:50 -0400
 From: Kevin Cozens [EMAIL PROTECTED]
 To: gimp-devel gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC
 meeting]

 Alan Horkan wrote:

  I really like the idea of providing information about menu items but not
 
 the proposed implementation.  The way many other Gnome and GTK give the
 information applications do is to show a description of a menu item in the
 status bar.  Perhaps the existing short description/summary/blurb in most
 plugins could potentially be repurposed for this, what do you think?

 Most users will invoke items from the menu and won't care what carries
 out the action (ie. plug-in, or script) so I don't feel the menus should
 provide any such information.

If all else fails trial and error is an adequate way to learn more about
what the various scripts and plugins do.

 What would be useful is for the Procedural Browser to include the menu
 path as is currently done in the plug-in browser.

This would be somewhat helpful but ..

 While working on Script-Fu/Tiny-Fu scripts I often use the browser to
 determine which PDB call I need to use for a given task.

What I do sometimes is leave an image open and then in the Script-Fu
Console to find it value I use
(gimp-image-list)
and then pass that to the functions I want to try out.

The proposed Logo/script browser[1] in bug 158980 might be able to make
this process even easier and apply a function to a current image.

(I made a really awful attempt at this using the Python based PDB
Browser and by passing dummy values to get plugins to pop up)

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

[1] Full Link to bug 158980
http://bugzilla.gnome.org/show_bug.cgi?id=158980

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting]

2005-06-07 Thread Alan Horkan

On Mon, 6 Jun 2005, Sven Neumann wrote:

 Date: Mon, 06 Jun 2005 00:24:47 +0200
 From: Sven Neumann [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Cc: [EMAIL PROTECTED]
 Subject: [Gimp-developer] The GUADEC meeting

 Hi,

 now that GUADEC is over and everyone's back home, you will probably
 want to know what has been happening related to GIMP at this year's
 GUADEC in Stuttgart. Let me try to give a short summary of the GIMP
 meeting we had on Monday.


 The menu reorganisation effort was raised. It seems that Akkana's
 proposal is widely accepted.

I wasn't previously aware of this proposal (no mention of it in the wiki
and I thought I was on the bug CC list but apparently not) but I
eventually found a patch by Akkana which I assume is the one to which you
are referring.
bug report on menu reorganistion:
http://bugzilla.gnome.org/show_bug.cgi?id=116145
Patch by Akkanna to get things started:
http://bugzilla.gnome.org/attachment.cgi?id=46852action=view

 The proposed patch can be improved but it is a good start. If Akkana or
 someone else has time and motivation to continute to work on this, then
 the patch can be committed right away.

The patch is a substantial improvement, an excellent start by Akkanna.

It will be a big improvement to have things grouped by what they do rather
than how they do it.  I think it is worth mentioning though that Adobe
Photoshop didn't even attempt this and instead they copped out and buried
their scripts in a seperate Actions dialog, so it may be difficult to keep
things managable as people want to add more and more extensions (but I
still think the patch is a very good and necessary first step).
http://wiki.gimp.org/gimp/GimpMenuReorganization

I was thinking fo doing something similar for the python plugins (and
making sure to add ellipses where needed).  However some of the python
plugins duplicate existing functionality so putting two Clothify plugins
beside each other would only confuse users.  I see Akkanna tackled this by
marking the Script-Fu unsharp as Unsharp 2 but if people have idea on
how to tackle this duplication of functionality I would be interested to
hear it. (I must say when it comes to learning to port scripts to python I
found it very helpful to have similar examples written in a different
language) plugin written .  One possible way to disambiguate similar
plugins might be to give them different menu icons but expect you can
probably come up with something better than that.

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting]

2005-06-07 Thread Alan Horkan

On Tue, 7 Jun 2005, Joao S. O. Bueno Calligaris wrote:

 Date: Tue, 7 Jun 2005 10:39:30 -0300
 From: Joao S. O. Bueno Calligaris [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC
 meeting]

  written .  One possible way to disambiguate similar plugins might
  be to give them different menu icons but expect you can probably
  come up with something better than that.

 I always saidthat tehere should be some way to identificate a menu
 entry. Not only there will be up to four (C, script-fu, Python-fu,
 tiny-fu) equivalent entries on a row, as you point out - but I think
 one has the right to know how each menu entry got there.

'kay, menu icons clearly aren't the best idea.

 I suggested them that right-clicking on a menu item would bring some
 information about it. (Like:  the package where it came from, what
 language it is written in, and maybe even accept a new shortcut for that
 item, without having to enable dynamic shortcuts)

I really like the idea of providing information about menu items but not
the proposed implementation.  The way many other Gnome and GTK give the
information applications do is to show a description of a menu item in the
status bar.  Perhaps the existing short description/summary/blurb in most
plugins could potentially be repurposed for this, what do you think?

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Re: Akkana Menu patch

2005-06-07 Thread Alan Horkan

On Tue, 7 Jun 2005, Akkana Peck wrote:

 Date: Tue, 7 Jun 2005 10:20:21 -0700
 From: Akkana Peck [EMAIL PROTECTED]
 To: The GNU Image Manipulation Program
 gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: Akkana Menu patch [was Re: [Gimp-developer] The GUADEC
 meeting]

 Alan Horkan writes:
  I was thinking fo doing something similar for the python plugins (and

 It was my intention to include python-fu as well. I must have missed

Excellent.  If you could add the ellipses (...) too I'd appreciate it.

 Nobody's commented on any of the other questions I asked in the bug,

I'd like to get your changes in as it is so difficult to get everyone
to agree and then start to make more changes as we can get some
sense of what changes are uncontraversial and people are happy with.

 like whether it would be a good idea to fold the short Glass Effects
 menu into Light Effects,

go for it

(it is probably worth mentioning though that Photoshop puts Lens under
Distorts and now it the time to consider incorporating things from
Gimpshop)

 or moving Enhance up to where it's just under Blur, or whether there's a
 reasonable place for Show Image Structure since it's now the only item
 in Utils.

I thought it had been changed already but abbreviations like Utils and
Decor should be avoided.

 I'll go ahead and move Enhance since no one objected; maybe I'll
 try to come up with some place to stick Show Image Structure.

I'm really not sure, I think that might require a rethink of what
categories are needed to accomodate third party plugins and scripts.
(I'd be tempted to dumpt it beside Colour Cube analysis because I use
both for similar puroposes but I know that isn't a good answer).

 (The bug is http://bugzilla.gnome.org/show_bug.cgi?id=116145 if
 anyone wants to comment there or read the questions in more detail.)

 I'd be interested too. I don't like Unsharp Mask 2 but strings
 like Unsharp Mask (script-fu) are likely to make the menus too
 long. Anyone have a better idea?

I didn't want to mention it earlier but as you intend making another
patch I should mention you used _U as the mnemonic for both Unsharps.

A lot of my opinions have been added to the Wiki page but it doesn't lend
itself to discussion or otherwise sorting out which ideas people really
want, I suppose I should try and catch people on IRC sometime this week
and thrash out which other ideas people feel strongly about rather than
cluttering the list with too many little details and slowly churning
through them one by one.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Apply palette to image colormap

2005-06-02 Thread Alan Horkan

 And... it is buggy.  It failed me when applying 256 color palette to a
 256 colro image with the message:
 ---
 Error while executing
 (tiny-fu-set-cmap 6 12 Gold)

 Error: car: argument 1 must be: pair
 --
 Not to mention:

 WARNING: Plug-In tiny-fu
 (/usr/local/lib/gimp/2.0/plug-ins/tiny-fu)
 called deprecated procedure 'gimp_image_set_cmap'.
 It should call 'gimp_image_set_colormap' instead!

Normally I'd be in favour of expanding abbreviations to make things
clearer but in this case the shorter deprecated name avoids the confusion
caused by the American mispelling of Colour (damned Webster and his
patriotic neologisms).

- Alan H

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Reply to Considered Harmful [Re: [Gimp-developer] Gimp server startup [OT]]

2005-06-01 Thread Alan Horkan

On Tue, 31 May 2005 [EMAIL PROTECTED] wrote:

 Date: Tue, 31 May 2005 18:48:58 +0200
 From: [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] Gimp server startup [OT]

 On Tuesday, May 31, 2005, 17:24:01, Michael Schumacher wrote:

  This is intentional - google for reply to considered harmful.

 This might have been of concern years ago, before people were used to
 mailing lists which do set the Reply-to header. Nowadays, I'd say that the
 opposite is true, since setting the Reply-to header seems common practice
 (at least if I look at the mailing lists I'm following, there are only 2
 that don't set the header).

The problem is still the same.

It is better to accidentally mail only one person and need to resend to
the list than it is to accidentally send mail to many people.

- Alan

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Idea for new plugin

2005-05-24 Thread Alan Horkan

On Tue, 24 May 2005, Chin2 wrote:

 Date: Tue, 24 May 2005 12:34:42 +0530
 From: Chin2 [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: [Gimp-developer] Idea for new plugin

 hi everone around
  i have an idea for a new plugin for gimp. i may not be able explain it very
 well. but for those who wuold understand it would be nice..

 http://www.freewebs.com/chin2online/plug1.jpg

The picture explains it well enough.

When people refer to the selection I would like to make it clear that you
are distorting the image (contents of the selection) rather than the
selection (the shape of the selection), but I understand it can be
difficult to explain these things clearly.  This is essentially a
distortion and hasn't much to do with the selection.

Such an effect can be achieved by creating an Elliptical selection and
then using the Perspective tool to invert and distort or rotate the
selection as desired.

It should be possible to automate the process using a script or a plug-in
if a programmer was interested enough to do it.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] use stock gtk about dialog in plugins?

2005-05-20 Thread Alan Horkan

I was looking at version 2.3 and was pleased to notice lots of little
details that have been polished or tweaked.

For no particular reason I noticed some of the plugins have an About
dialog and since the GIMP requires gtk 2.6 I started about getting them to
use the GTK_STOCK_ABOUT button and the standard gtk about dialog.

I spent quite a while checking which applications use an about dialog and
the list was extremely short:
Fractal Explorer
Gimpressionist
ImageMap
(Gfig used to but doesn't at least not in version 2.3)

Rather than getting these applications to use the new GTK About dialog I
also considered removing the about dialog entirely (the information is
still availalbe from the Plugin database if anyone wants it).  However I
didn't think this was a change developers would be eager to make and
wasn't going to bother suggesting it until I read this existing comment by
Sven which suggested completely removing the about dialog from the Fractal
Explorer.
http://bugzilla.gnome.org/show_bug.cgi?id=140202#c13

So would it be acceptable to remove the about button and dialog from both
Fractal Explorer and Gimpressionist?  If it is I'll file a request and try
and provide a patch at some stage.  Either way ImageMap should probably
use the gtk stock about dialog, so I'll give that a try for starters.

Sincerely

- Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Re: [Inkscape-devel] common interface for graphics apps on thefree desktop

2005-02-03 Thread Alan Horkan

On Thu, 3 Feb 2005, Jakub Steiner wrote:

 Date: Thu, 03 Feb 2005 20:57:45 +0100
 From: Jakub Steiner [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: gimp-developer@lists.xcf.berkeley.edu
 Subject: [Inkscape-devel] common interface for graphics apps on the free
 desktop

 One of the good things about Adobe's product line is that they work
 together. Same tasks require the same interface. Shortcuts are
 consistent.

 On the free desktop we have two major graphics applications, Inkscape
 (http://www.inkscape.org) and GIMP (http://www.gimp.org). It will not be
 uncommon to have users needing both apps in their workflow. I hope you
 guys agree trying to have similar consistency helps to provide a sane
 user experience.

There is definately some room to improve consistancy that wont bother
either project but as I'm sure you are aware Inkscape quite deliberately
has a different user interface from the GIMP so hopefully we can stick to
the bits everyone can agree on.

It is probably worth mentioning that Inkscape is likely to implement some
form of dock to help manage the Palette windows.  It is also likely in the
long term that the toolbar widgets in Inkscape will become more flexible
allowing a somewhat more flexible layout of the user interface.

 To be specific, there are areas where GIMP  Inkscape provide similar
 functionality in a slightly different way. For now I will ignore the
 path tool.


 An inconsistency that came up while I was working on
 something is the mouse wheel behavior. GIMP uses shift+scroll wheel to
 zoom, Inkscape Ctrl+mousewheel. GIMP uses Alt+mousewheel to pan
 horizontally, Inkscape uses Shift+mousewheel. I've filed this as
 http://sourceforge.net/tracker/index.php?func=detailaid=1115612group_id=93438atid=604306

According to the GNOME Human Interface Guidelines Inkscape is using the
preferred behaviour (and although I would need to double check I am
reasonably sure this behaviour is consistant with Apple and Microsoft
guidelines).

http://developer.gnome.org/projects/gup/hig/2.0/input.html#mouse-buttons
Ctrl-scrollwheel-up should zoom into the window or control under the mouse
pointer, and Ctrl-scrollwheel-down should zoom out. Zooming in this way
should not move keyboard focus to the window or control being zoomed.

 It would be cool if somebody found the motivation to write up some
 extension to the Gnome HIG, defining a standard behaviour for gfx apps
 (*hint* *hint* ;).

I do agree that a section describing how best to design Palette Dialogs
is needed as they need to be compact and are quite different from the
standard transient dialogs described by the current guidelines.

 Sorry for cross posting, but I hope to initiate some discussion among
 both camps.

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

(Feel free to reply to one list or both but please don't CC me)
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] xtns-extras ?

2005-01-23 Thread Alan Horkan

On Sun, 23 Jan 2005, Joao S. O. Bueno Calligaris wrote:

 Date: Sun, 23 Jan 2005 01:50:27 -0200
 From: Joao S. O. Bueno Calligaris [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: [Gimp-developer] xtns-extras ?

 Hi,

 a few weeks ago I wrote mentioning that it might be a good idea
 to rename the Xtns menu entry to Extras.

Abbreviations are a bad idea, some languages inevitably require longer
strings which is why most menus will have lots of spare space to the
right.

 Therefore, I am trying it again:
 What do you say about renaming Xtns to  Extras? I think it would
 be a good change to the GIMP's general look and feel.

I dont think it will make much of a difference either way.

If this change were going to happen it might be best to make it part of
the extensive menu overhaul that was considered but stalled.

- Alan H
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg-exif development summary

2005-01-05 Thread Alan Horkan

On Wed, 5 Jan 2005, William Skaggs wrote:

 Date: Wed,  5 Jan 2005 07:47:10 -0800
 From: William Skaggs [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Cc: @mail.primate.ucdavis.edu
 Subject: Re: [Gimp-developer] jpeg-exif development summary


 Robert Krawitz wrote:
4) When the exif specifies that an image is rotated, the plug-in
   pops up a query asking the user whether to rotate it into
   standard alignment.  I thought it was better to ask rather than
   do it automatically, because there are probably a substantial
   number of existing images that have been edited without having
   their exif information properly updated (for example, by earlier
   versions of GIMP).  When an image is saved with exif, the
   orientation is set to top-left, as the exif specifications
   require.  (See bug #121810)
 
  I'd suggest making this a preference.  If someone's careful about
  maintaining their images (or hasn't edited them before), they'll get
  very annoyed by having to answer this question every time they open an
  EXIF file that's rotated.  Wouldn't earlier versions of the GIMP have
  destroyed the EXIF data?

 That would be a reasonable thing to do:  Rotate images if exif says so?:
 _Always _Never _Ask each time.  But we have a high threshold nowadays
 for adding new preferences, so this is something that probably won't
 happen until it's clear that a lot of people want it.

I hope you will consider that the simplest thing to do is to follow the
specification and try to do things in such a way that in the long run
there should be no need for a prompt or a preference?  I do realise
thatrotating the view without rotating the image itself is making things
complicated but perhaps it would be possible to have the importer take
care of the rotation and the exporter rotating back as needed, and still
preserving all EXIF metadata?

- Alan H.

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Why not allow the name to be configurable?

2004-12-13 Thread Alan Horkan

On Sun, 12 Dec 2004, Robert L Krawitz wrote:

 Date: Sun, 12 Dec 2004 17:00:24 -0500
 From: Robert L Krawitz [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
  [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer]  Why not allow the name to be configurable?

From: Sven Neumann [EMAIL PROTECTED]
Date: Sun, 12 Dec 2004 18:05:46 +0100

Alan Horkan [EMAIL PROTECTED] writes:

  I have to ask why reject such patches?

 Because IMO the name is important. If we allow the name to be changed
 easily,

 It would also make it way too easy for anyone who wants to make some
 quick money out of The GIMP.  We must not allow people to change the
 name by means of a simple configure option and let them benefit from
 our hard work.


 Changing the source code and documentation is the easiest part of it.
 The hard part is changing the web site, references all over the net,
 etc.  I speak here from ongoing experience -- the Gimp-Print project
 is in the process of renaming to Gutenprint.

I am not asking the GNU Image Manipulation Program to change name.

I was asking why patches that might make it possible/easier for others to
change the project name and branding would be rejected.

I am aware of some the difficulties that would occur if the GIMP were to
change name tomorrow which is why I want to make it clear that wasn't
what I was asking.  It is also extremely unlikel for a name change
to ever happen which is why I was asking a subtley different question.

I have accepted Svens answers on this matter and do not intend to push it
further.  I dont find the name amusing or clever but it does not get in
the way of my image editing.

 Changing the source took Roger Leigh perhaps a week or so, but the web
 site, hosting, etc. are still moving along very slowly, and we have a
 lot of work to do.

While going through this process did Roger Leigh replace the name or did
he abstract the name so that if some one was ever forced to change it
again it could be done more easily?  (the latter would of course take much
more time)

 This is probably the primary reason that 5.0 wasn't released perhaps a
 month ago.

I'm surprised the rebranding was not done seperately from the release, but
that is probably only something that is obvious in hindsight.

I would guess you changed the name of gimp-print to guten-print first and
foremost because the project is seperate from the gimp but presumably you
were aware that a small minority find the term gimp somewhat
inappropriate and that it might be easier to market a different name.

I wish Guten-Print the best of success with the new name and I encourage
you to make as much publicity out of it as you can.  (Still haven't seen
any stories on it yet, just mailing list posts but I suppose I'll hear a
lot more about it when 5.0 is released.)

 If a project as big as Mozilla Firefox allows it name to be
 changed, why would it be an issue for the gimp?

For Firefox having the name configurable is part of the business
plan.  I can't find any such note in the GIMP's business
plan. Heck, I can't even find the plan.

 Firefox had a little legal problem on their hands, and didn't have
 much choice.

Firefox started off as a fork of Mozilla, was codenamed mb2, then Pheonix
then Firebird.   I really doubt the clean abstraction of the name had
anything to do with the legalities but as Sven suggested much more do to
with the business plans of Netscape and the Mozilla foundation to allow
rebranded versions of their browser.
Better a hundred branches than one fork.

The project name could be have been changed crudely using grep and other
tools or by messing around with the translations (something I may still
look into) but it is another matter entirely to improve the abstraction of
the code and make it so that the name is configurable and need only be
changed in a few key places.

The Mozilla foundation does want to encourage commercialisation of their
product and the GIMP doesn't, fair enough.

Sincerely

Alan Horkan


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Why not allow the name to be configurable? [was [Bug 160890] Change Gimp name (fwd)]

2004-12-13 Thread Alan Horkan

On Sun, 12 Dec 2004, David [iso-8859-15] Gómez wrote:

 Date: Sun, 12 Dec 2004 17:19:26 +0100
 From: David [iso-8859-15] Gómez [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] Why not allow the name to be configurable?
 [was [Bug 160890] Change Gimp name (fwd)]

 Hi Alan,

  I don't think it is a good idea to change the project name.

 So you kind of answered to yourself...

No that is the answer to quite a different question.

I asked why not accept patches that make it easier to change the name.

  It is a good sign that the gimp has improved so much that people are only
  left with the name to complain about :)

 I don't complain about the name.

I never claimed you did.

  I think it would be a fair compromise to accept patches that make it
  easier for those who would like to configure the name.

 That a non-sense claim. I think that people that get offended by
 a name have deeper problems.

You can say it is trivial or silly but you cannot deny that it happens to
bother a small minority of people.

I do not know if you are a native English speaker but the term gimp is has
a very similar meaning to cripple.  If you look at the bug report I
point to some comments where people other than me say they have
encountered difficulties, notably the embarassment of explaining the name
really was the gimp to a person in a wheelchair and that the user was not
mocking them.

 And they should worry first about them instead of changing everybody's
 minds to their way of thinking.

I say again that I was not asking to change what everbody else calls the
GNU Image Manipulation Program but I was asking why it would not be
acceptable to make it easier for other to change the name (and Sven has
explained the reasons for it).

 I answer to you, because i work on a window manager with a name
 that could be considered offensive by spanish-speakers with similar

What is the name?

 ideas to the users who claim that gimp should change its name. But we
 didn't intend to offense anyone when we choosed the name, it was just a
 joke.

I'm not a big fan of funny project names because different people find
completely different things funny, and I much prefer names that give some
idea of what a project does (which the long form GNU Image Manipulation
Program does serve that purpose).

But this is all beside the point, I'm not trying to force the majority to
change their ways but I wanted to make it easier for the small minority to
help themselves.

 People who complained about the name understood this when we explained
 it to them.

  If a project as big as Mozilla Firefox allows it name to be changed, why
  would it be an issue for the gimp?

 There was another project called Firebird, so there was a good reason
 to change it.

As Sven explained and I pointed out in other posts the fact that Mozilla
and Firefox can be so easily rebranded has far more to do with Netscape
than it does any legal issues.

  Why require people to fork or maintain their own patchsets for the sake of
  a little extra configurability.

 I wouldn't call it configurability.

What would you call it then?

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Why not allow the name to be configurable?

2004-12-13 Thread Alan Horkan

The bug report in question was
http://bugzilla.gnome.org/show_bug.cgi?id=160890

I got the name wrong in the message body but it was correct in the message
title.

  On Sun, 2004-12-12 at 11:05, Sven Neumann wrote:
  I seriously doubt that the name is effectively keeping GIMP from being
  used. And I am all happy to ignore the very few people who are so
  narrow-minded as to having a problem with the name.

Narrow minded PHB's or school principals are apparently part of the
problem.

  While I agree with most of what you've said in response to this
  thread, Sven, I take a bit of exception with this.  Being one of the
  few open minded liberals stuck in Texas, I tend to be a little
  sensitive to being called narrow minded.

 My apologies. I shouldn't have generalized here. As you pointed out
 there's a difference between having a problem with the name and
 refusing to accept the software because of the name and despite better
 knowledge.

 So what I suggest we do is to keep the name,

Modifying or otherwise changing the official name causes far too many
other problems (the website domain name for one thing) which is why I have
only gone as far as to suggest that things be made easier for users to
change for themselves.

 but perhaps we can indeed do something about the way it is perceived. It
 could help to use the full name more.

I think that would help, especially for things like press releases.
I usually try to use the long name to avoid any ambiguity.

 Not saying that we should avoid using the acronym but perhaps it would
 be good if we could try to mention the full name

I would of course be willing to try and help with such an effort.

 in release announcements and such at least once. If someone wants to
 review the README, NEWS. INSTALL files as well as

 the man-pages for this, that would be appreciated.

the man page looks pretty good (at least on FreeBSD), the name is
explained immediately and the acronym expanded at the start of the
DESCRIPTION section.  the man pages for gimprc, gimp-tool, and gimp-remote
don't mention the full and unabbreviated name and I will try to take a
close look at them later.


- Alan H.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] panel and winning splash

2004-12-13 Thread Alan Horkan

On Mon, 13 Dec 2004, Carol Spears wrote:

 Date: Mon, 13 Dec 2004 12:06:21 -0800
 From: Carol Spears [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED],
  GIMPDev [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] panel and winning splash

 On Mon, Dec 13, 2004 at 07:48:57PM +, Alan Horkan wrote:
 
  On Mon, 13 Dec 2004, Carol Spears wrote:
 
   i am waiting to hear what the panel decided for the winning splash.  Any
   word on this yet?
 
  It was decided that it was very important to get some input from artists
  namely Jimmac Tigert and drc.

 okay, so what was the reason to have a panel then?

they were asked for comments on a shortlist of choices.
they were not asked to make the final decision.

 looks like the best thing would have been to skip the panel

It is far too late now and the time for such comments has long passed, but
I'm sure lessons have been learned and future competitions will be run
differently.

- Alan



___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Why not allow the name to be configurable?

2004-12-13 Thread Alan Horkan

On Mon, 13 Dec 2004, Sven Neumann wrote:

 Date: Mon, 13 Dec 2004 21:26:37 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] Why not allow the name to be configurable?

 Hi Alan,

 didn't you say you would stop arguing on this stupid subject?

That was unnecessary.
What kind of reaction to you expect to a comment like that?

I thought I also said I wanted to reply to the other messages first (but I
perhaps I didn't).  I did not want to ignore the posts people had made,
as they might consider it rude.

I had planned to add your answers to the User FAQ which I thought existed
in Wiki, but according to the Developer FAQ there is no User FAQ.

Thank you again for taking the time to explain your reasons.

Now I'm really finished and wont make any further comments on the subject.

- Alan.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Why not allow the name to be configurable?

2004-12-13 Thread Alan Horkan

 Date: Sun, 12 Dec 2004 18:05:46 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer]  Why not allow the name to be configurable?

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  I have to ask why reject such patches?

 Because IMO the name is important. If we allow the name to be changed
 easily, our users will not any longer know what software they are
 using.

 Contributors will be lost because they will look for the Foo
 project instead of the GIMP project.

(Sven I know you understand what I'm saying but other do not seem to get
exactly what I'm asking)  To make myself as clear as I possibly can I'm
not asking for the project to change its name but to accept patches that
allow others to rebrand the gimp if they want.

 It would also make it way too easy for anyone who wants to make some
 quick money out of The GIMP.

This has happened already, people already package and sell the gimp
and their failure to provide adequate support has hurt the gimp brand.
If it was easier for them to rebrand it would be reasonable to expect
them to do so and make it clear that their product is not officially
endorsed by the gimp project.

(I'm referring to this widely reported incident of a Mac user who paid for
the gimp and got no service from the vendors and as a result was
excessively critical.   http://www.wpdfd.com/editorial/wpd0504review.htm )

 We must not allow people to change the name by means of a simple
 configure option and let them benefit from our hard work.

First of all thank you for providing a clear explanation.  If the issue
comes up again users wont be left in any doubt of how things stand and I
can direct them to your comments.  I will add this to the wiki, as I think
it has been asked enough to be considered a Frequently Asked Question.

Free Software already allows them to do exactly the kinds of changes you
would rather not allow people to make.  Despite the fact that it it might
happen anyway I can understand that you dont want to make it easy.

  You are in the lead developer in charge and can do anything you want
  and I certainly wouldn't expect you to make the changes but I'd feel
  a lot better if you gave a good reason to reject patches that would
  make it easier to get more people to use Free Software?

 I seriously doubt that the name is effectively keeping GIMP from being
 used. I am all happy to ignore the very few people who are so
 narrow-minded as to having a problem with the name.

I'd rather see more people use Free Software.

I'm disappointed that people here do not seem to understand or accept that
some people (and it seems only to be a small minority of native English
speakers in particular) have issue with the name and that their concersns
are being dismissed as as some sort of narrow minded political
correctness. I dont believe the complaints will go away but as you are
happy to ignore the complaints I'll accept that and when I've responded
to the messages in this thread I will try not to bring the issue up
again.

 If a project as big as Mozilla Firefox allows it name to be changed,
  why would it be an issue for the gimp?

 For Firefox having the name configurable is part of the business plan.
 I can't find any such note in the GIMP's business plan. Heck, I can't
 even find the plan.

I think it is a shame there is not a clear plan for the gimp and I think
it would be a very good thing if there was a plan and efforts made to
commericalise the gimp to allow developers like yourself (or others) to
get better rewarded for the work you do improving the gimp.

  Why require people to fork or maintain their own patchsets for the
  sake of a little extra configurability.

 So that it becomes harder for them to do this. And if they really
 think it's worth all the hassle, well, then they can do it.

I suppose it is reasonable to draw the line somewhere.

Thanks again for making a clear decision and explaining it.

Sincerely

Alan Horkan.
http://advogato.org/person/AlanHorkan/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Why not allow the name to be configurable? [was [Bug 160890] Change Gimp name (fwd)]

2004-12-13 Thread Alan Horkan

On Sun, 12 Dec 2004, Carol Spears wrote:

 Date: Sun, 12 Dec 2004 08:51:34 -0800
 From: Carol Spears [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED],
  GIMPDev [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] Why not allow the name to be configurable?
 [was [Bug 160890] Change Gimp name (fwd)]

 i have a question for you; you don't need to answer it to anyone but
 yourself.  what does the word gimp mean to you and where ever could you
 have come up with this meaning?

One of the meanings I associate with the the word gimp is lame or
crippled (it is a dictionary definition of the term).
http://dictionary.reference.com/search?q=gimp

the other you have already mentioned

 when i hear the word gimp, i get a chuckle from a media image that some
 pack of film geniuses inbedded into our collective language lately.

I must say the name doesn't bother me very much but I'm not the only one
who would prefer a differnt name, it was brought up recently on the user
mailing list, and a bug report was filed and I didn't see the harm in
allowing users to change the name if they really wanted to (and they still
can if they are the kind of person who knows how to compile their own
software, but that rules out most normal users).

 with this sort of cord: http://www.boondoggleman.com/what_is_it.htm

Until now I was totally unaware that the term gimp also had that meaning.
That idea could have been used to come up with a very interesting splash
screen but I don't think anyone picked up on the idea.

 i am becoming confusing again.  i am sorry.  let me try to sum it up
 this way:  what gives you the right to inflict your perversions on a
 group of developers like that?

If you look again I am not trying to inflict anything on anyone.
I do not apprecaite the implication that I'm perverted, if anything I
would prefer to have a neutral word that has none of those connotations.

Most importantly I was not asking for the project to change name and not
seeking to impose a new name on anyone else but merely asking why it was
would not be acceptable to make it easier for those who would like to
change the name for themselves.

 if you have a problem with the name, perhaps you should fix yourself.

The name doesn't stop me using the GNU Image Manipulation Program, but it
it is one more thing getting in the way of convincing other people to
try it.

 leave bugzilla for software problems.

I didn't file the bug report.  Please do take a look at it first and read
my other posts if you feel it is still necessary to reply to this message.

Sincerely

Alan Horkan.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Why not allow the name to be configurable? [was [Bug 160890] Change Gimp name (fwd)]

2004-12-12 Thread Alan Horkan

Some people have difficulty dealing with the connotations of the term The
GIMP.   I wont go into details again about why some people have issues
with the name, some even finding it offensive.

bug 168090 suggests a name change
(and it seems to be the first time anyone has wanted this enough to file a
bug report about it)

I don't think it is a good idea to change the project name.  (CC'ing the
gimp-user list as the issue was recently brought up there already.)
It is a good sign that the gimp has improved so much that people are only
left with the name to complain about :)

I think it would be a fair compromise to accept patches that make it
easier for those who would like to configure the name.

Sven wrote:
Bugzilla is the wrong place for such a discussion. If you really want to
have it, please bring it up on the mailing-list.

Sven also wrote:
I am certainly not willing to accept patches that allow to configure the
name

I have to ask why reject such patches?

You are in the lead developer in charge and can do anything you want and I
certainly wouldn't expect you to make the changes but I'd feel a lot
better if you gave a good reason to reject patches that would make it
easier to get more people to use Free Software?

If a project as big as Mozilla Firefox allows it name to be changed, why
would it be an issue for the gimp?
Why require people to fork or maintain their own patchsets for the sake of
a little extra configurability.

Sincerely

Alan Horkan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: whishes for Gimp

2004-11-18 Thread Alan Horkan

On Thu, 18 Nov 2004, Juhana Sadeharju wrote:

 Date: Thu, 18 Nov 2004 13:21:49 +0200
 From: Juhana Sadeharju [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [Gimp-developer] Re: whishes for Gimp

 From: Sven Neumann [EMAIL PROTECTED]
 
 Adding more tools has the disadvantage of cluttering the toolbox.

 Just suggestions:

 Solution 1: everything goes to menu (tree) and each non-default
 menu item would have toggle which would append it to the toolbox.

The toolbox can already be customized, you can see for yourself if you try
one of the version 2.2 prereleases.
Go to
File, Dialogs, Tools,
and if you have an up to date version there will be an 'eye' icon next to
each tool allowing you to show/hide whatever tools you want.

Sven's point still stands though, adding more tools to the default toolbox
is not a great idea.

Sincerely

Alan Horkan

Free SVG Clip Art http://OpenClipArt.org
Abiword is Awesome http://abisource.com
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] comparing gimp speed

2004-11-16 Thread Alan Horkan

On Tue, 16 Nov 2004, Sven Neumann wrote:

 Date: Tue, 16 Nov 2004 12:07:31 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] comparing gimp speed

 Hi,

 while we are discussing this. Would anyone object if we changed the
 default tile cache size from 64MB to 128MB? Memory is becoming cheap
 these days and IMO it is reasonable to adapt the default value from
 time to time.

Would it be difficult to query the operating system and to automatically
set the tile cache size to some percentage (50%?) of available RAM?

Increasing the default size sounds sensible given that even most low end
computers come with at least 256MB of RAM.  I dont know about other linux
distributions but the Memory recommendations for Fedora 2 are as follows:
  Minimum for graphical: 192MB
  Recommended for graphical: 256MB
http://fedora.redhat.com/docs/release-notes/fc2/x86/

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


new gfig [Re: [Gimp-developer] canvas background options]

2004-11-14 Thread Alan Horkan

On Sun, 14 Nov 2004, Sven Neumann wrote:

 Date: Sun, 14 Nov 2004 00:31:13 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  I was unable to get to use the gimp 2.1 series until recently.  I
  cannot provide feedback only when it suits your timetable.  When I
  pointed out problems with 2.0 you gave out to me for not mentioning
  them during the 1.3 cycle so I am making my points before 2.2 is
  released.

 A couple of days before 2.2 is released and a long time after the
 feature set and the user interface has been frozen. Not a very good
 timing. But of course we are always open for suggestions.

 Even though it seems rather useless, let me point you to bug #142996

Thank you that is intersting and helpful, I had not seen that report
before.  I didn't realise there was a context menu on the old button.  I
never would have accidentally discovered context menu with such a tiny
context target area.

  (I really hope Gfig will be rolled back as the developer working on
  it has previously suggested, it is definately not ready for 2.2)

 We have another developer working on it at the moment and he's
 contributing his free time for the task of finishing the changes to
 GFig that Bill started. This comment of yours (and you did the same
 comment on gnomedesktop.org) is discouraging, nothing else. Please try
 to avoid this in the future.

It might help you to understand my negativity when I explain that the
underlying instability of windows doesn't do the gimp any favours.  When
binaries are available windows is the easiest platform to test on and in a
way the instability of the platform is actually helpful for testing.  I
have tried to compile the gimp serveral times during 2.1 but rather than
asking even more questions here and needing to chase down and compile lots
of little dependancies and parts of the toolchain I dont have I waited
for more releases to try again (until eventually there was a windows
binary I could test with).

My comments [1] were very restrained, I did say it had potential.  The new
SDI application style inteface for Gfig will be very good as it is an
easier way to present all the features that Gfig managed to cram into the
old dialog style of interface.  The Gfig had crashed several times
(reproducably and in different places) and if I recall correctly it
crashed badly enough to take the rest of the gimp down with it.  Feedback
takes time, and I haven't gotten around to checking if the problems are
known issues or writing a detailed explaination of how to reproduce them
or otherwise tracking them down.  I have started to David Odin offlist
about it further.

- Alan H.


[1] The new Gfig is definately is a bit rough around the edges. It has a
lot of potential though. It really should be reverted to the old usuable
ugly but stable version for the 2.2 release.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: new gfig [Re: [Gimp-developer] canvas background options]

2004-11-14 Thread Alan Horkan

On Sun, 14 Nov 2004, David Odin wrote:

 Date: Sun, 14 Nov 2004 21:28:44 +0100
 From: David Odin [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: new gfig   [Re: [Gimp-developer] canvas background options]

 On Sun, Nov 14, 2004 at 07:13:32PM +, Alan Horkan wrote:
 
  It might help you to understand my negativity when I explain that the
  underlying instability of windows doesn't do the gimp any favours.  When
  binaries are available windows is the easiest platform to test on and in a
  way the instability of the platform is actually helpful for testing.  I
  have tried to compile the gimp serveral times during 2.1 but rather than
  asking even more questions here and needing to chase down and compile lots
  of little dependancies and parts of the toolchain I dont have I waited
  for more releases to try again (until eventually there was a windows
  binary I could test with).
 
   So, you're telling us you haven't yet tried the current cvs version of
 gfig, yet asking us to use the 2.0 one?

I have tried the version in gimp 2.2 pre1

   I haven't seen any bug-report for this.  I'm am aware of some bugs in
 gfig and I have told the mailing list about them.  May be you could take
 the time to check if your crashes and mines are related?

I will try, but I only have a working copy of gimp 2.2 pre1 on my home
machine.

   One bug is very easy to trigger: draw a line, erase it, draw another
 line.  Don't tell me this takes too much time to check.

Working at home, verify the bug reoccurs and bringing it takes time.  I
use the computers available to me and they dont lend themselves to keeping
up to date and I've never had much luck compiling the gimp from CVS (but
that is just me, I'm not claiming it is difficult if you know what you are
doing, have admin rights on your machine and a fast internet connection).

I'll try and look at a CVS version of gfig this week, but it is painfully
difficult for me to get this organised.

   new gfig has some issues and I've tried to list them on this very
 mailing-list.  If you can list more, please list them in the correct
 thread.

Will do.

   and as I already said before, using the 2.0 version of gfig would mean
 to at least port the old version to the HIG standards,

I was suggesting shipping the old unmodified version because it was more
stable.

To be nominally HIG compliant would require some adjustment of the old
dialog.  To meet the spirit of the HIG and provide a more user friendly
does require the valuable work you are doing.

If gfig is not frozen and will be shipping a more stable and up to date
version than was in gimp 2.2 pre1 then that would be a different matter
entirely.  I would much prefer to see your version (with a few
improvements) to be the one included when gimp 2.2 is released.

- Alan H.


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-13 Thread Alan Horkan

On Fri, 12 Nov 2004, Sven Neumann wrote:

 Date: Fri, 12 Nov 2004 23:42:42 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  'Useless discussion'.
 
  Thanks for the encouragement, with that attitude is it any wonder more
  people dont try and provide feedback and try and improve the gimp.

 Alan, the discussion became useless after the facts had been exchanged
 and several people explained you that the feature is indeed useful.
 That makes further discussions on this topic rather useless.

I am still hoping to get more information on how the feature is actually
use to try to better solve the problem rather than dwell on the
implementation any further.

I was unable to get to use the gimp 2.1 series until recently.  I cannot
provide feedback only when it suits your timetable.  When I pointed out
problems with 2.0 you gave out to me for not mentioning them during the
1.3 cycle so I am making my points before 2.2 is released.

 Especially during times of string and UI freeze.

All that means it that no changes will be made until after that freeze,
not that changes shouldn't be suggested.

(I really hope Gfig will be rolled back as the developer working on it has
previously suggested, it is definately not ready for 2.2)

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-13 Thread Alan Horkan

On Sat, 13 Nov 2004, Simon Budig wrote:

 Date: Sat, 13 Nov 2004 00:41:18 +0100
 From: Simon Budig [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 Hi all.

 Alan Horkan ([EMAIL PROTECTED]) wrote:
  On Fri, 12 Nov 2004, Sven Neumann wrote:
   Alan Horkan [EMAIL PROTECTED] writes:
Given my previous comments that is understandable and I think
discoverability is important but it doesn't make sense to have a
seperate menu item for every obscure feature and to me this is
most definately an obscure feature.
  
   It has been requested over and over again so there are certainly
   people who see a need for it.
 
  I never claimed some people wouldn't find it useful.

 You did however harp on the uselessness of this feature and advocate its
 removal. Despite numerous people supporting it. Just because you don't
 see the use of this feature that doesn't mean that it has none.

In hindsight I should have been more diplomatic, and I repeated the
comment excessively.

Perhaps I might have been less quick to complain if it had been only
one menu item that shows a dialog but it is not, it is a submenu
with several menu items and that seems a lot like clutter to me.
  
   It is a submenu, so it is only a single menu entry
 
  i dont follow that logic

 Simple: If a menu entry pops up a dialog or if a menu entry pops up a
 submenu is irrelevant for the menu itself. It is exactly one menu entry
 in the menu. It doesn't clutter less or more than a dialog.

My counterpoint is that even though a submenu means only one extra
menu in the parent menu it means another level and more items to
search through.  It doesn't make the specific feature any more
difficutl to use but more menu items overall can complicate the task of
finding anything.

  I'm not trying very hard to find it, finding problems is relatively easy
  finding solutions and finding the time to provide feedback in way you will
  actually listen to is what is time consuming.

 From my point of view the most things brought up by you are details.
 While I like attention to the detail I don't like that these things tend
 to need lots of discussion. The issue here is a perfect example:
 Configurability of the border color. This discussion should have been
 over when everybody except you agreed that it is useful. Suddenly about
 14 Mails pop up, 5 of these by you not understanding the point of the
 others. This does not help.

As we had started I had hoped to finish and move some way towards
improving the feature for those who want it and possibly making it less
obtrusive.  If the task is to compare an image with a Black Background, a
white Background and a Blue background, changing it one at time would be
slower than firing off a script that made copies and added a border in a
selection of colours (that is just a possible scenario, maybe there is no
room for improvement but if I'm not allowed to discuss it I'll never
find out).

I'll try and show more restraint and not drag out discussions longer in
future, I admit I got a little carried away.  In other mailing lists
normally only those interested in the thread would keep reading and
responding to it.

- Alan H.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Alan Horkan

On Fri, 12 Nov 2004, David Odin wrote:

 Date: Fri, 12 Nov 2004 01:02:31 +0100
 From: David Odin [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 On Thu, Nov 11, 2004 at 11:06:21PM +, Alan Horkan wrote:
 
  I noticed the Canvas background colour options under the Image menu in the
  gimp 2.2.
 
  In gimp 2.0 this option was fairly discrete and was available on the top
  right just above the scrollbar which seemed fair enough even if it was
  not something I would ever change (except perhaps by changing my desktop
  theme).
 
  Is this feature really important to some users, so much so that it needs
  menu items?  I am suggesting it would be better to put this in the
  preferences if at all rather than cluttering the menus.
 
   Yes, this feature is important to me at least.  It is important to
 have a dark surrounding around a dark image and a light one around a
 light image, so you can judge the contrast better.

I can understand how that would require you to change it regularly and why
you might want a menu item for it.
How did you like how the feature was presented in 2.0 or were you unaware
of it until it was given a prominant menu item?

- Alan H.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Alan Horkan

On Fri, 12 Nov 2004, Sven Neumann wrote:

 Date: Fri, 12 Nov 2004 15:39:58 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  I can understand how that would require you to change it regularly
  and why you might want a menu item for it.  How did you like how the
  feature was presented in 2.0 or were you unaware of it until it was
  given a prominant menu item?

 Hiding useful functionality in some obscure button with a right-click
 popup menu in the image corner is not really good user interface
 design and I am very much surprised that you don't consider this
 change an improvement.

Given my previous comments that is understandable and I think
discoverability is important but it doesn't make sense to have a seperate
menu item for every obscure feature and to me this is most definately an
obscure feature.  (most of the time I shrink wrap my images and dont even
see the canvas padding, if I wanted to regularly preview images against a
black background I would probably configure the Fullscreen mode for that
purpose)

Perhaps I might have been less quick to complain if it had been only one
menu item that shows a dialog but it is not, it is a submenu with several
menu items and that seems a lot like clutter to me.

 We also needed that space in the upper right corner for a more useful
 and less obscure feature that is also being offered in other
 applications: linking the image zoom ratio to the window size.

That does seem like a good idea of itself but I dont think it makes the
menu items for Canvas Padding idea any better than a workaround.

I'm surprised that enough users would be changing the setting often enough
to want to be able to set it on a once off per window basis, I would have
though that a single global preference would to override the toolkit
default would have been enough (which is as far as I can go towards
offering an alternative implementation).

Sincerely

Alan Horkan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Alan Horkan

On Fri, 12 Nov 2004, Jakub Friedl (lists) wrote:

 Date: Fri, 12 Nov 2004 16:57:51 +0100
 From: Jakub Friedl (lists) [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED],
  GDev [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

  I'm surprised that enough users would be changing the setting often enough
  to want to be able to set it on a once off per window basis, I would have
  though that a single global preference would to override the toolkit
  default would have been enough

 oh please no. or is the gimp supposed to be used only by beginners and
 not by advanced users?

That line of reasoning can be used to justify adding a whole lot of crud
to the gimp that only really benefits the advanced users.  if anything
recent development has been removing little used plugins to reduce the
maintainance burden.

the gimp is the de facto standard for image editing on Linux, FreeBSD,
Solaris, and I'm sure a few others.  I there hardly any other piece of
graphics software as likely to be available as the gimp.

As such is extremely important to cater to ordinary users.

I don't want to make the gimp into something that advanced users cannot
use quickly and efficiently either, but an uncluttered streamlined user
interface should be of benefit to everyone.

I wish you would have resited the urge to overreact, all this is just
dicussion and although I would prefer not to have the Canvas Padding
feature I do not think my suggestions have yet been convincing enough.

 a month ago i was making three images to be placed on a wall, each of
 them on different one, painted with different colour. i was painting
 them at the same time (they were a series)
 and i enjoyed the possibilty to see them all against the proper colour.

I'm still convinced it is a minority feature and although it may be useful
I'm not convinced it is useful enough for most users to deserve such
prominant location in the menus.

Gimp 2.2 seems to be largely decided, and it is unlikely that my
suggestion would be taken on board until after 2.2 has been released.

 BTW: if you feel that the gimp should be simplified as possible for
 beginners,

I believe it should be simplified for everyone, most usability
improvements are optimisation of a different kind and just as
accessibility benifts more than just the disabled so too should good
usability benfit everyone.

I'm not arrogant enough to claim I'm an expert, but I thought I should be
able to discuss the change before 2.2 and if I didn't do it now I'd
probably be berated for not having mentioned it sooner.

 wouldnt be possible to keep advanced features visible for advanced users
 but not for beginners? but not remove them completelly? single option in
 preferences (or in gimprc file) which would enable more advanced
 features which some consider as interface clutter but others may need
 them?

Did you use Nautilus when it had a Normal mode and an Advanced mode?
It was a disaster because most users wanted one or two of the supposedly
Advanced features which meant turing on a whole lot of other advanced
features.

It is better to think of the task and the results you are trying to
achieve and see if there is a way to stream line the process.

I do not doubt that it is useful for you to have a way to easily compare
your image against various backgrounds.

What I am asking is if the current implementation is really the best way
to provide that feature?

You have made it clear that you want to be able to set a different
background colour for each image.  Do you set different colours for
different views of the same image?

If so might it not be beter even better to reorganise this functionality
in a way that allowed you to more quickly preview an image with various
different background rather than having to choose a different back colour
each time you wanted to make your comparisions.

If you describe in more detail how exactly you go about your work I might
be able to refine my suggestions.

I'm trying to make things easier for _everyone_ including you :)

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Alan Horkan

On Fri, 12 Nov 2004, Sven Neumann wrote:

 Date: Fri, 12 Nov 2004 18:49:26 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  Given my previous comments that is understandable and I think
  discoverability is important but it doesn't make sense to have a seperate
  menu item for every obscure feature and to me this is most definately an
  obscure feature.

 It has been requested over and over again so there are certainly
 people who see a need for it.

I never claimed some people wouldn't find it useful.

  Perhaps I might have been less quick to complain if it had been only
  one menu item that shows a dialog but it is not, it is a submenu
  with several menu items and that seems a lot like clutter to me.

 It is a submenu, so it is only a single menu entry

i dont follow that logic

 and thus certainly not clutter. It would have been clutter to use a
 dialog for something that can be easily done using a small submenu.

i think a small dialog with all the options in one place would not be any
worse than the current setup

 Can we please stop this useless discussion here?

'Useless discussion'.

Thanks for the encouragement, with that attitude is it any wonder more
people dont try and provide feedback and try and improve the gimp.

And you don't seem to understand why I think you are rude and abrupt.

 I get the impression that you are trying very hard to find something to
 criticise.

I'm not trying very hard to find it, finding problems is relatively easy
finding solutions and finding the time to provide feedback in way you will
actually listen to is what is time consuming.  There is plenty of room for
improvement as the long list of bug reports in bugzilla will attest to, as
the numerous FIXME in the PDB Browser and the TODO in the code.  If more
developers were to use other graphics software like Adobe Photoshop or
Paint Shop Pro you would see there is even more ways that the gimp could
be could be improved.

What am trying hard to do is discuss ideas and find ways to improve things
but you seem unwilling to tolerate polite and resonable discussion,
perhaps you expect ideas to come out of nowhere fully formed or
implementations to be just right first time.

 Why do you have to show so much disrespect for other people's work?

Why are you so resistant to discussion?
Why are you so willing to dismiss criticisms instead of trying harder to
see if things really can be improved?

It is not disrespect to think that things can be improved.
If I had no respect I would give up entirely and would not make any effort
to use the gimp or provide feedback and try and improve it.

- Alan H.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Offtopic] Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...

2004-11-11 Thread Alan Horkan
 purge from our minds the the idea of
getting them to switch and to instead hope that the gimp can become
another useful tool in their paintbox.

 Also - anyone have an address for the Inkscape-devel and Sodipodi-devel
 lists? I've been trying to test these and contribute also but havent

This is probably considered offtopic and I'm more than a little surprised
you were unable to find the answer on your own.  Given that you know the
lists are called inkscape-devel and sodipodi-devel you might have even
been able to guess that they were @lists.sourceforge.net

Alternatively the Inkscacpe Website http://inkscape.org/ inlcudes a link
to the mailing lists on the left sidebar about 11 items down,
http://inkscape.org/mailing_lists.php
and the subscription page for the Inkscape developer mailing list is here
http://lists.sourceforge.net/lists/listinfo/inkscape-devel

The layout of the Sodipodi website is a little more confusing, there is a
link to the mailng lists from the Developement page and probably other
places too
http://sourceforge.net/mail/?group_id=4054

 found the lists yet. Inkscape is impressive, but could do with some 'eye
 candy' - thats another important factor for designers, we're competing

I thought the screenshots and tutorials were a good start when it comes to
eye candy http://inkscape.org/screenshots/index.php and the
OpenClipart.org project includes many examples of what Inkscape (and
Sodipodi and other SVG software) can achieve but maybe I'm being overly
generous.

 with the Windows and Mac toolkits, and frankly GTK looks pretty darn
 strange and ugly to a designer - it'll put them off using a really good

You would probably be more forgiving of GTK if you were using it on Linux
and were taking advantage of themes.

 tool. Inkscape on the whole did what i wanted when i learnt how it
 'thought', but wouldnt open and reopen from Illustrator. I'd very much
 like to report these experiences to their list and see how they are
 tackling them.

The Inkscape developers would definately like to hear your opinions and
are willing to ajust things to accomdate Illustrator users (up to a point)
as things are being changed around a lot at the moment that means there is
both room for flexibility and it also means that it is essentail that you
make sure to try a fully up-to-date Nightly build.

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...

2004-11-11 Thread Alan Horkan


Miriam

 okay... since i'm in the Hotel California where you can check in but
 never check out

Sorry that the you were unable to unsubscribe, I have no idea why the
unsubscribe system didn't work for you but I'm pretty sure the developers
were joking and that if you are still unable to unsubscribe having done
your best to try the various methods available that they would be willing
to take you off the list but I hope you will volutarily stick around a
little longer.

 Is it possible to design a GUI implementation of the same script? The
 Select-To sounds good but its gotta be a short menu - preferably within
 the Brush palette itself... thats where we'd think to look for it...

I'm not sure you realise there already is a script under
Script-Fu/Selection/To Brush...

which will take the contents of the current selection, ask you to give
it a name and then save it to the brushes folder.

 Script-Fu is totally incomprehensible to graphic designers

Not just graphic designers :)

Scheme is an 'interesting' programming language but it sort of has its
charms if and when you can eventually figure it out.
I'd still like an automatic script recorder though.

- Alan H.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...

2004-11-11 Thread Alan Horkan

On Thu, 11 Nov 2004, David Neary wrote:

 Date: Thu, 11 Nov 2004 21:36:18 +0100
 From: David Neary [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] Selection to brush/pattern/whatever in
 menus...

 Hi,

 Alan Horkan wrote:
  On Thu, 11 Nov 2004, David Neary wrote:
   It should also (IMHO) work on images and not just drawables,
   proposing a flatten if necessary. Every time I have used
   selection to brush so far, the selection was created with select
   all.
 
  I'd rather not add a flatten option (or 'work on copy'), I think it is
  better to use the built in functionality where possible rather than
  complicating each script.  Image Duplicate and Flatten Image work well and
  they both deserve shortcuts (I dont recall what the defaults are if any as
  I mostly use the Photoshop shortcuts).

 I meant as an export operation. In general, if you pass a file to
 a save operation that it doesn't support, it proposes an export
 operation to convert to a format supported (like saving an RGB
 image as gif, for example). I'm not sure how that's done, but I
 imagine that it's mostly in the core.

Apologies.
That makes a lot more sense.

However in gimp 2.0 if you use File, 'Save as', then choose Gimp
Brush (.gbr) and if your image contains multiple layers you are already
asked to Export and advised to flatten the image.
Perhaps I'm still misunderstanding you.

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Dialog layouts in 2.2pre1

2004-11-05 Thread Alan Horkan

 Date: Fri, 05 Nov 2004 17:00:30 +
 From: Keith Goatman [EMAIL PROTECTED]
 Cc: gimp-devel [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] Dialog layouts in 2.2pre1

 Sven Neumann wrote:
  Despite the fact that it has a sane API (which the old widgets didn't
  have), it also has a number of useability improvements like bookmarks,
  mime-type icons and the ability to mount volumes. It also features a
  Win32 backend and in the future it will allow GIMP to work on remote
  files (if we figure out how to use gnome-vfs w/o pulling in too many
  dependencies). It is also expected that Search capabilities will be
  added in the future (see
  http://primates.ximian.com/~federico/docs/file-chooser-extension-spec/)
 
  If you are missing keyboard navigation in the file chooser, you might
  want to try a recent GTK+ development snapshot. There have been some
  improvements in that area.

It really is a lot more bearable if you can get a more recent version of
the file chooser with type ahead find.

The changes are good in a variety of ways but unfortunately for old users
it is better in very different ways from what worked well in the old
dialog, it is six of one half a dozen of the other.
On the upside the API and infrastructure has been cleaned up so there is
room for modifications and improvements and it is being worked on.

 Yes all the features you mention above are technically very nice, and
 make it more in line with the standard windows file dialog.  However, at
 the moment it is just plain annoying because it takes longer to select
 the file I want.  Since this is a common task it makes using the new
 version frustrating to use when I don't dnd from my browser.  I will try
 the latest GTK development snapshot to see if it's any better.

It is a secret conspiracy to kill off the file chooser and make everyone
use Drag and Drop and open files using the file manager!!!
(Believe it or not I'm actually half serious about this)

- Alan H.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Do what I mean [was RE: [Gimp-developer] first impressions of GIMP 2.0]

2004-10-31 Thread Alan Horkan

On Wed, 27 Oct 2004, Austin Donnelly wrote:

 Date: Wed, 27 Oct 2004 09:23:32 +0100
 From: Austin Donnelly [EMAIL PROTECTED]
 To: 'Sven Neumann' [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: RE: [Gimp-developer] first impressions of GIMP 2.0

 [Adding a layer mask]
   Huh? Go to the Layers menu, choose Add Layer Mask. Also available
   from the right-click menu in the Layers dialog.
 
   I couldnt actually access this - it was greyed out completely.
 
  You can't add a layer mask to a layer that doesn't have an alpha
  channel.

 Hmm - perhaps the best interface here would be to always have the Add Layer
 Mask menu option available, but if there's no alpha channel then popup a
 dialog saying something like Adding a layer mask requires the image to have
 an alpha channel.  Would you like me to add one? Yes: / No (default yes,
 tickbox (unchecked) for don't ask me again).

 This is similar in spirit to the file export dialogs that automatically
 convert your image into something the file save plugin can handle (ie
 flatten etc).  It's the DWIM (Do What I Mean) school of UI design, where you
 try and guess what the user is actually trying to do :)


Austin, thanks for filing the bug report and
thanks Sven for fixing it so quickly.
http://bugzilla.gnome.org/show_bug.cgi?id=156676

I was hoping you would file more general bug report to capture the idea
you mentioned of Do what I mean (I cannot think of any other way to
describe it, sorry) and see if there were other areas where similar
problems were occuring.  There might be other areas were it would be
better to do something rather than do nothing.

There is a case that I think is similar: if you are moving a layer down
the stack and the background layer has no alpha channel you get the
message
Layer 'Background' has no Alpha.  Layer was placed above it.  [ OK ]

the way I see it there are a few possible improvements
1) just add the Alpha Channel as in bug 156676
2) dont use a message dialog, explain using a less obtrusive status bar
message
3) change from a message to a dialog something like this

Layer 'Background' has no Alpha.  Would you like to Add Alpha?
[ Close ] [ Add Alpha]

I looked at a few other greyed out menu items that could potentially be
reenabled:
Select Invert when there is no selection;
Engrave plug-in seems to be disabled on layers that do not have an
alpha channel.

Maybe there is not any need to create a tracker bug for these loosely
related idea but should I file bug reports or try and group these and
others together as part of one big idea?

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] directory organisation [was Re: [Gimp-user] Installing plug-ins (fwd)]

2004-10-28 Thread Alan Horkan

One thing I have always admired about the gimp is the logical organisation
of its files on disk.
Unlike most other programs the gimp developers had the foresight to create
a sensible directory structure
/usr/share/gimp
/usr/share/gimp/2.0
/usr/share/gimp/2.2

whereas most applications are less sensibly organised and create files
like
/usr/share/appname
/usr/share/appname2
/usr/share/appname3

The message below from the user list reminded me and I was wondering Would
it be possible to continue this elegent and logical organistion sense to
the same for files in the user home directory and in future have something
like this?
~/.gimp/2.2
~/.gimp/3.0

(I'll file a bug report and try and make a patch if this idea is deemed
acceptable)

Sincerely

Alan Horkan

-- Forwarded message --
Date: Tue, 26 Oct 2004 15:14:22 +0200
From: Sven Neumann [EMAIL PROTECTED]
To: Carol Spears [EMAIL PROTECTED]
Cc: GIMPUser [EMAIL PROTECTED]
Subject: Re: [Gimp-user] Installing plug-ins

Hi,

Carol Spears [EMAIL PROTECTED] writes:

 actually, i was wrong.  the cvs version of gimp is now installing
 things into ~/.gimp-2.0/ i guess until the plug-ins catch up with
 the version numbers.

GIMP 2.2 will be using the ~/.gimp-2.2 directory.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] first impressions of GIMP 2.0

2004-10-26 Thread Alan Horkan

On Mon, 25 Oct 2004, Gezim Hoxha wrote:

 Date: Mon, 25 Oct 2004 13:36:47 -0700 (PDT)
 From: Gezim Hoxha [EMAIL PROTECTED]
 To: [EMAIL PROTECTED], gimp dev [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] first impressions of GIMP 2.0

 One of the tools that I absolutely love is the
 dynamic shortcut tool. If you set this in the
 preferences, then go to one menu highlight a tool then
 just press a letter, this letter will become the new
 shortcut of the tool and it's sweet :) (I should say
 that it took a while to discover this nice thing).

 And I haven't really used photoshop since 5.5 and the
 other day I see this guy makes a selection and then
 the selection gets some handles on it...he just drags
 the handles and makes it how big he wants it to
 bethat was really amazing to see, had never seen
 it before...so if gimp were to implement this I would
 love it.

Try the scale tool in the toolbox, it allows you to do something very
close to what you are describing.  (In Gimp 2 it is between the rotate
tool and the shear tool, I find the icons confusingly similar but look
carefully and you will see it is available).

- Alan H.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] gimp GUI

2004-10-25 Thread Alan Horkan
 below the layer menu. A
 navigator screen should be in place always - this is a feature I find
 essential, and makes it impossible for me to use the GIMP - while i can
 zoom in and out, its very difficult to drag the screen around to the
 place where I want to work.

if you have a wheel mouse or three button mouse you can middle click and
drag/pan (although I still wish I could use Page Up and Page Down to
navigate the page).

if you like how Adobe Photoshop does things you should definately take a
look at the psmenurc which is a settings file to give the gimp
keybindings similar to photoshop.

there is also an excellent plugin called pspi by Tor Lillqvist which
allows you to use (some) Photoshop plugins with the gimp.

 As for Illustrator / Fireworks / Dreamweaver / Flash: (my own
 'essential' tools)

 Illustrator is a print design tool, on the level of GIMP. At the moment

Try Inkscape, http://inkscape.org
for print work people seem to be combining it with Scribus (Desktop
Publishing Software)
http://www.scribus.net/

 Fireworks is a vector design tool.

Although Fireworks acts very much like a vector design tool as it part of
the family of Macromedia products but it claims to be Raster graphics.
Perhaps you meant Freehand which is the Vector graphics tool from
Macromedia which is equivalent to Adobe Illustrator and seems to be
competing quite successfully.

 an optimising screen for jpeg/gif (ewww, but essential). Fireworks
 allows you to slice the image and export the slices to HTML or simply to

there are some slice tools for the gimp, the first thing you should try is
adding some guides and choosing Image, Transform, Guillotine but there
are more ways.

 Flash is an absolute essential - we have no tools at all at present for
 animation. Flash uses vector graphics as well as being able to import

There are some open source Flash tools available if you look hard enough
but few are advanced enough to be included with most Linux distributions
and you will very likely need to compile them for yourself if you want to
try them out.

Macromedia did eventually make Flash a freely available standard that
others can implement (but which they control) but open source tools have
not caught up in that area yet but some people are certainly trying.

 Personally speaking, I'm just sad that I can't use Free software for my
 design work, and would love to be able to migrate entirely to GNU/Linux.

If you are determined Wine might be an option to ease the migration
http://winehq.com/
or if you have money you might buy VMWARE to run windows inside Linux.

 A thought - the older SGI IRIX O/S had many of these tools - perhaps
 free ports of these may be easier to implement. 3D design is nicely
 taken care of by Blender, which has become an essential on Winblows
 machines also.

I'm surprised you have not mentioned Mac OS X which has much of the tools
that graphic designers and desktop publishers love and has versions of
free software like the gimp available for it (although not as perfectly
beautiful native applications).

 Hope this is of some help at least... I'll get back to you with more
 details, and feel free to ask.

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: New Image dialog usability bug

2004-09-14 Thread Alan Horkan

On Mon, 13 Sep 2004, Danni Coy wrote:

 Date: Mon, 13 Sep 2004 22:36:07 +1000
 From: Danni Coy [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [Gimp-developer] Re: New Image dialog usability bug

 Why not have the entries for size have drop down menus allowing the user to
 select the last 8 or so amounts entered.

That might work but it would clutter the dialog and you could just use
templates instead.

- Alan

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] on splitting things off

2004-09-09 Thread Alan Horkan

On Wed, 8 Sep 2004, Carol Spears wrote:

 Date: Wed, 8 Sep 2004 18:02:16 -0700
 From: Carol Spears [EMAIL PROTECTED]
 To: David Neary [EMAIL PROTECTED],
  GIMPDev [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] on splitting things off

 hello,


 my experience with gimp is different than dave neary is talking about.
 he is saying that if you dont get everything at one time, you will not
 get it.  when i first started to use gimp, it was so much fun to go
 online and shop (for lack of a better term) for new and fun things for
 gimp that were on several different web sites -- each with its own
 personality.  much more the pleasure when i got to meet those web site
 owners later online and even more in real life this year.

 gimp-perl gets installed now by debian for gimp-2.0 and i tried to
 install it for gimp-2.1.

 people who want gimp-python will go and install it.

When using the University computers I'm pretty much stuck with what the
systems adminstrator installs and they is almost always only the defaults.

Most users will rate the gimp based on what it includes by default.
If something is not there by default is missing.

I can understand that some people relish hunting for all sorts of
different add-ons (sometimes I feel like doing that too) but I dont think
most people do.

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] split GIMP into even more packages

2004-09-08 Thread Alan Horkan

On Wed, 8 Sep 2004, Sven Neumann wrote:

snip

 to be clobbered with more stuff simply because we are too lazy to add
 some simple notes to our web-site and FTP server. In the long run we
 will want to split GIMP into even more packages.

Slimming down the core by moving things out to other packages is very
sensible.  It keeps the core smaller and easier to build without having
any significant impact on users, so long as packagers are smart about it.
(On a side note, I really dont like Firefox because they threw out some
many little bits I actually liked without rolling them out as a package of
plug-ins, which is a mistake I am very glad the gimp has avoided.
Adding back in the bits you like - if they are even availabe as plugins -
is far less convienent than sticking with Mozilla.)


Do you foresee a gimp-plugins package?

gimpressionist (and its nonstandard data files), gfig, and imagemap add a
quite lot bulk to the gimp and I would think of as prime candidates to be
rolled out to such a package.

I dont ever expect to be using Dicom (a medical file format) but I dont
think getting rid of it would necessarily be a good idea either.  The way
I see it at a minimum gimp core would only really need XCF PNG and JPEG
(I'd immediately add in PSD but I think that is probably just me).

Is this remotely like what you have in mind because I would be
interested to hear more.

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.

2004-09-08 Thread Alan Horkan

 On another note, I'm not sure this is a desirable goal. splitting
 stuff off feels an awful lot like putting it out to pasture. The

that does seem like a valid risk to consider

 goal of just having the core application, with no plug-ins, no
 image data structures, no scripts, and a minimum number of brushes,
 patterns and gradients doesn't seem to be the direction that
 people want to see the GIMP taking, from what I can tell.

I think a lot more of the patterns really should be moved to
gimp-data-extras (there are three different types of wood included in the
basic patterns, one should really be enough in the base) so that those who
want less will have less and those who want more will realise that they
should install gimp-data-extras and get a lot more.

 People would like more brushes, more patterns, more gradients, with
 the ability to delete the ones they don't use/like, and more
 scripts/plug-ins with a way to organise the menus according to
 the ones they use most often.

I do think users want this but I do not think users care how it is
achieved.

Things can be split into seperate packages but the real problem occurs
when distributions do not fully realise the intention was only to
modularlize not to remove the features and that they should install it
_all_ unless they have a really good reason for doing otherwise.

Some of us are at the mercy of systems adminstrators who install only the
default packages.

 I know that you believe that we should work on the core
 application and a few plug-ins, and leave most of the plug-in
 development to 3rd party plug-in maintainers, I'm not sure I
 agree. I think that we should be almost promiscuous in what we
 accept into CVS, but equally vicious in removing things from CVS
 when they become unmaintaned. I think that most people don't want
 to have to install several packages, they want to install the
 GIMP, and automatically get plug-ins like gap, refocus, and even
 DBP.

I would like to think that all these things would be installed by defualt
on most distributions, that the users would have to specifically opt out
if they didn't want the extras (and distributions like Knoppix would have
to strike a careful balance on what they leave out)

 Note that I'm not saying that all this should happen for 2.2, but
 I am speaking to the general goal of a lean, mean GIMPing machine
 versus an application which comes with everything including the
 kitchen sink, which you can modify to your own usage patterns,
 buut which has sufficiently sane defaults as to not have a huge
 complicated menu structure at the same time.

Maybe I'm foolishly optomistic to think that we could have both a small
seperable core but have everything and the kitchen sink nicely packaged
so that the developers can get on with things with the minimum of fuss and
users can still have it all.

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.

2004-09-07 Thread Alan Horkan

 Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit
 (ie. with translations) if it isn't fully ready yet by exposing it to
 more users but what is in the best interest of GIMP and its users?

I know I'd much prefer another stable release with Script-Fu in it first,
but that is my entirely subjective opinion.

I fear having to rewrite some of my scripts having already written gimp
1.2 and gimp 2.0 versions.  Compatibility is important to me, even if only
small changes are necessary it causes problems.  I dont relish the
prospect of new scripts I write not being usable by people who still have
gimp 2.0.x or even 1.2, users are still requesting backports of scripts to
1.2.  It may seem like Gimp 2 has been available for ages, particularly
for those who have been using gimp 1.3 but Gimp 2.0 was only released this
summer.

That said I'll certainly hope to instal Tiny-Fu alongside Script-Fu and
sort things out after 2.2.

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Re: script-fu gimp-flip problems? procedural database execution failed

2004-08-11 Thread Alan Horkan

On Tue, 10 Aug 2004, Alan Horkan wrote:

 Date: Tue, 10 Aug 2004 22:26:39 +0100 (BST)
 From: Alan Horkan [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: script-fu gimp-flip problems? procedural database execution
 failed


 I'm trying to port a script from gimp 1.2 to gimp 2

here is the currently slightly broken gimp 2.0 version, you can find the
relevant part of the file by searching for gimp-flip and it is clearly
marked by cursing in block caps which some may find offensive
http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/pattern-swirly.scm

and here is the perfectly working gimp 1.2 version
http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/gimp-1.2/pattern-swirly.scm

there is a commented out line
;(gimp-flip temp-drawable2 0)
as well as
(script-fu-transform temp-image temp-drawable2)

which is simply a wrapper for (gimp-flip drawable 0) because I was trying
various differnt things (invert, rotate, and I eventually decided on
flip).
I did try various combinations (gimp 1.3.x and gimp 2.0.x on windows).
I haven't yet tried gimp 2 on linux becuase I do not have a copy
conveniently available at the moment.

 everything else works fine except gimp-flip
 procedural database execution failed

 Any ideas?

thanks for the suggestion Simon.

Sincerely

Alan Horkan

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] script-fu gimp-flip problems? procedural database execution failed

2004-08-10 Thread Alan Horkan

I'm trying to port a script from gimp 1.2 to gimp 2

everything else works fine except gimp-flip
procedural database execution failed

i tried searching for an answer but the only remotely similar thing
suggested 'missing fonts' might be a problem

gimp-flip works fine in the script CoolMetal.  I cannot see what I'm doing
differently, my script worked fine in gimp 1.2.

gimp-flip is also in 3dTruchet but strangely commented out and didn't work
for me when I uncommented it (and drawable is mispelt on the same line).

(i think gimp-flip might have worked in truchet but i dont recall)

Any ideas?

- Alan

PS it is inconvenient for me provide the script right now but I'll be
submitting it soon anyway.  (it is a rewrite of swirly-pattern.scm).
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] preparing GIMP 2.2 (fwd)

2004-08-09 Thread Alan Horkan

Forwarding to the list in case others are interested

relevant to bug report
http://bugzilla.gnome.org/show_bug.cgi?id=145145

plan: moving patterns from Toolbox to the current image

-- Forwarded message --
Date: Mon, 9 Aug 2004 18:52:24 +0100 (BST)
From: Alan Horkan [EMAIL PROTECTED]
To: Sven Neumann [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] preparing GIMP 2.2


Status on my pattern changes, in case you are wondering

 This list doesn't include tasks that have already been started but

I have most of the patterns done.  Now most of them also work off the
current selection if there is one.

Problems.  I started this work based on Gimp 1.2.x scripts (I presumed the
changes would minor and would likely be rejected so I did what was best
for my own purposes at the time) and as a result I have had difficulties
forward porting Truchoid.  I could probably redo my changes staring
againts the 2.0 version but it will be a real pain and this will likely
delay me significantly.

I have also rewritten Swirly to be between 3-4 orders of magnitude faster.
I made it work off the current image too but it adds a new layer
containing a square to the current image and I have not sorted out tiling
it to the current image yet.

I'll try and get more done this week, with any luck I'll get my head
around Swirly and only have Truchoid left to do.  Either way I'll post
most or all of what I have on my site later in the week and file
additional bug reports for the ones that are finshed.

I have spent a lot of time but I have other work I really should be doing
and I am not confident I'll be able to spare enough time to get them all
done in time for 2.2 but I'd be very dissapointed to have my work left
out.

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Linux Journal Editors Choice Award

2004-07-31 Thread Alan Horkan
The Gimp has won the Linux Journal Editors choice Award for Best
Graphics software, they seemed particularly pleased by the improved
EXIF support.

http://linuxjournal.com/article.php?sid=7564
(I saw it in the magazine and went looking for it on the website and
found it but the bizarre thing is that it is post-dated Sunday August
1st)

- Alan H.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] removing gimp toys, second opinion please?

2004-07-22 Thread Alan Horkan

  If you still reject the idea I would ask you to keep the toys in mind when
  it comes to menu reorganisation.  (Wiki is still down otherwise I'd add
  this to the menu reorganisation document we had there).
  The Gnome HIG recommends:
 
  http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu
  Do not create submenus with fewer than three items, unless the items are
  added dynamically (for example the File-New Tab submenu in gnome-terminal).

 Looks as if we need a third Toy then. Any volunteers?

Putting them somewhere else in the menus would be easier.  (Misc? Distort?)

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] removing gimp toys, second opinion please?

2004-07-21 Thread Alan Horkan

http://bugzilla.gnome.org/show_bug.cgi?id=148027

Given that some less used file formats have been removed in recently
releases on the basis of less code to maintain and less general clutter I
suggested that the old Toys be removed from the Gimp for version 2.2.  To
my surprise Mitch rejected the idea (without much explanation), Adam who
wrote the toys didn't seem to think it was a terrible idea so I'm asking
onlist to try and get a second opinion.

If toys like Gee-Zoom were built on top of a useful plugin (eg some sort
of a kaleidescope plugin for example) I wouldn't even be asking but they
toy are not useful at all sso users are just presented with eye-candy and
left wondering how they can get that effect on their actual image but they
cannot.

If you still reject the idea I would ask you to keep the toys in mind when
it comes to menu reorganisation.  (Wiki is still down otherwise I'd add
this to the menu reorganisation document we had there).
The Gnome HIG recommends:
http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu
Do not create submenus with fewer than three items, unless the items are
added dynamically (for example the File-New Tab submenu in
gnome-terminal).

- Alan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


  1   2   >