Re: [Gimp-developer] Redo shortcut

[Phil Harper]

From: Tom Mraz <[EMAIL PROTECTED]>
To: Gimp Developer List <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Redo shortcut
Date: Thu, 25 Sep 2003 20:18:18 +0200
MIME-Version: 1.0
Received: from lists.XCF.Berkeley.EDU ([128.32.112.242]) by 
mc11-f15.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 25 Sep 
2003 11:35:45 -0700
Received: from lists.XCF.Berkeley.EDU (unknown [127.0.0.1])by 
lists.XCF.Berkeley.EDU (Postfix) with ESMTPid 5BEDC103B1; Thu, 25 Sep 2003 
11:45:30 -0700 (PDT)
Received: from penguin.kabelta.cz (unknown [212.11.121.19])by 
lists.XCF.Berkeley.EDU (Postfix) with SMTP id 46757102CCfor 
<[EMAIL PROTECTED]>;Thu, 25 Sep 2003 11:32:14 -0700 
(PDT)
Received: (qmail 1784 invoked from network); 25 Sep 2003 18:18:18 -
Received: from localhost (HELO centrum.cz) (127.0.0.1)  by localhost with 
SMTP; 25 Sep 2003 18:18:18 -
X-Message-Info: yilqo4+6kc43tBKQfUgFUHBFfx51X4Ib
Delivered-To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807
X-Accept-Language: cs, en-us, eo
References: 
<[EMAIL PROTECTED]><[EMAIL PROTECTED]><[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.1b4
Precedence: list
List-Id: 
List-Post: 
List-Subscribe: 
,
List-Unsubscribe: 
,
List-Archive: 
List-Help: 

Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 25 Sep 2003 18:35:46.0183 (UTC) 
FILETIME=[D57F5970:01C38393]

I believe we could hard-code two keybindings to work as the
default, couldn't we?
Technically possible, but extremely horrible, since the user has to be
educated about it. And since the only argument in favour of the less
ergonomic C-S-Z is "easier to learn", that sounds even worse than leaving
it at C-R.
I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. 
Then if you move from photoshop or HIGified Gnome apps, it will work for 
you. But the (IMHO) much more ergonomic C-R stays as the default for 
newbies. As it was said earlier the ergonomics of Redo operation in for 
example text editor is less important as you don't use it so often and you 
don't switch between Undo and Redo very fast and frequently.

Tom Mraz

sounds like a good option, of course, it would confuse things if a user 
wants to apply SH+CT+Z to some other function(not sure why they'd want to, 
but it's possible).

just out of interest, what on earth made the GNOME HIG people think that 
SH+CT+Z was a good combo for anything? and is there a good reason (HIG rules 
wise) for not allowing use of CT+R? it's not like there's a refresh of 
reload funciton in GIMP(although it could be handy, i still wouldn't want it 
attached to CT+R)

you've got to remember that from a Photo$hop perspective undo and redo are 
unimportant, everything's done with history, and undo is normally only one 
level(that's how i remember those horrible experiences anyway) or is it Ct+Z 
becomes Redo once you've undone once, either way, it's deeply unpleasant and 
i don't want to talk about it :P

Phil.

_
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Phil Harper]

From: [EMAIL PROTECTED] (Tino Schwarze)
To: Gimp Hackers <[EMAIL PROTECTED]>
Subject: [Gimp-developer] Mailing list archive out of date
Date: Thu, 25 Sep 2003 13:54:47 +0200
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.
oh dear, well, if it helps, gimp-head.zip is the file you're after.

The archive is
a) out of date (last message from July 26)
b) not searchable (ht://dig error: "Unable to read configuration file")
Bye, Tino.

--
 * LINUX - Where do you want to be tomorrow? *
  http://www.tu-chemnitz.de/linux/tag/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
www.gimp

_
Sign-up for a FREE BT Broadband connection today! 
http://www.msn.co.uk/specials/btbroadband

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

Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)

[Phil Harper]

just to say, "yeah, what he said" ;)

seriously though, i have real trouble remembering to use shft+crtl+z instead 
of ctrl+r, it's mainly habit, but it is also the fact that i find the old 
method more comfortable.

the only place Ctrl+ r gets me into trouble is Mozilla, when editing an 
email i ocasionaly refresh the page by accident, thanks to my painfully slow 
connection i can sometimes stop it before it gets anywhere though :P

