Re: [Gimp-developer] Screenshot plug-in status

[Alan Horkan]

On 7 Sep 2003, Sven Neumann wrote:

> Date: 07 Sep 2003 13:17:47 +0200
> From: Sven Neumann <[EMAIL PROTECTED]>
> To: Tor Lillqvist <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]>
> Subject: Re: [Gimp-developer] Screenshot plug-in status
>
> Hi,
>
> Tor Lillqvist <[EMAIL PROTECTED]> writes:

(slightly Offtopic and delayed reply)

While a Screenshot plugin can be useful (easy enough to discover) it was
never what I really what I wanted as a windows user.

Rather I would have much preffered to be able to simply use the built in
Print Scrn (or Alt+Print Scrn to grab just the current window) and paste
that into the GIMP.

Unfortunately the GIMP only me to choose File, Aqquire, From Clipboard.
Could pasting from the system ClipBoard be setup in such a way as to allow
me to directly paste screenshots without needing to take the extra few
clicks to Aquire from clipboard or use the Screenshot
plugin?

Should I file an enhancenment request in bugzilla?

- Alan  H.


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

Re: [Gimp-developer] Screenshot plug-in status

[Alan Horkan]

On Thu, 11 Sep 2003, Hans Breuer wrote:

> >Unfortunately the GIMP only me to choose File, Aqquire, From Clipboard.
> Which you never tried at least _once_ before complaining ?

I think you have misunderstood me.
I used it many times, it works and I use what is available.
I only mention it now because changes are being made to the screenshot
code and perhaps there might be a better way to do screenshots and
streamline the workflow.

> Though from the users point of view there may be no differnce between
> 'Copy' (== here Program internal and fast)
>   and
> 'Copy from Clipboard' (== system global, data across process boundaries,
>kind of slow)

I am aware that the system clipboard is different and slower, but isn't
the real performance loss is from the user point of view.

I only ask that you take a moment and consider if there might be a way to
make things faster for the user which is where speed really counts.
Could some of the handling of the system clipboard be done automatically
and only when needed to mitigate the speed tradeoff?  If is impractical
fair enough, I was just asking because the code was being changed anyway.

- Alan


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

Re: [Gimp-developer] Screenshot plug-in status

[Alan Horkan]

On 11 Sep 2003, Sven Neumann wrote:

> Date: 11 Sep 2003 02:04:24 +0200
> From: Sven Neumann <[EMAIL PROTECTED]>
> To: Michael Schumacher <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]>
> Subject: Re: [Gimp-developer] Screenshot plug-in status
>
> Hi,
>
> "Michael Schumacher" <[EMAIL PROTECTED]> writes:
>
> > > While a Screenshot plugin can be useful (easy enough to discover) it was
> > > never what I really what I wanted as a windows user.
> > >
> > > Rather I would have much preffered to be able to simply use the built in
> > > Print Scrn (or Alt+Print Scrn to grab just the current window) and paste
> > > that into the GIMP.
>
> Perhaps you should use GNOME then ;)

I do use Gnome, just not all the time.

- Alan

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

Apple has no Delete Key [Re: [Gimp-developer] Gimp interface streamlining]

[Alan Horkan]

On Fri, 12 Sep 2003, Daniel Egger wrote:

> Date: Fri, 12 Sep 2003 12:20:13 +0200
> From: Daniel Egger <[EMAIL PROTECTED]>
> To: Gimp Developer <[EMAIL PROTECTED]>
> Subject: Re: [Gimp-developer] Gimp interface streamlining
>
> Am Fre, 2003-09-12 um 11.25 schrieb Simon Budig:
>
> > It would be nice to have more keys available to the tools. I'd love
> > to get the Del-Key working for deletion of nodes in the path tool...
>
> The del key is a bad choice. Quite a few GIMP users have Apple machines
> which don't have a del key.

I think Apple is exceptional in that regard and didn't they put some of
the keys back in the later iMac designs?

Delete is such a particularly good and obvious keybinding for Deleting
things with on other platforms couldn't we use delete as well as another
keybinding for the benifit of Mac users?

- Alan H.


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

Re: Apple has no Delete Key [Re: [Gimp-developer] Gimp interface streamlining]

[Alan Horkan]

On Sat, 13 Sep 2003, Marco Wessel wrote:



> It is true that the Apple keyboards that used to come with the iMacs, B/W
> G3s and G4s don't have a del key. However, this keyboard has long since
> been replaced with the full-sized keyboard, which does have the key. As
> does every older mac keyboard in existence, save the PowerBook keyboards.
>
> Simply put, most people should have the key. However, how about using
> backspace, which IMO is more intuitive for deleting things. (Though it
> could be used by something else, I'm not entirely sure.)

Backspace is used to clear a dynamic a dynamic menu keybinding.  (Not to
rule out the possibility of that specific context being made properly
isolated to allow use of Backspace else where).

sincerely

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

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

[Gimp-developer] Berkeley, Bug Isolation Project

[Alan Horkan]

I had not seen this mentioned on the developer list, so sorry in advance
if you already knew about it.

The bug isolation project is an effort to track crashes but also to track
user behaviour and help figure out how to make software better.
http://www.cs.berkeley.edu/~liblit/sampler/

There is a sampler program for the tracking as well as special builds of
open source softare including the GIMP 1.3.20 on their download page
http://www.cs.berkeley.edu/~liblit/sampler/downloads/

Their contact page also has detials of their mailing lists
http://www.cs.berkeley.edu/~liblit/sampler/contact.html

Anyway, I just thought it might be of interest and I hope to try it out
myself soon.

Sincerley

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] How do I get a plugin into the offical release?