i'm sorry if i've missed large parts of this thread, my hotmail address is 
under attack from a worm, so i don't receive a lot of mail(other than 
"security updates") at the moment :(

Phil.

From: Nathan Carl Summers <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: David Neary <[EMAIL PROTECTED]>, Branko Collin <[EMAIL PROTECTED]>, Gimp 
Developer List <[EMAIL PROTECTED]>
Subject: Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
Date: Tue, 23 Sep 2003 09:50:58 -0700 (PDT)

/me returns from the hurricane, finally able to catch up on several days
worth of email.
On Mon, 22 Sep 2003 [EMAIL PROTECTED] wrote:
>
> However I *love* the Ctrl-R binding, especially because it lets me 
quickly
> compare the done and undone versions of an image using a single hand 
with
> very little effort. Try to do it with Ctrl-Z/Shift-Ctrl-Z and you'll 
find
> that you need either very good coordination between fingers (better than 
the
> one I have at least) or to use both hands.

I agree.  Gimp's undo and redo feature differs from many other programs in
that when comparing subtle changes it is useful to switch rapidly between
the "before" and "after" views, while for a program such as a word
processor, that is probably not a useful thing to do.  This being the
case, this particular need of GIMP users was probably not considered by
the HIG.
Personally, I compare between the "before" and "after" by holding down
control and hitting z or r as necessary.  For some changes, I switch
several times a second, as the human eye is remarkably able to detect
small differences when they are animated.
Switching between views this fast with accuracy is simply not possible
using Shift-Ctrl-Z due the the physiology of the human hand. The optimal
hand position is left on the shift and control and right on the z, with
the finger on the shift moving every other beat of the other hand and the
finger on the control key staying still.
Here the body's natural cordination works against switching views quickly,
as the nervous system will assume that the finger on the R key and
that on the shift key should really be synchronized.  This leads to
errors. With the old bindings the natural cordination system helps to
acomplish the task accurately and faster.
> So, if it's possible to have two different keybindings for the same 
command
> I'd like very much to have both.

Unfortunately, it is not.  Really, GTK should be made more flexable in
this regard, but it is not a trival problem, due to how GTK handles
accelerators.
Since we only can choose one, it makes sense that we choose the one that
ergonomics favors.  I'm sure that in this case most usability people would
say that actually being able to use the feature is more important than
consistancy with some other apps.  Especially because this particular
funciton isn't particularly consistant between apps.
On the other hand, we could go for both ergonomics and consistency by
using MS Office's Ctrl-Y.  Note that I am not recommending it.  I think
keeping redo the way it is in 1.2 is the best policy.
> BTW, the mail program I'm using right now (Forte Agent) uses Ctrl-R to 
redo.

There we go, between that and tradition, we have all the justification we
need. ;)
Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger

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

Re: [Gimp-developer] Gimp interface streamlining

[Phil Harper]

From: Jakub Steiner <[EMAIL PROTECTED]>
To: Simon Budig <[EMAIL PROTECTED]>
CC: Gimp Developer <[EMAIL PROTECTED]>
Subject: Re: [Gimp-developer] Gimp interface streamlining
Date: Fri, 12 Sep 2003 19:22:54 +0200
MIME-Version: 1.0
On Fri, 2003-09-12 at 11:25, Simon Budig wrote:
> Tor Lillqvist ([EMAIL PROTECTED]) wrote:
> > Or, the arrow keys could be used to finetune the "pressure" and "tilt"
> > while moving the mouse.
>
> Just wanted to point out that since gimpcon it is possible to change
> the opacity with the cursor keys for all Paint tools.
Which I greatly appreciate and thank you for that. But, you know.. It's
kinda awkward for a right-hander to reach for the cursor keys ;)
Ultimately a http://www.eviloverlord.net/powermate.html";>powermate control
would be best.
oooh, wow, /me wants one!

that does sounds like a great control device for use in GIMP though, how 
likely would support be?

Phil.


cheers

--
Jakub Steiner <[EMAIL PROTECTED]>
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
Use MSN Messenger to send music and pics to your friends 
http://www.msn.co.uk/messenger

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

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

[Phil Harper]

From: Alan Horkan <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Screenshot plug-in status
Date: Thu, 11 Sep 2003 18:49:42 +0100 (BST)



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.
well, i am very happy with the way GIMP's clipboard and buffers are kept 
separated from the win32 clipboard, i frequently keep text lying around in 
the win32 clipboard that i may well use frequently, but i very rarely need 
to copy image data outside of the GIMP, and this way i can have all my named 
buffers, i can cut and paste between GIMP images while keeping my text in 
the clipboard for use in text editors and web browsers, handy if you're 
multitasking.

so, on to screenshots, i sometimes use alt-printscrn and acquire, but more 
often acquire screenshot, as that way i don't nuke the contents of the 
clipboard.

i may have completely missed the point here, but i think keeping clipboard 
functions the way they are and maybe adding a paste as new from clipboard 
function along with the others so that acquire doesn't have to be used every 
time.

Phil.

- Alan

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
Sign-up for a FREE BT Broadband connection today! 
http://www.msn.co.uk/specials/btbroadband

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

Re: [Gimp-developer] WikiWordOfTheDay

[Phil Harper]

From: Øyvind Kolås <[EMAIL PROTECTED]>
To: Gimp Developer <[EMAIL PROTECTED]>
Subject: Re: [Gimp-developer] WikiWordOfTheDay
Date: Tue, 9 Sep 2003 12:43:44 +0200

* Roman Joost <[EMAIL PROTECTED]> [030909 10:51]:
> On Mon, Sep 08, 2003 at 11:52:10AM +0200, David Neary wrote:
> >
> > Hi all,
> >
> > I had a few ideas about collaborative content creation for the
> > website and the documentation project recently, and thanks to
> > Carol's forethought, we have the means to do this at our
> > fingertips.
>
> [..]
>
> > So there's the idea. To work, it'll need the cooperation of the
> > documentation team, the web team and the user and developer
> > communities.
> pieces. Unfortunatly, we have some problems for new users and
> contributors to getting involved for writing docs:
>
>   1. Learn how to contribute (what is easier to lern: writing XML docs
>   or learn the wiki syntax)
>
>   2. If we have some docs on a wiki page, how is it possible to convert
>   them to XML? Maybe it costs more time to convert the wiki docs, than a
>   new contributor will lern XML ...
Depending on which wiki is installed,.. changing it to use a more
XML-like syntax (xhtml),.. and using more correct identifiers for the
documentation items shouldn't be too much work.
Parts of xhtml can be mapped to DocBook, but not all (I'm not that
familiar with it)
i forgot to send this to the list last time, anyone tried it?
Wiki2DocBookXML http://freshmeat.net/projects/wt2db/
Phil.

/Øyvind K.
--
  .^.
  /V\Øyvind Kolås,  Gjøvik University College, Norway
 /(_)\   <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
  ^ ^
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
es

_
Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint ShopPro8

[Phil Harper]

From: Alan Horkan <[EMAIL PROTECTED]>
To: Phil Harper <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint 
ShopPro 8
Date: Sat, 16 Aug 2003 20:29:53 +0100 (BST)
MIME-Version: 1.0
Received: from salmon.maths.tcd.ie ([134.226.81.11]) by 
mc1-f24.law16.hotmail.com with Microsoft >On Sat, 16 Aug 2003, Phil Harper 
wrote:

> Date: Sat, 16 Aug 2003 14:15:08 +
> From: Phil Harper <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Gimp-developer] Allow Maximise in Dialogs,
>  like in Paint ShopPro 8
>
> >From: <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )>
> >To: [EMAIL PROTECTED]
> >Subject: Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint
> >ShopPro 8
> >Date: Sat, 16 Aug 2003 14:23:57 +0200
> >
> >On Sat, Aug 16, 2003 at 01:21:05PM +0200, Sven Neumann <[EMAIL PROTECTED]>
> >wrote:
> > > > (Keep in mind that users might be using text sizes larger than the
> > > > defaults so static widget layouts are a really bad idea).
> > >
> > > In general all GIMP dialogs can be maximized and widgets reflow as 
you
> > > described. What are you talking about?
> >
> >File->New is the exception (it's fixed-size), but that's the only 
dialog
> >I could come up with that has this problem.
> >
> >Because that's the dialog most often perceived as dialog, maybe he was
> >assuming all others are the same?
>
> hmmm, yes, it does make you wander if he's ever used the GIMP if he's 
making
> such suggestions...

That was incredibly rude and entirely uncalled for.

- Alan

/me resisting the urge to say more

i'm terribly sorry, forgot to add the ;)

not that this would make the email any less rude i'm sure.

Phil.

_
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger

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

Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint ShopPro8

[Phil Harper]

From: <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )>
To: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint 
ShopPro 8
Date: Sat, 16 Aug 2003 14:23:57 +0200