[Alan Horkan]

On Tue, 23 Sep 2003, David Neary wrote:

> Henrik Brix Andersen wrote:
> > According to http://registry.gimp.org/changes?max=15 the last change to
> > a plug-in was done only a couple of days ago - so it seems the registry
> > works at least for some people.
>
> Perhaps, but there are several things which should be possible
> which aren't.
>
> First, the majority of the plug-ins in the registry appear to be
> abandonware - 1.0 plug-ins that have never been updates to 1.2,
> never mind 1.3/2.0. We need a way to clean out the cruft (or at
> least hide it away).
>
> Second, the registry could do with a ranking system to have the
> most common and/or popular plug-ins appearing on the top of the
> lists of plug-ins. The only sorting system I've seen is
> alphabetically, which severely limits the usefullness of the site.
>
> Third, it is not possible to attach patches for existing
> plug-ins to a plug-in without being a plug-in maintainer. It
> would be nice if this were easier to do, perhaps with a comment
> system? Although I guess an inscription system makes some
> sense...

This functionality sounds a lot like MozDev, which has a very useful list
of active projects, or Sourceforge (or Gnu/Savannah/Whatever).

Changing to a full blown project management system might make things
easier to manage in the long run.

Something to consider at least.

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

Re: [Gimp-developer] Mailing list archive out of date

[Alan Horkan]

On Thu, 25 Sep 2003, Tino Schwarze wrote:

> Date: Thu, 25 Sep 2003 13:54:47 +0200
> From: Tino Schwarze <[EMAIL PROTECTED]>
> To: Gimp Hackers <[EMAIL PROTECTED]>
> Subject: [Gimp-developer] Mailing list archive out of date
>
> Hi there,
> I just tried to figure out where to get Windows binaries for 1.3.>=19
> and couldn't find any. So I tried to search the archives.
>
> The archive is
> a) out of date (last message from July 26)

There is another archive for the developer list here
http://www.mail-archive.com/[EMAIL PROTECTED]/maillist.html

There is a windows gimp users list at yahoo and they also have
a list archive there too and I know that Tor (aka tml) announced binaries
of 1.3.20 for testing there last week.

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] Re: Alternative zoom algorithm

[Alan Horkan]

On Sat, 17 Jan 2004, Marc wrote:

> Date: Sat, 17 Jan 2004 20:22:05 +0100
> From: Marc <[EMAIL PROTECTED]>
> To: Sven Neumann <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: [Gimp-developer] Re: Alternative zoom algorithm
>
> On Sat, Jan 17, 2004 at 05:24:51PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote:
> > <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes:
> >
> > > Get used to it, that's how gimp-developer works :(
> >
> > Marc, your comment is highly inappropriate.
>
> Eh, really? Yes, maybe I should have said "that's how gimp developers
> work", which would be more approriate.

I commend Sven for his diplomacy.
I am very pleased by Simons explanation.

This may have been the way some of the GIMP developers have worked in the
past but I hope that in future the GIMP developers will do just like
Simon has done and explain his criticism in a fair and clear manner so
that no one will have reason to get offended.

I think that more developers will be attracted to the GIMP if they are
forgiven for impatient mistakes and the over enthusiasm of beginners and
not knowing how things work around here but are given the chance to learn.

Sincerely

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

Re: [Gimp-developer] Re: Win GIMP

[Alan Horkan]

>Please note that GIMP does MDI (multiple document interface)
>already, it just doesn't folllow the WiW (window in window)
>approach that some people seem to prefer for obscure reasons.
>
> Every reference I've ever seen to MDI refers to window in window.  I
> don't understand the purpose of that at all (and I happen to really
> detest it, in any event, since it wastes a lot of screen space).

When using the GIMP I prefer to have the document window maximized.  On
windows this means that the Toolbox will get pushed behind and it is
extremely awkward and I believe this is a significant part of the problem
that most users want solved.  Something as simple as an always on top
option for the toolbox might be enough to make things easier for users
like me who occasionally use crappy window managers.

Speaking of maxmising the avialable workspace and it does seem to be of
interst to more users than just me (I love the fullscreen mode by the way
and) is there any way to hide the scrollbars?
I would like to be able to get rid of the scrollbars and use keys for
scrolling* up and down the page or alternatively use the
overview/navigation widget.
[the following bug is asking for the ability to use specific keys for
scrolling, currently there doesn't seem to be ANY way to assign ANY keys
at all to scrolling http://bugzilla.gnome.org/show_bug.cgi?id=53988 ]

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] Re: Win GIMP

[Alan Horkan]

> > scrolling, currently there doesn't seem to be ANY way to assign ANY keys
> > at all to scrolling http://bugzilla.gnome.org/show_bug.cgi?id=53988 ]
>
> I might be wrong but shouldn't you be able to specify keys for
> scrolling using GTK+ bindings?

without a recompile?
if so please point me to the relevant documentation?
(if it requires a recompile I'm afraid it is only slightly better than
useless)

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

Re: [Gimp-developer] Tentative 2.2 feature list

[Alan Horkan]

On Thu, 5 Feb 2004, Kevin Cozens wrote:

> Date: Thu, 05 Feb 2004 19:25:41 -0500
> From: Kevin Cozens <[EMAIL PROTECTED]>
> To: gimp-devel <[EMAIL PROTECTED]>
> Subject: Re: [Gimp-developer] Tentative 2.2 feature list
>
> On Thu, 2004-02-05 at 17:12, David Neary wrote:
> > 9) A decent image browser/thumbnail viewer + cover-sheet support
>
> This sounds a bit like the old GUASH (which I have started to port
> to GTK+ 2.x/GIMP 2.0) but I'm not sure what you mean by "cover-sheet
> support".

Incidentally this was recently requested amongst the comments on
gnomedesktop.org (or was it bugzilla) and I suggested using one of the
many thumbnail browserst that already have this functionality (gThumb has
it I think) but that it would be great if GIMP also had this
functionality.

take a bunch of thumbnails and create a new image that consits of those
thumbnails layed out in rows and columns much like a photographic contact
sheet that is sometimes provided if you get traditional photographs
developed.

The latest version of Adobe Photoshop includes a Thumbnail browser
(methings they felt Paint Shop Pro biting at their heels) so expect to
hear lots of complaints about the GIMP not having a Thumbnail browser
anymore.  Good luck with the GUASH revival, and I encourage anyone who has
ideas on how to make GQView, gThumb, F-spot or any other thumbnail browser
work better with the GIMP.

Sincerely

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

PS As soon as I get my hands on an evaluation copy of Photoshop I'll be
filing a truckload of enhancements requests including one with many
screenshots of PhotoMerge (and if you dont know what that is yet then I
encourage you to look at the best of the rest and steal ideas for the
GIMP).
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)

[Alan Horkan]

On Fri, 6 Feb 2004, Sven Neumann wrote:

> Date: 06 Feb 2004 11:50:54 +0100
> From: Sven Neumann <[EMAIL PROTECTED]>
> To: David Neary <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]>
> Subject: Re: [Gimp-developer] Updated roadmap (so people don't laugh at
> the old one)
>
> Hi,
>
> David Neary <[EMAIL PROTECTED]> writes:
>
> > You can certainly spread it around. I update the NEWS now, as
> > well as you. Anyone can do that. Same thing goes for making the
> > announcement on freshmeat, gnome-desktop, linuxartist... I can do
> > bugzilla tags.
>
> Well, I am certainly not going to ask for this and so far I have
> always waited about a day if someone else would post announcements on
> gnomedesktop and other sites. But it seems that noone but me is
> interested enough to post there, so I guess I will continue to do

If you _asked_ people might post the news but unless you asked for others
to do it then I would assume that you wanted to do it yourself and have it
done your way.  And I'm on the list digest so I usually read the
announcement on GnomeDesktop.org before I read it on the list.

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

Re: [Gimp-developer] Re: Last day for abstracts

[Alan Horkan]

On Mon, 16 Feb 2004, Carol Spears wrote:

> Date: Mon, 16 Feb 2004 06:49:06 -0800
> From: Carol Spears <[EMAIL PROTECTED]>
> To: Dave Neary <[EMAIL PROTECTED]>,
>  GIMPDev <[EMAIL PROTECTED]>
> Subject: [Gimp-developer] Re: Last day for abstracts
>
> it is going to be a tough act to follow robin rowe and cinepaint.
>
> gimp-1.0 rox!
>
> carol

Carol

I know you are funny sometimes but we all know Robin reads this list and
such comments dont help anyone.

Can't we all just get along?

Barney the purple dinosaur says "Lets be fwiends"?

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

Re: [Gimp-developer] Re: Last day for abstracts

[Alan Horkan]

On Mon, 16 Feb 2004, David Neary wrote:

> Date: Mon, 16 Feb 2004 23:14:30 +0100
> From: David Neary <[EMAIL PROTECTED]>
> To: Alan Horkan <[EMAIL PROTECTED]>
> Cc: Carol Spears <[EMAIL PROTECTED]>,
>  GIMPDev <[EMAIL PROTECTED]>
> Subject: Re: [Gimp-developer] Re: Last day for abstracts
>
> Hi,
>
> Alan Horkan wrote:
> > On Mon, 16 Feb 2004, Carol Spears wrote:
> > > it is going to be a tough act to follow robin rowe and cinepaint.
> >
> > I know you are funny sometimes but we all know Robin reads this list and
> > such comments dont help anyone.
> >
> > Can't we all just get along?
>
> I agree with the sentiment, but AFAIK Robin hasn't read this list
> since yosh de-subscribed him during the Summer after yet another
> row over the history of FilmGIMP. Just wanted to say that I
> disagreed with someone abusing their power like that - after all,
> we're welcome on the Cinepaint lists.

You cannot prevent people reading the web based archives (assuming there
is a working version around somewhere) nor can you ban every unknown
address which anyone could easily aquire if they wanted to join this
_public_ list.  However if you made Robin that unwelcome I doubt he would
bother rejoining the list and by outright banning him you will have only
aliented him further.

I understand that some people resent the duplication of effort and that
comments on both sides have been less than friendly but it benifits
neither project to argue.

I still believe that both projects can coexist and that each can focus on
doing something well and both fulfill a useful niche.

It is long overdue for both projects to accept each other and work
together.

It seems odd to me that the best way to produce a plugin compatible with
both Cinepaint and the GIMP is to program it to the Adobe Photoshop API.