On Sat, Aug 16, 2003 at 01:21:05PM +0200, Sven Neumann <[EMAIL PROTECTED]> 
wrote:
> > (Keep in mind that users might be using text sizes larger than the
> > defaults so static widget layouts are a really bad idea).
>
> In general all GIMP dialogs can be maximized and widgets reflow as you
> described. What are you talking about?

File->New is the exception (it's fixed-size), but that's the only dialog
I could come up with that has this problem.
Because that's the dialog most often perceived as dialog, maybe he was
assuming all others are the same?
hmmm, yes, it does make you wander if he's ever used the GIMP if he's making 
such suggestions...

--
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED]  |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger

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

Re: [Gimp-developer] GimpCon RFC: Portable XCF

[Phil Harper]

From: Leonard Rosenthol <[EMAIL PROTECTED]>
To: Nathan Carl Summers <[EMAIL PROTECTED]>
CC: The Gimp Developers' list <[EMAIL PROTECTED]>
Subject: Re: [Gimp-developer] GimpCon RFC: Portable XCF
Date: Wed, 20 Aug 2003 10:40:51 -0400
At 8:45 AM -0700 8/12/03, Nathan Carl Summers wrote:
 >	Not necessarily.  You should be able to do it with any format
 with a good catalog system, but some will be easier than others.
How would you handle resizes?  Either we could do immediate compaction or
garbage collection.  Both have their disadvantages.
	Correct.


 > >How about a TIFF-like directory chunk at the beginning (except
 >hierarchical)?

	That would be one solution - sure.
Can you think of a better one?
	Well, it needs to be a directory of some sort - whether it is TIFF-like, 
XML-based, ZIP-like, whatever..


I think the goal of the XCF redesign is to become the de-facto standard
for interchange of layered images.
	Unless you get Adobe to adopt support for it in their applications - that 
simply won't happen!  Whether you like it or not, Adobe is the standards 
bearer in this regard, followed by the other major commercial players - 
Corel, Jasc, etc.
well, it'd be interesting to see if Adobe added XCF to Photo$hop, after all, 
GIMP is the competition, it wouldn't be in their interests to support a 
multilayered image format that it controlled by someone else(although they 
might support PSP, i don't know haven't checked.)

it would be good if Jasc and Corel were to pick it up as a standard 
interchange format, that would put Adobe under some pressure at least.

	And that is also part of my suggestion for using a pre-existing format 
like TIFF or PSD.  There is always wide support for them...
but that means you'd have to leave out any new improvements to GIMP layer 
handling that are made, otherwise you'd be breaking compatibility with the 
"standard"(yes, that is a joke), PSD is only fully supported really by 
adobe, if we're going to have a standard file format that's simply a broken 
version of PSD5 i don't see much point.

as for TIFF, you wouldn't be able to do it in a standard readable TIFF, 
you'd need to update the format entirely, or simply break it, which, again, 
defeats the object.


In other words, any XCF
reader should be able to read any XCF writer's output.
	A reasonable requirement, to an extent.  Do we expect that every XCF 
reader support ALL features of XCF?
i wouldn't expect them to, some would only want to produce a thumbnail, as 
with Nautilus, but i guess the standard decoder could provide a way of doing 
that anyway.


 A layered TIFF by that name wouldn't cut it, because most tiff readers 
don't support layered images.
	Sure they do!  Well, at least for any program that supports multiple 
layers/pages to begin with.  And this goes to the question above...
can you post a multilayer TIFF somewhere for me to try out, i've never 
encountered one before, and it would be interesting to see how it's handled.

	If my application doesn't support a particular feature of XCF, am I not 
compliant?  Should I not bother doing XCF?
it'd be nice if your app could read and render a flat version of the image 
if you don't support layers i supose, this is an interesting one since all 
these different target apps will handle things like layermodes differently, 
and some wouldn't even be supported.


 Of course, we could always use TIFF internally but call it XCF.
	We could do that.

	Adobe does that with .ai, which is really .pdf...
i thought it was a kind of encapsulated post script


We might want to change the magic number as well.
	Wouldn't do that, since the whole idea is to maintain compatibility...
no, that simply wouldn't be flexible enough, surely, i mean you could have 
extra data about how do use the layers in the TIFF but if those aren't 
recognised by other readers you just get a strange result and a confused 
decoder.


I have no problem with basing Portable XCF on TIFF.  It seems to be well
designed without really being too overdesigned.  On the other hand, I
think there are a few improvements that we could make to make it better
for the purposes of GIMP.
	I agree, though I think we can add all of these through additional tags 
and not having to redesign...
i'm sure it's fine for a basis, but not to keep compatible with the existing 
TIFF format.


/me wonders if the CinePaint people have any thoughts...


	Definitely!
hmmm, yes, would be interesting, but they're sticking with their current 
tree aren't they, they wont make the eventual move to GEGL, and i thought 
this discussion was about the XCF version designed for it.

Phil.

Leonard
--
---
Leonard Rosenthol

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

Re: [Gimp-developer] GimpCon RFC: Portable XCF

[Phil Harper]

From: Leonard Rosenthol <[EMAIL PROTECTED]>
To: "Phil Harper" <[EMAIL PROTECTED]>,[EMAIL PROTECTED]
Subject: Re: [Gimp-developer] GimpCon RFC: Portable XCF
Date: Wed, 20 Aug 2003 20:54:55 -0400
MIME-Version: 1.0
At 11:42 PM +0000 8/13/03, Phil Harper wrote:
well, it'd be interesting to see if Adobe added XCF to Photo$hop, after 
all, GIMP is the competition, it wouldn't be in their interests to support 
a multilayered image format that it controlled by someone else(although 
they might support PSP, i don't know haven't checked.)
	They support a number of formats that they don't control - because they 
are standard formats that their customers are requesting.   But today XCF 
isn't one of them, and probably won't be for a while.
the last thing Adobe wants to do is support XCF, it's a competing format 
belonging to a competing(and competatively priced) app.


it would be good if Jasc and Corel were to pick it up as a standard 
interchange format, that would put Adobe under some pressure at least.
	It might, but again, I can't see them doing it.  What's the ROI for them 
to invest in this?   They already support PSD and TIFF as the two richest 
formats for layered raster images.  (not to mention PS and PDF).

there's very little, but eveything else seems rather speculative at this 
stage, so why not.


but that means you'd have to leave out any new improvements to GIMP layer 
handling that are made, otherwise you'd be breaking compatibility with the 
"standard"(yes, that is a joke),
	That is true, and a big reason to not use PSD...


as for TIFF, you wouldn't be able to do it in a standard readable TIFF,
	This, however, is wrong!   We can represent EVERYTHING in GIMP today, and 
EVERYTHING for GEGL (etc.) in the future with TIFF. And other programs 
simply will ignore them as they do with other features of TIFF they don't 
support.

why would i want to save to a file format that would render my image that's 
built up of layer masks and vector text layers really badly if opened in a 
standard viewer rather than in a format engineered from the ground up for 
all of the requirements i could have, and that is distinctive as being a 
GIMP image format, rather than just a really ugly TIFF?


can you post a multilayer TIFF somewhere for me to try out, i've never 
encountered one before, and it would be interesting to see how it's 
handled.
	Easy enough to create one with ImageMagick using a bunch of other files.

	convert a.png b.jpg c.gif +adjoin output.tiff
thanks i might try that.


it'd be nice if your app could read and render a flat version of the image 
if you don't support layers i supose, this is an interesting one since all 
these different target apps will handle things like layermodes 
differently, and some wouldn't even be supported.
	EXACTLY my point!

	Whatever file format we end up with, we need to accept that not all 
consumers of that file format will be able to support 100% of the features 
(perhaps not even GIMP itself).

so why use a format that all consumers would expect to be able to utilise 
100%, it would surely confuse the hell out of your average photo$hop users 
to use TIFF in this way, especially if we're looking at cross compatibility.


	Adobe does that with .ai, which is really .pdf...
i thought it was a kind of encapsulated post script
	It was through version 8, but since version 9, it has been PDF...
ah, i see


no, that simply wouldn't be flexible enough, surely, i mean you could have 
extra data about how do use the layers in the TIFF but if those aren't 
recognised by other readers you just get a strange result and a confused 
decoder.

	You could get that just as easily with XCF when a given consumer/reader 
doesn't support 100% of the features of the format...
in which case you'd have to do something about a workaround, like maybe have 
an optional pre-rendered version of the image stored in the XCF for viewers 
that don't support it properly, but, at that point it's questionable that 
you'd want to view an XCFin something other than GIMP, remember, GIMP has 
this handy thing called export, if your target audience wont be able to read 
an XCF then don't give them one, give then a PNG instead.

Phil.

Leonard
--
---
Leonard Rosenthol
<mailto:[EMAIL PROTECTED]>
 			 <http://www.lazerware.com>
_
Use MSN Messenger to send music and pics to your friends 
http://www.msn.co.uk/messenger

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