I know that it is a contentious issue but someone has to just draw a line
and move on for the greater good and it deeply saddens me that you dont
cut each other a bit more slack and that these kinds of childish
arguements, misunderstanding and misinterpreations prevent talented
developers from working together.

I really love the work that the GIMP has done and I'm glad that CinePaint
has been able to fill a niche for those who need 32 bit support right now
and cannot or are unwilling to wait for GEGL.

I dont want to gush and say how wonderful you all are for devoting your
free time to work on the GIMP but I worry that the joy is being lost.  I
really sincerely appreciate having such a powerful solution as the GIMP
but the GIMP has only just begun.

I know it is a cliche but if you cannot say anything nice please do try
and dont say anything at all.

Sincerely

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

Re: [Gimp-developer] The GIMP Foundation

[Alan Horkan]

On Mon, 8 Mar 2004, Kelly Martin wrote:

> Date: Mon, 08 Mar 2004 23:09:51 -0600
> From: Kelly Martin <[EMAIL PROTECTED]>
> To: Sven Neumann <[EMAIL PROTECTED]>
> Cc: Nathan Carl Summers <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> Subject: Re: [Gimp-developer] The GIMP Foundation
>
> Sven Neumann wrote:
>
> > If sueing copyright violators is the main goal, I'd rather let the
> > Free Software Foundation do this job. It is probably in a lot better
> > position when it should ever come to a law-suit.
>
> The FSF can't sue someone unless it owns at least some part of the code in
> question.  The FSF's solution to this has been to seek assignment of copyright.
>   Do you want to assign the GIMP copyrights to the FSF?

I can tell you that although the FSF much prefer to have some ownership
of the code it is not an absolute necessity and that as it is in their
interest to defend the GPL they have been very helpful to projects that
did not fall directly under their banner.  Just ask Bradley Kunh.

Sincerely

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

Re: Re : Fwd : Re : Re : [Gimp-developer] splash pictur [jean-luc.coulon@wanadoo.fr]

[Alan Horkan]

On Sat, 13 Mar 2004, Jean-Luc Coulon (f5ibh) wrote:

> Date: Sat, 13 Mar 2004 16:42:37 +0100
> From: "Jean-Luc Coulon (f5ibh)" <[EMAIL PROTECTED]>
> To: Sven Neumann <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: [iso-8859-1] Re : Fwd : Re : Re[iso-8859-1]  :
> [Gimp-developer[iso-8859-1] ] splash pictur [EMAIL PROTECTED]
>
> Hi Sven,
>
> Le 13.03.2004 16:20, Sven Neumann a écrit :
> >Hi,
> >
> >"Jean-Luc Coulon (f5ibh)" <[EMAIL PROTECTED]> writes:
> >
> >> I don't think my font size is so huge ;-)
> >
> >Well, your font isn't that huge but you've choosen a very wide font.
> >It's of course up to you, but you will be suffering from this problem
> >in all dialogs. I suggest you don't use an oblique font for your
> >desktop.

I've always been told that for localisation reasons you have always have
to leave extra space anyway, most noteably up to 2/3 extra for the
talkative Germans (I think that is the usual figure that gest mentioned
but dont quote me on it).

For accessibility reasons space for larger fonts would be also be needed.

I think it would be an interesting change if the GIMP had splash screen
that was Landscape, but that it really up to Jimmac of course but it would
help cover up this glitch.

> While we are speaking of splash screen a 3:2 ratio or 4:3 ratio or
> "magic number" ratio rectangle instead of a square shape would looks
> even better, but it is a matter of taste  ;-)

aha! but do you try and anticipate the size of the status bar,
window and window decorations and attempt to have it so that the overall
ratio is 3:2/4:3 or do you just do it for the image?  (consider that a
rhetorical question).

Sincerely

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