Re: [Gimp-developer] [FEATURE] Some plug-in settings should bepersistent accros

[Phil Harper]

From: Raphaël Quinet <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer]  [FEATURE] Some plug-in settings should be 
persistent accross sessions
Date: Tue, 5 Aug 2003 09:45:46 +0200

On Fri, 25 Jul 2003 22:23:23 +0200, David Neary <[EMAIL PROTECTED]> wrote:
> http://bugzilla.gnome.org/show_bug.cgi?id=63610
[...]
> It would be nice if preferences for plug-ins survived session
> changes. The way to do this might be in saving them to an rc file
> without providing an interface to changing them in the normal
> preferences dialog (this might be handy enough although Sven
> might have something to say about it).
I doubt that we can do this in the Right Way before the next release.
Saving these preferences should be done by the core through a well-
defined interface.  That's why I added a dependency on bug #101604,
which tracks the changes to the PDB and plug-in API.
this has got to be optional, i do not want plug-ins keeping settings accross 
sessions, at the moment they keep settings during a session and that's fine 
for me, but when i start up i expect the defaults personally.

> Basically some discussion is needed. Currently, the jpeg defaults
> suck. I would suggest following the advice in this bug and
> changing the default quality to 85%. Currently this is hard-coded
> in the plug-in.
This is something that can be done easily.  In fact, I have just done
it.  I have increased the default quality to 85%, which seems to be
a better default for most (?) users.  I have just committed this
tiny change to CVS.  This should take care of the most annoying part
of this problem, while the bigger issues can be taken care of later.
-Raphaël
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] A fresh pair of eyes.

[Phil Harper]

From: Alan Horkan <[EMAIL PROTECTED]>
To: Phil Harper <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] A fresh pair of eyes.
Date: Sun, 3 Aug 2003 03:02:57 +0100 (BST)
MIME-Version: 1.0
On Sat, 2 Aug 2003, Phil Harper wrote:

> >Alan Horkan <[EMAIL PROTECTED]> writes:
> >
> > > so how do you scroll sideways (using the wheel)?
> > > is this the same keybinding as Photoshop?
> >
> >Dunno what PS uses but GIMP uses Ctrl.
> is there some plan that everything in GIMP should fall inline with
> Photo$hop? those who already use the old ways of doing things probably 
wont
> like having their workflow messed with further.

Not officially.  In fact there seem to be people actively resisting it who
insist on being differnt just for the sake of being differnt.
Clone first and innovate later.

Follow standards, even defacto standards unless there is a damned good
reason to do otherwise.
make every window manager and desktop just like windows, and every graphics 
app just like photoshop, every vector app just like illustrator...

i personally see more importance in following a defacto standard in an app 
like Gnumeric or Abiword than in something like GIMP, but that's probably 
just me.

The GIMP itself is a defacto standard, ask the average Linux/BSD user
about image editing and they will recommend the GIMP for just about
everything, not many know well enough to recommend Image Magic for batch
proccessing.  I know there are a few simpler image editing programs but
users end up getting thrown in at the deep end and told to just learn to
use the GIMP.
or sometimes people offer to help them in their learning and suggest that 
they might want to read a book to help, i supose this is a good chance for 
the second edition of Grokking the GIMP though(any plans anyone know?) :)

I am increasingly noticing that quite a few applictions copy the GIMP and
if I ever want to get them to change I am unfortunately going to have try
and change the GIMP first or at the very least get people to admit that
they have absolutely know idea why things are done a certain way except
that the are already that way.
The "old ways" aaah, you may notice the GIMP has changed quite a bit since
1.2 and needs to keep on changing.  The old keybindings could and should
be put in a "old ways"  menurc so that we can get on with making a
powerful image editor that caters to a wide audience with user friendly
defaults (see Ctrl+Shift+Z for details).  The older users are also the
people most easily able to change and adapt to new but reasonable
defaults.
This may seem like a bit of a rant but really ... I dont even know myself
anymore but it is things like this that annoy me so much that I had no
choice but to stick my nose in and keep making my opinions known.
i still don't understand why the keybindings would need to fall inline with 
P$  simply to make the sofware apeal to a wider audience, there are lots of 
die hard adobe users who will never even try GIMP, and then there are the 
win32 GIMP users, a lot of who know little about configuring their GIMP, 
but, have learned the old way of doing things, and would like to continue 
working in that way, there is already an optional set of P$menurc settings 
isn't there, so if people want that they can have it, but i personally don't 
much like the idea of thrusting it upon them as a default, i will adapt to 
the new settings with time, and the phasing out of 1.2, but really, i don't 
think there's a need to.