PS How are the Splash and About images still PPM format* because I was
wondering why they aren't in a smaller format like PNG?
(* I dont have the latest copy of GIMP 2.0 handy otherwise I'd check)
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Re: Re : Fwd : Re : Re : [Gimp-developer] splash pictur [jean-luc.coulon@wanadoo.fr]

[Alan Horkan]

On Sun, 14 Mar 2004, Sven Neumann wrote:

> Date: 14 Mar 2004 02:31:43 +0100
> From: Sven Neumann <[EMAIL PROTECTED]>
> To: Alan Horkan <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: [utf-8] Re: Re : Fwd : [utf-8] Re : Re : [Gimp[utf-8]
> -developer] spl[utf-8] ash pictur [jea[utf-8] [EMAIL PROTECTED]
> nadoo.fr]
>
> Hi,
>
> Alan Horkan <[EMAIL PROTECTED]> writes:
>
> > PS How are the Splash and About images still PPM format* because I was
> > wondering why they aren't in a smaller format like PNG?
> > (* I dont have the latest copy of GIMP 2.0 handy otherwise I'd check)
>
> Please get a recent copy then or refrain from commenting on our
> code. These files are PNG for more than 2 years now. You could have
> downloaded a new version in the meantime.

I have previously used the GIMP 1.3.x builds but I just didn't have a copy
conveniently in front of me that I could check against.

So it was a dumb question.

> Of course we know about the problems that l10n can introduce.

I phrased the comment about localisation poorly, I realise it doesn't read
well and of course I wasn't suggesting you dont know about localisation.

> However the solution to this problem is not to add some arbitrary extra
> space but to adjust either the widget or the font size dynamically.

Adjusting thing dynamically was the problem!
The minimum size for the widget wasn't big enough so it kept resizing and
that resizing was the annoying glitch in question.

> Usually the widget is adjusted but for the about dialog we adjust the
> font size and I consider to do the same for the splash.

I dont know why distributions that support startup notification dont just
disable the splash screen since they dont have any technical reason for
having it.

I'll just disable the splash sceen on my machine and not mention it again.

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

Re: [Gimp-developer] gimp2 on a 486

[Alan Horkan]

> so, you decide if i am a troll or not and be my guest -- delete the
> mails or even better yet tell your spam filter about me.

spam filters are no use for blocking people if you use the mailing list
digest.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Press pack

[Alan Horkan]

On Sun, 21 Mar 2004, Branko Collin wrote:

> Date: Sun, 21 Mar 2004 14:22:08 +0100
> From: Branko Collin <[EMAIL PROTECTED]>
> To: Gimp Developer <[EMAIL PROTECTED]>
> Subject: Re: [Gimp-developer] Press pack
>
> On 21 Mar 2004, at 19:17, Jakub Steiner wrote:
>
> > I made a couple of demos of the new GIMP 2 functionality. I believe it
> > works a lot better than just a list of new functionality. They are
> > divx avis and it's approx 80MB. Feel free to mirror it on the gimp.org
> > website and use it for the 2.0 release extravaganza.
> >
> > http://jimmac.musichall.cz/gimp2demos.php
>
> I have tried to play these demos using Windows Media Player
> (Microsoft) version 2, 7 and 9, and in all instances it crashed my
> mediaplayer. The error messages says something about a divx module;
> probably just the decoder I am using.
>
> Still, it would perhaps be handy to test this on other Windows
> installations if this URL is going to be sent to any other than
> GNU/Linux using journalists.

If the video needs to be recoded may I humbly recommend using Xvid.
http://www.xvid.org (although perhaps you are already using it merely
referring to it as DivX for convenience)

It is almost at 1.0, in the prerelease/release candidate stages at the
moment.  It is a proper open source MPEG 4 implementation.

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

[Gimp-developer] The issue of JPEG Patents?

[Alan Horkan]

http://www.theregister.co.uk/2004/04/23/forgent_jpeg_suit/

Has the issue of Jpeg Patents been brought up yet?
(a quick but not thorough search suggests not)

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

Re: [Gimp-developer] The issue of JPEG Patents?

[Alan Horkan]

On Fri, 23 Apr 2004, Daniel Rogers wrote:

> Date: Fri, 23 Apr 2004 22:47:49 -0700
> From: Daniel Rogers <[EMAIL PROTECTED]>
> To: Joao S. O. Bueno <[EMAIL PROTECTED]>
> Cc: Alan Horkan <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [Gimp-developer] The issue of JPEG Patents?
>
> Joao S. O. Bueno wrote:
> > On Friday 23 April 2004 18:39, Alan Horkan wrote:
> >
> >>http://www.theregister.co.uk/2004/04/23/forgent_jpeg_suit/
> >>
> >>Has the issue of Jpeg Patents been brought up yet?
> >>(a quick but not thorough search suggests not)
> >
> >
> > hmmm...What about waiting until october, and THEM start the Gimp Foundation?
> > You can't sue what does not exist
>
>
> > Honestly...I got scared for the GIMP when I read about the "thou shalt not
> > open scanned-up money images"  blurbs ...
> > when I read about this JPEG patents, I did not even thought about the GIMP,
> > because it's just too stupid. But..who knows where human greed can take us?
>
> Well you could still sue the plugin maintainer.  but that is no point.
> It is greed drivin, thus there is a second, implict rule, thou shall not
> sue that which has no money.

I was thinking that Jpeg support might have to be preemptively removed
like Gif support was removed.  (Although the Gif patents have expired in
America and will expire in Europe in June)

On reading more, some comments suggest that this issue might not be
specific enough to effect the Gimp but then I always believed Gif could
have been included in the Gimp if parts of the Gif compression had been
disabled but these issues are always more complicated than they
seem.
http://slashdot.org/comments.pl?sid=105099&cid=8948562

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

Re: [Gimp-developer] Image Info Dialog

[Alan Horkan]

On Tue, 27 Apr 2004, Dave Neary wrote:

> Date: Tue, 27 Apr 2004 11:42:33 +0200
> From: Dave Neary <[EMAIL PROTECTED]>
> To: Carol Spears <[EMAIL PROTECTED]>
> Cc: GIMPDev <[EMAIL PROTECTED]>
> Subject: Re: [Gimp-developer] Image Info Dialog
>
>
> Hi,
>
> Carol Spears wrote:
> > since day one with the gimp, everytime i want to get the info dialog i
> > first search the Image Menu.  my reasoning is "Image -->Info".  i am
> > really not thinking of viewing anything, more like knowing 

I always though of 'File, Properties' (or 'File, Get Info' because there
is lots of kinds of file metadata, not specifcally related to the image
drawable.

> This is a reasonable suggestion.
>
> Out of interest, are there other menu items that people would like to see
> elsewhere? This is not very difficult to do, but there has not (yet) been a

I very much want menus in other places.
I filed this bug less than two weeks ago and it was rejected.
http://bugzilla.gnome.org/show_bug.cgi?id=140439

I'm convinced that there will always be people who want menus in different
places and that runtime customizable menus will eventually be needed.
(It doesn't seem possible to have menus that will be comfortable for
longterm Gimp, Adobe Photoshop, Corel Painter or Macromedia Fireworks
users).

If the improvements to Script-Fu allow scripts to exactly place menu items
(this seemed to be part of the plan) and assign shortcuts (but this wasn't
mentioned) I will at least be able to use scripts to put some features
exactly where I would like them to be.  (It doesn't seem to be posible to
use Script-Fu to add seperators either, I just get a menu item labelled
---).

> proposition on where to put menu entries.

... so many things I'd like to mover around I wont even start to list
them.

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

Re: [Gimp-developer] Image Info Dialog

[Alan Horkan]

On Tue, 27 Apr 2004, Carol Spears wrote:

> > > Carol Spears wrote:
> > > > since day one with the gimp, everytime i want to get the info dialog i
> > > > first search the Image Menu.  my reasoning is "Image -->Info".  i am
> > > > really not thinking of viewing anything, more like knowing 
> >
> > I always though of 'File, Properties' (or 'File, Get Info' because there
> > is lots of kinds of file metadata, not specifcally related to the image
> > drawable.
> >
> i can see the logic of "File -->Info" i just never thought that way
> myself.
>
> i always want "Image Info", and the truth is, this dialog is so limited
> that it is still quicker to get the scale tool and pop up the scale
> dialog to get the width and height information which is usually what i
> am looking for.
>
> crap, i am working so much on web pages with my wysmythingie (mozilla)
> that it is actually (truthfully) quicker to right click on the image and
> load that into the web browser for the height and width information.

I've gotten into the habit of hovering over the bottom right corner and
rounding up to figure out the image size.

I'm thinking if we are both finding it a little bit awkward to quickly
know the image dimensions then it is unlikely that we are the only ones
and that it would be something worth improving.

Perhaps additional information in the status bar messages showing the
selection dimensions and offsets would work?  (Shown as a standard
transient message, I am definately not advocating permanently grabbing a
chunk of the statusbar.)  I think, I hope something non-intrusive and
relatively trivial could be done to make things a little bit easier,
ideas?  Should I file a request for enhancement?

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

Re: [Gimp-developer] Usability test - Results available

[Alan Horkan]

> This dialog is still available but it isn't any longer bound to the
> "By Color Select" Tool. Choose "Selection Editor" from the Dialogs
> menu.
>
> > Move the 'Fill' and 'Stroke' functions to the 'Selection' menu.
>
> I don't think these belong there since they do not manipulate the
> Selection. Where do other apps put "Fill"? IMHO it belongs into the
> "Edit" menu and I am surprised that the users didn't look for it
> there.

Fill and Stroke definately don't belong in the Selection menu (you could
be filling or stroking a Path not just a selection).  The Select menu
keeps the selection options nicely seperate from manipulating the image
(or drawable ie the contents of the selection).

Although there was a problem adding things to Select menu does not seem
like the right solution and it was one of the few suggestions in the
report I strong disagreed with.
The suggestions to provide much more information in the status bar (like
the way Inkscape does) sounded like a good idea but would probably be
rather time consuming work.

Adobe Illustrator uses Edit, Stroke and Edit, Fill... (just one item for
Fill which pops up a dialog with lots of options and fill types of all
kinds).  Photoshop also has "Layer, Filled Layer" (or similar) which
allows you to choose a texture/pattern and inserts a new layer with that
fill.

I dont recall Jasc having any extra fill options besides using the bucket
tool (and I double checked by looking at various sites including this one
http://moonsdesigns.com/tutorials/psp8/tools.html )

Sincerely

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

[Gimp-developer] Re: [Gimp-user] Re: Blur plug-in

[Alan Horkan]

On Mon, 7 Jun 2004, GSR - FR wrote:

> Date: Mon, 7 Jun 2004 15:10:30 +0200
> From: GSR - FR <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: [Gimp-user] Re: Blur plug-in
>
> [EMAIL PROTECTED] (2004-06-07 at 1149.52 +0200):
> > The plan is to remove the randomize and repeat functionality. That
> > would allow us to also remove the (quite confusing) dialog.
> > Filters->Blur->Blur would then be a simple blur with a 3x3 convolution
> > kernel. It would be fast and easy to use but of course we it would be
> > less powerful. So the question is, is anyone actually using this
> > functionality? Are there scripts out there that rely on
> > plug-in-blur-randomize to be available?
>
> Why not just ditch it completly then? If it just a 3x3 convolution
> that you have to manually repeat, and there are already other filters
> and scripts that do the same. The point of repeat is not having to
> rerun manually to get a "bigger radius" blur.

If there was a more convenient way to save a 3x3 convolution matrix than
having to write a script-fu script around the convulotion matrix plugin
then there would not be any reason to keep the blur plugin but at the
moment manually typing in a convulation matrix gets really annoying really
fast.

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

[Gimp-developer] a few script-fu

[Alan Horkan]

I've been doing some scripting
http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/script-fu.html
and I'd like to return my scripts for inclusion in the Gimp.

New File Dialog is poweful and flexible and makes it easy to create new
images, it is better to have script work off the current image if
possible, than trying to reinvent the new file dialog inside a script. I
have changed Camouflage and SwirlTile to work off the current image (they
are added to the menu at Filters/Render/Patterns/ although I'd prefer if
they weren't so deep but hopefully the menu reorganisation will allow the
menu structure to be flatter).

Direct links to my Camouflage and Swirl Tile scripts
http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/camouflage.scm
http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/pattern-tileable-tempest.scm

I have also worked on the round-selection script-fu, the most
notable change is that it can now do concave as well as convex edges.
http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/selection-rounded-rectangle.scm


Sincerely

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

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

Re: Scheme [was Re: [Gimp-developer] OSCon attendance]

[Alan Horkan]

On Thu, 15 Jul 2004, Markus Triska wrote:

> Date: Thu, 15 Jul 2004 18:52:36 +
> From: Markus Triska <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Scheme [was Re: [Gimp-developer] OSCon attendance]
>
> On Thursday 15 July 2004 02:25 pm, Shlomi Fish wrote:

> Each of the nominated projects is very good (see Dave's post for some details
> about the GIMP). The Arch - GIMP relation was a joke, if you don't mind. The
> fact remains that Tom's Pika Scheme has Unicode support, which TinyScheme
> lacks, so it could be worth a look.

As there was some talk about the GIMP using Guile and if much work has
been already done in that direction it it might also be worth mentioning
that there is someone actively working on a Guile wrapper for Pika
http://lists.gnu.org/archive/html/pika-dev/2004-01/msg00067.html

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

[Gimp-developer] removing gimp toys, second opinion please?

[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

Re: [Gimp-developer] removing gimp toys, second opinion please?

[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] Linux Journal Editors Choice Award

[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] preparing GIMP 2.2 (fwd)

[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] script-fu gimp-flip problems? "procedural database execution failed"

[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

[Gimp-developer] Re: script-fu gimp-flip problems? "procedural database execution failed"

[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

Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.

[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] split GIMP into even more packages

[Alan Horkan]

On Wed, 8 Sep 2004, Sven Neumann wrote:



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

[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] on splitting things off

[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

Re: [Gimp-developer] Re: New Image dialog usability bug

[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] gimp GUI

[Alan Horkan]

.

gimp is/was missing 'Exclusion' though

if you want to have a permanantly open menu the developers might be
willing to add an extra tearoff if you asked nicely.

> the layer menu stays in place, appearing 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] gimp GUI

[Alan Horkan]

> > Photoshop does have some vector tools... of course we have SVG which
> > Illustrator also uses...
>
> GIMP has a path tool which is essentially a vectors tool. It could
> need some other vector shapes though... of course we have SVG which is
> the standard format for storing paths in GIMP 2.0.
>
> > its the slicing for web that is vitally important too photoshop
> > also has this...
>
> GIMP also has this. There are Python and Perl scripts that do the
> slicing and also create HTML for you.

Last week I learned there is also a scheme/script-fu version called
'webotine' which is great if you want to have the same version on both
windows and linux.  http://registry.gimp.org/plugin?id=2821

-- 
Alan Horkan

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

Re: [Gimp-developer] first impressions of GIMP 2.0

[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] first impressions of GIMP 2.0

[Alan Horkan]

On Mon, 25 Oct 2004, Sven Neumann wrote:

> Date: Mon, 25 Oct 2004 21:04:57 +0200
> From: Sven Neumann <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Gimp-developer] first impressions of GIMP 2.0
>
> Hi,
>
> "miriam clinton (iriXx)" <[EMAIL PROTECTED]> writes:
>
> > The Rect Select Options though is a feature that few designers need
> > in a menu - it would be better to use a custom Color swatch tool -
> > which is invaluable.
>
> I don't understand. Would you mind to elaborate on this?
>
> > The Colormap utterly baffles me.

Do you mean the colour picker tool?  There is lots of functionality there,
I suppose I can see how it might be confusing.

> Sorry?
>
> > Erm how do you add a layer mask? I usually add a layer mask
> > simply by selecting Layer mask while i'm working with a layer - no
> > need to select it with the Move tool or the Selector tool. This one
> > baffles me
>
> Huh? Go to the Layers menu, choose "Add Layer Mask". Also available
> from the right-click menu in the Layers dialog.

Specifically:
Layer, Mask, Add Layer Mask.

(As Sven has pointed out) There is also a context menu hidden in the
Layers dialog (if you right click on the Layer Preview part of the Layers
dialog) although it is not something I'd expect a new user to find
without being told it was there.

Is this very different from how it is done in Adobe Photoshop?

> > I'm actually (sadly) testing the ;atest Winblows version (Win ME) - at

(Windows ME is possibley the worst version of Windows ever, windows 98 and
Windows 2000 are far less unpleasant than that nasty hybrid.)

> > the moment there's not enough room on my laptop to run both GNU/Linux
> > and winblows - and I have to use Flash and Fireworks for my work. But

If you have a CD Rom drive a bootable Live CD version of Linux might be a
good choice for you.

> > Default opening tool should be set to the 'move/select' tool - opening
> > with the selector tool can often cause dangerous mistakes, moving
> > sections when you dont want to!

The mistakes are not dangerous as gimp has a working Undo system.
I find "File, Revert" to be very useful too.

> > One feature I'd love to see is drag and drop from one image to
> > another. I use this frequently, rather than cutting and pasting
> > layers.
>
> You can drag and drop from the layers dialog, even between two layer
> dialogs. There's a lot to drag and drop in GIMP and also between GIMP
> and other applications. GIMP 2.2 will also improve clipboard support.

Gimp is definately very good when it comes to drag and drop.

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)]

[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

"Do what I mean" [was RE: [Gimp-developer] first impressions of GIMP 2.0]

[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

Re: [Gimp-developer] Dialog layouts in 2.2pre1

[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

Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...

[Alan Horkan]

On Tue, 9 Nov 2004, Popolon wrote:

> Date: Tue, 09 Nov 2004 23:00:35 +0100
> From: Popolon <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [Gimp-developer] Selection to brush/pattern/whatever in menus...
>
> Actually in Select menu there is two items "To Path" and "Save To Channel".
>
> I searched long time how to convert selection to brush, I think that the
> only way was to save brush to a file, move the file to ~/.gimp-xx/brush
> folder and restart gimp.
>
> This week in a newsgroup, another guy searched didn't find how to
> convert a selection to a pattern. For him the only way was to save
> selection to move the file to ~/gimp-xx/pattern folder and restart gimp :(.
>
>
> A day, don't know exactly for why, By wandering in gimp menus, I find
> the miraculous:
> Script-Fu->Selection->To Brush/Image/Pattern

I adjusted my local version to become "Edit, Define Pattern..."
(and similarly "Edit, Define Brush...").

I think the current label is incorrect and misleading because the
selection itself is not being modified, the _contents_ of the selection is
what is being modified (same goes for most scripts and filters).

> I believe (perhaps wrong), that the human logic is to use the same tool
> to do nearly the same thing.
>
> The menu Select could have an organisation for these conversions as:
>
> Select->To...->[Brush/Channel/Image/Path/Pattern/...]

I agree that it would help if the scripts were moved to elsewhere in the
menus, but I reiterate my point that I do not think they do not belong in
the Select menu.

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

[Alan Horkan]

On Thu, 11 Nov 2004, David Neary wrote:

> Date: Thu, 11 Nov 2004 18:21:36 +0100
> From: David Neary <[EMAIL PROTECTED]>
> To: Sven Neumann <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
>  [EMAIL PROTECTED]
> Subject: Re: [Gimp-developer] Selection to brush/pattern/whatever in
> menus...
>
> Hi,
>
> Sven Neumann wrote:
> > Script-Fu->Selection->To Brush solves this nicely
> > but it should be moved to a better place in the menus.

I forgot that I made further modifcations to my local copy of the script
besides moving it to "Edit, Define Brush..." I aslo removed the option to
specify the filename and made the script to that automatically because if
I really wanted to be able to specify the filename I could "Save As" and I
preferred to to keep it as simple as possible
(and I also wanted to copying how that other photo editor does it
http://www.nectec.or.th/courseware/graphics/photoshop/define-brush.gif )

It is important that 'Define Brush' be significantly easier and way more
useful than using 'Save As', at the moment the main advantage of the
script is not needing to hunt around for the correct directory.

Now that I think about it more I remember I actaully made quite a few
changes I also improved it to work with INDEXED Images and I made sure it
worked if you had no existing selection.

I might have submitted it before (if I was finished and if I thought it
might be accepted without too many changes) but my attempts to consolidate
the code with 'Selection to Pattern' were not very successful (saved more
space by not needing to include the GPL twice than anything else), and it
kinda sucks not to be able to include a thumbnail sized preview in the
dialog.

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

If there is enough interest I will try and dig out my modified version
later this week, I might have to forward port the changes to gimp 2.0.

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

[Offtopic] Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...

[Alan Horkan]

tting them to switch completely is compounded by their
requirement to support their library of exisiting files in a proprietary
format, and their collections of brushes and scripts that are difficult to
convert.  It is better to completely 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...

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

[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

[Gimp-developer] canvas background options

[Alan Horkan]

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.

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

[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

[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

[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

[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

Re: [Gimp-developer] canvas background options

[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

[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

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

[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]

[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] comparing gimp speed

[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

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

[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

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

[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] Why not allow the name to be configurable?

[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)]

[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?

[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

[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?

[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?

[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] panel and winning splash

[Alan Horkan]

On Mon, 13 Dec 2004, Carol Spears wrote:

> Date: Mon, 13 Dec 2004 08:51:44 -0800
> From: Carol Spears <[EMAIL PROTECTED]>
> To: GIMPDev <[EMAIL PROTECTED]>
> Subject: [Gimp-developer] panel and winning splash
>
> hi,
>
> 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.

> i ask because someone has asked to borrow the script i used to make the
> splash with -- i would like to use it one last time before sharing it --
> on this panels decision.
>
> is there a decision or an eta of when the decision will be "passed
> down"?

We all hope to reach a decision real soon now.

- 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? [was [Bug 160890] Change Gimp name (fwd)]

[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

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

[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] xtns->extras ?

[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

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

[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=detail&aid=1115612&group_id=93438&atid=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

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

[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

Re: [Gimp-developer] Idea for new plugin

[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

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

[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] Apply palette to image colormap

[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

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

[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=46852&action=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]

[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

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

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

[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]

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

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

[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-devel&m=92756018422117&w=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

[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

Re: [Gimp-developer] Integrated Scripting

[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

[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] Integrated Scripting

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

[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 (fwd)

[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!

[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] Layer locking proposal

[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] Krita news

[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

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

[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

[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
> 
> 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] Photoshop PSD 6 format Spec / Gimp XCF format Spec

[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 
> 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]

[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

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

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

[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] Why be cryptic? 'Xtns' should be name 'Extensions'

[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