and if other software copies the GIMP's way of doing things then surely it 
can't be that bad a way, changing GIMP 2.0 won't neceseraly make all those 
apps which do so fall inline with the new stup, in fact it may introduce yet 
another set of keybindings for those poor linux users to contend with.

anyway, this is very much a ranty and emotive issue, but probably not an 
important one, they've changed, we must just accept that i guess.

Phil.

Sincerely

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


_
Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] A fresh pair of eyes.

[Phil Harper]

From: Sven Neumann <[EMAIL PROTECTED]>
To: Alan Horkan <[EMAIL PROTECTED]>
CC: gimp developer list <[EMAIL PROTECTED]>
Subject: Re: [Gimp-developer] A fresh pair of eyes.
Date: Sat, 02 Aug 2003 09:48:50 +0200
MIME-Version: 1.0
Hi,

Alan Horkan <[EMAIL PROTECTED]> writes:

> so how do you scroll sideways (using the wheel)?
> is this the same keybinding as Photoshop?
Dunno what PS uses but GIMP uses Ctrl.

is there some plan that everything in GIMP should fall inline with 
Photo$hop? those who already use the old ways of doing things probably wont 
like having their workflow messed with further.



Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

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

Re: [Gimp-developer] Wrong terminology in color picker tool

[Phil Harper]

From: Daniel Egger <[EMAIL PROTECTED]>
To: Sven Neumann <[EMAIL PROTECTED]>
CC: Gimp Developer <[EMAIL PROTECTED]>
Subject: Re: [Gimp-developer] Wrong terminology in color picker tool
Date: 29 Jul 2003 13:39:02 +0200
MIME-Version: 1.0
Am Die, 2003-07-29 um 10.33 schrieb Sven Neumann:

> The shape displayed is what's used to sample, that's not a question.
> Make it configurable doesn't seem like a good idea here. I guess most
> people will agree that a circle is the natural choice.
I don't. The colorpicker ist quite handy to determine the average color
in some area and a square is much more natural to handle. Also for a
circle to be somewhat usable you'd have to take the in/out coverage of
the pixels under the radius into account or you'll get disturbing
results for small sizes.
i would tend to agree, if i want an average for an area i will usually be 
after a square anyway, however, it would be good to have a checkbox to 
switch between circular and "classic" behaviour, i don't know how much of a 
concern this is but surely you should be keeping inline with what the 
installed userbase are used to and are happy working with more than 
pandering to the Photo$hop audience...

Phil.

--
Servus,
   Daniel
<< signature.asc >>
_
Tired of 56k? Get a FREE BT Broadband connection 
http://www.msn.co.uk/specials/btbroadband

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

Re: [Gimp-developer] Grain modes are just the beginning - wasMcFarland's Re: St

[Phil Harper]

From: Sven Neumann <[EMAIL PROTECTED]>
To: "Joao S. O. Bueno" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer]  Grain modes are just the beginning - was 
McFarland's Re:  Startup Notification support...
Date: Tue, 29 Jul 2003 10:38:02 +0200
Hi,

"Joao S. O. Bueno" <[EMAIL PROTECTED]> writes:

> For example, this is the line in current gimp code that does the
> "merge mode" :
>
>  sum = src1[b] + src2[b] - 128;
>
> It will be doable by typing:
> ED = E1 + E2 -0.5;
>
> as the custom layer mode. (E stands for "every channel". A is already
> used for alpha -  I myself dislike the "every", and will accept other
> suggestions)
>
> The advantadges? Even the above formula throws information away - it
> kees a better average than ADD layer mode. With the custom layer
> mode, you willbe able to adjust the cnstante factor for every layer
> on every image.
> Thus if it is too light, with large white only areas, one will just
> have to edit the layer mode expression from the above to:
> ED = E1 + E2 -0.7;  , for instance.
I don't want to discourage you and it's certainly a nice expert/geek
feature but I doubt that the casual GIMP user wants to type in any
formulas.
Sven
well, it's certainly something that is of interest to me, and surely it 
wouldn't be a problem to have the extra layer modes at the bottom of the 
drop down list as well as a create new mode option which can optionally add 
it to a user list of modes or just save it in the XCF being processes.

just an idea, and sorry if it's already been covered.

Phil.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentativeGIMP 2.0 r

[Phil Harper]

From: Tor Lillqvist <[EMAIL PROTECTED]>
To: Alan Horkan <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: (LONG) Problems with the GIMP (was: Re: 
[Gimp-developer]tentative GIMP 2.0 release plans)
Date: Sun, 27 Jul 2003 23:22:07 +
Alan Horkan writes:
 > Any chance of binaries [for Win32] for testing?

If you ask nicely, I might be presuaded to zip up what I've
got... (Just built it on Win32 for the first time in a while.)
i'd certainly be very very greatful indeed if you'd do that, please...

thnks

Phil
 > And what compiler did you use (wondering if I'll be able to get 
gtk-wimp
 > to work with the Gimp 1.3 on windows).

gcc version 3.2.3 (mingw special 20030504-1)

One irritating thing with GIMP on Windows currently is GTK bug
#112402, I really need to fix that soon. GIMP's toolbox and some other
windows are currently positioned with their title bar exactly off
screen.
There also seems to be some handle leak when GIMP is starting up and
queries all the plug-ins. Also, something needs to be done to #98737
soon. (Perhaps related, I had to start GIMP at least four times before
it got past all the plug-ins and wrote out the pluginrc file.)
--tml

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
Sign-up for a FREE BT Broadband connection today! 
http://www.msn.co.uk/specials/btbroadband

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

Re: [Gimp-developer] User preference was (Startup Notificationsupport...)

[Phil Harper]

From: Alan Horkan <[EMAIL PROTECTED]>
To: Patrick McFarland <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Startup Notification support...
Date: Sun, 27 Jul 2003 03:27:06 +0100 (BST)
MIME-Version: 1.0
On Sat, 26 Jul 2003, Patrick McFarland wrote:

> On 26-Jul-2003, Daniel Egger wrote:
> > I think the problem is that 1.2 is far more used in productive work
> > because artists and designers are afraid running software which is
> > stamped alpha or beta more than just occasionally.
>
> Wrong, Im an artist, and I prefer 1.3 over 1.2.
"One Swallow does not a summer make".
indeed

Normal users in general abhor using anything labelled beta,
consider your self extraordinary.
depends, there's not really any such thing, especially when it comes to 
linux users, but i agree in general users are scared of software labelled 
beta or unstable, but most "users" don't understand the significance of an 
odd version number ;) and are often quite happy to try out a developers 
version.

and then there are the win32 users who wont use software unless it's got a 
beta, alpha or internal testing(longhorn (l)users) tag, but wouldn't know 
where to start with real software. these people don't seem to have any 
concerns about being beta testers for M$ and think what they do is really 
1337...

The quality of most proprietary software has even caused users to distrust
N.0 release and wait for the first or second service patch.
again this depends upon the type of users you refer to, but generally that's 
true, if they're paying for the software at any rate.

If you can build from source then you are probably more developer than
user anyway.
on linux that's nothing special really, no offence intended, it's simply 
made really nice and easy to do.

While it is great that there are GIMP users willing to make the
extra effort to use 1.3 I really hope to see GIMP being used by everyone
else.  The sooner we stamp out piracy of Adobe Photoshop the bettter :)
i'm frequently suggesting 1.3.x to users, and they're often more than 
willing to give it a try, even if they don't have much *nix knowledge they 
can generally handle building and installing, which is great to see :)

Phil.
--
"Tell me where is the love in what your prophet has said
Man, it sounds to me just like a prison for the walking dead"
http://www.biggyp.tk/ - GIMP Tutorials and SEAL2 themes
http://gug.sunsite.dk/gallery.php?artist=123 - Gallery
http://biggyp.deviantart.com/ - Other Gallery


Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
_
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger

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

Re: [Gimp-developer] ANNOUNCE: gimp-plugin-template 1.3.1

[Phil Harper]

great to see a new development release again, i will definately
update my GTK in order to build this one :)
i played around with the Wilber Construction kit some time ago and
added some shiny higlights, i've just uploaded it to
http://gug.sunsite.dk/gallery.php?artist=123 if you want to have a
look and maybe use it if you like the additions.
Phil.

Hi,

going hand in hand with the 1.3.17 release, there's now an updated
version of the gimp-plugin-template available from
 ftp://ftp.gimp.org/pub/gimp/plugin-template/

The template has been relicensed to a less restrictive X11-style
license (thanks to Adam for his patch) and was updated to follow the
GIMP-1.3 API changes. It requires at least GIMP-1.3.17. If you want to
write a larger plug-in for GIMP 2.0, this package should give you a
good start.
Sven
_
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger

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