Re: [Gimp-developer] AUTHORS.xml

[Kelly Martin]

Carol Spears wrote:
1) do we still keep Spencer Kimball and Peter Mattis as the authors and
everyone else as a contributer? Or everyone could be an AUTHOR or
everyone could be considered a CONTRIBUTER.  I am unable to have an
opinion on this and would really like to hear the opinions of a few
others.
I would be offended if Messrs. Kimball and Mattis were no longer listed as the 
primary authors.  I see no reason to deviate from the current practice.

Back in 1999 we weren't able to figure out who some of the people in there were. 
 We left them in anyway, figuring someone had had a good reason to add them. 
For all I know one of them is Peter's dry cleaner.

The only change I would support is listing the current development lead(s) as 
"This release brought to you by ...".  We didn't do this for 1.0, but I can 
understand why some people feel that they deserve more than to be listed in a 
long scroll of people, many of whom they've never even heard of.

Kelly (the only person listed twice in AUTHORS, as far as she knows)

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

[Gimp-developer] Re: [Gimp-user] The GIMP Foundation

[Kelly Martin]

Dave Neary wrote:

Daniel Rogers wrote:

Avoid self-dealing.


What's this?
Self-dealing is whenever the people who control the organization command the 
organization to do business with themselves in their personal capacity. 
Self-dealing "tears the veil" and makes the director or officer who engages in 
it personally liable for the corporation's debt by creating the presumption that 
the corporation is an "alter ego" of the individual.  In the case of a 
non-profit, it also violates the rule against private inurement.

It means, inter alia, that the directors of the non-profit cannot also receive 
money from it except possibly a small stipend and reimbursement of their 
expenses in attending board meetings and other organization functions.  Being a 
member of the board of a non-profit organization is charity work: you generally 
cannot expect to get paid.

If you're looking to get a job with the GIMP Foundation, you can't also be a 
member of its board of directors (except as an ex-officio member, which the 
Executive Director typically would be).  This doesn't mean that the Foundation 
can't hire staff, just that those staff can't be the ones making the ultimate 
decisions on how to spend the organization's money.  Staff can recommend, but 
final approval of at least the general budget has to be by the volunteer board. 
 To do otherwise risks a finding that the organization inures to the benefit of 
a private party, which destroys non-profit status.

I'm very interested in the idea of a Foundation and would love to be a part of 
one, but I have no expectation of it turning into a personal revenue stream.

Kelly

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

Re: [Gimp-developer] The GIMP Foundation

[Kelly Martin]

Nathan Carl Summers wrote:

If you are a board member you must:
Attend board meetings.
Is this required to be in person, or is conference call/irc/email/etc
sufficient?  Furthermore, is it possible for board members to be
reimbursed for expenses?  I can see this being a major obstacle for non-us
residents otherwise.
Most states require that such meetings take place "so that all present may hear 
one another".  This permits conference calls, but excludes IRC and email.

Instead, I would like to see the ability to give TGF power-of-attorney to
sue copyright violators in their behalf.
That's a touchy area.  Copyright law in the United States requires that a suit 
to enforce copyright be brought "in the name of the party in interest".  (The 
RIAA is running into problems with this because they're not the "party in 
interest" of any of the copyrights they're suing on.)  There really isn't a good 
way around the assignment issue.

Kelly

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

Re: [Gimp-developer] more gimp foundation stuff

[Kelly Martin]

Daniel Rogers wrote:

1.  I heard that some people have been asked to be on the board, why
weren't the developers consulted?  I'm a developer, why wasn't I asked?
Who are these board members?
Keep in mind that developers will not necessarily make good board members.  The 
sort of decisions that a board of directors has to make really don't have that 
much in common with those made by a developer.  Developers need to be involved 
in the operation of the foundation, but it's unrealistic to expect a majority of 
the board to be active developers.  It might even be counterproductive.

Kelly

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

Re: [Gimp-developer] The GIMP Foundation

[Kelly Martin]

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?

Kelly

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

Re: [Gimp-developer] The Mark Shuttleworth offer

[Kelly Martin]

Dave Neary wrote:

We could even consider having a quickish stable release after 2.2 with 
just GeglImage replacing GimpLayer, which would give us a chance to work 
out any wrinkles in that milestone before we start really relying on it...
Unless the code has changed a lot and I haven't noticed it (and looking I see it 
hasn't), you should be redesigning GimpDrawable (not GimpLayer) to inherit from 
GeglImage.

I'm not sure whether having GimpImage inherit from GeglNode, or contain a member 
GeglNode, makes more sense.

Kelly

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

Re: [Gimp-developer] The Mark Shuttleworth offer

[Kelly Martin]

Michael Natterer wrote:

Actually no. GimpDrawable is a GimpItem is a GimpObject. It should
*have* a GeglImage, not be one.
Yes, this is probably correct.  Tempbufs should probably also be replaced by 
GeglImages, and the entire paint core replaced by GeglOp-related operations.

As I see it, GimpImage would contain a GeglNode, rather than inherit from it. 
There would be a contained GeglNode that would represent the current projection; 
it would be created from the existing layer & channel lists.

Part of the problem is that GeglNode can represent combinations that the GIMP 
doesn't support, and adding the UI support for those combinations is 
(remarkably) nontrivial.  Also, there is not a one-to-one correspondence between 
GeglNodes and GimpLayers (some layers will generate only one GeglNode, others 
several, especially when layer masks are in use).  Relying on "decompiling" the 
GeglNode to generate the Layers & Channels dialog seems unwise.

Kelly

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

Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)

[Kelly Martin]

Simon Budig wrote:

Ok, thinking some more about it: What about using symbols as parameter
identifiers?
  (script-fu-foo-bar 'imageimage
 'drawable drawable
 'radius   5.5
 'size 300)
passing symbols to the PDB doesn't make sense, so this could be used
to differentiate.
The more Scheme-like approach would be to add a read syntax which instantiates a 
"parameter name" type.  So, something like "(script-fu-f00-bar ::image image)" 
(:: being an arbitrary syntactic marker that I just made for which an 
appropriate syntax macro has been defined; you can theoretically use anything 
not already assigned to something else), which is internally expanded to 
"(script-fu-f00-bar # image)" which is then magically converted 
to however the PDB handles parameter passing by the appropriate Scheme-C glue code.

Not only is this more in keeping with how Scheme is generally used, it's 
conceptually much cleaner because it avoids overloading quoted interned symbols.

Kelly

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

Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)

[Kelly Martin]

Kevin Myers wrote:

(script-fu-foo-bar image="myimage" size=300)
Defining syntax macros for such a syntax in Scheme is less than straightforward, 
and is also very un-Scheme-like.

Kelly



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

Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)

[Kelly Martin]

Kevin Myers wrote:

You seem to know what you're talking about Kelly, so I'll have to accept
your word that my suggestion is un-Scheme-like.  However, please verify one
thing regarding your suggestion:  How do you handle parameter values with
imbedded blanks or other "special" characters?
(True) Scheme has a quoting mechanism for this issue, which is relatively well 
defined.  It might be tricky to quote those quotes when you're using an inferior 
command shell (such as Windows Explorer), but this should be considered a fault 
of those environments -- and is certainly no reason to abandon the R5RS standard.

Kelly

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

Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)

[Kelly Martin]

Kevin Myers wrote:

Hi Kelly,

I understand your basic points, but...

Admittedly, the Windows command prompt (not simply Explorer) is less capable
than most *nix command shells.  However, there are also a very large number
of Windows based GIMP users, and one of the requirements of GIMP 2.x is that
it should be as usable under Windows as it is on other operating systems.
I'm not familiar with R5RS, and you could certainly be right in your opinion
regarding that.  However, as a Windows GIMP user (and much more rarely a
GIMP bug, patch, fix, and enhancement contributor), I want to make sure that
there isn't excessive *nix bias that inhibits or ignores usability needs
under Windows.
Windows inhibits its own usability in this respect.  It is nearly impossible to 
get imbedded quotes from the Windows command line.  This is a defect in the 
Windows shell.  Getting around it would force us to use some weird character for 
string quoting, which would be confusing to everyone.  In my opinion, the 
sacrifice is not worth the gain: we should not have to do something Weird and 
Bizarre to cope with Microsoft's inferior product.

Kelly

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

Re: [Gimp-developer] making plans

[Kelly Martin]

Dave Neary wrote:
I could be convinced that having a release in 3 months is the right 
thing (I am under no illusions though - if I disagree with it, that 
won't necessarily influence the eventual decision). It would depend on 
the feature lists we compile over the next few days/weeks.
I think a goal of a 2.2 release in three months is a good one, which means the 
feature list that gets accumulated should have anything that can't be 
implemented in that time removed from it.  If that makes for too few features, 
then either add one or two more.  I wouldn't push the release date back much 
more than that.

That probably means that a feature freeze in one to two months is appropriate. 
There's a lot of little stuff that people have been holding off on; surely 
there's enough of those to fill the next three months.  Save the Big Stuff for 
2.4/3.0.

That's my two cents on the matter, at least.

Kelly

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

Re: [Gimp-developer] PDB requirements

[Kelly Martin]

Manish Singh wrote:

I was asking more in terms of an API should look like. Interactive
paint is more involved than say, a bucket fill, which is easily translated
into to "call PDB bucket fill function on button release".
Especially when you consider the airbrush, which has time sensitivity as well as 
motion sensitivity.  The general paint UI (used for paint/pencil/erase, clone, 
smudge/dodge/burn, and airbrush, IIRC) has to generate an drawing event for each 
drag.  The airbrush also has to generate one for each timer tick while the mouse 
is down, whether or not a drag occurred.  The other tools generate only one 
drawing event, at mouse release.  The lasso can probably only generate one 
drawing event, at mouse release, but its event structure is considerably more 
complex than the rest.  I'm not sure about the various vector-related tools.

This is nonsimple to begin with, and making it efficient is even more complex. 
You don't want substantial redraw delays while painting.  I am not sanguine on 
getting this implemented in the desired three month window.

Kelly

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

Re: [Gimp-developer] PDB requirements

[Kelly Martin]

Manish Singh wrote:

We could simply bypass the pdb for painting, and just emit "record this"
on button release. But maybe it'd be better to have the pdb more involved,
I dunno.
You'd at least have to serialize all the events for the paintbrush and airbrush 
if you want the macro to be brush- and color- independent (that is, you are 
interested in capturing the motions used, rather than the result).  You could 
save the serialization in a buffer and then spew it forth at the end, but I 
don't see any way around collecting the actual paint events.

This was a requirement when I was asked to this by my former employer back in 
2000, and also a requirement for the guy who was trying to contract Wilberworks 
to do it back in 1998.  I think a macro recorder that doesn't capture motion 
events will be of limited utility to users.

Kelly

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

Re: [Gimp-developer] PDB requirements

[Kelly Martin]

David Neary wrote:
Perhaps I'm being over-simplistic, but couldn't we go for the
partial solution of just recording plug-in events, via the
existing PDB interface, and get ourselves most of the
functionality that people need for very little effort?
It's really not all that useful if we don't have paint event recording.

Kelly

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

Re: [Gimp-developer] Refactoring code from GPL to LGPL

[Kelly Martin]

Dave Neary wrote:

A GIMP plug-in is a completely different process space than the GIMP 
core. Information is passed via a wire protocol which is implemented at 
both ends using LGPL code. I don't see how this is different from 
viewing the GIMP as a server, and the plug-in as a client. Or 
alternatively, the PDB as a broker and both the plug-ins and the rest of 
the core as clients.
We specifically moved libgimp from GPL to LGPL to allow for the possibility of 
proprietary plugins.  Spencer and Peter affirmatively agreed to that change when 
it was made.  That was either late in the 0.99 cycle or early in the 1.0 cycle, 
although I forget which.  Yosh should remember.

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

Re: [Gimp-developer] Refactoring code from GPL to LGPL

[Kelly Martin]

Robin Rowe wrote:

How do you get permission to move GIMP code from GPL into LGPL?
You get the explicit permission of everyone who's ever contributed to the code 
in question.  For the entirety of the GIMP, that's about 100 people.

I can tell you right now that I object to relicensure, which means you're going 
to have to exclude anything I've ever written.  Good luck with that; I'm 
responsible for some pretty substantial parts of GIMP's infrastructure code.

Kelly

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

Re: [Gimp-developer] Joining the GNOME Foundation

[Kelly Martin]

Daniel Rogers wrote:
No no, I'm talking about general funds.  Not sure if GNOME would 
withhold funds specifically given to us, that is a slighly different 
situation.  I am talking about funding from GNOME's general pool of 
funds.  Also, I don't actually expect them to do something like this. 
GNOMe wants to help us.
A non-profit that receives a restricted donation is legally prohibited from 
using it for any purpose other than that stated in the restriction.  If the 
non-profit receiving the donation is unwilling to accept the restriction, it 
must refuse (or return) the donation.

So if you give money to the GNOME Foundation with a codicil that it be used to 
further GIMP development, they can't legally use it for any other purpose. 
However, the codicil is interpreted pretty strictly, so "to further GIMP 
development" is too vague and they could use that to cover administrative costs 
on the grounds that that "furthers GIMP development".  You'd have to give money 
with a pretty strong codicil ("these funds shall be used only to pay the wages 
of not more than five developers to work on the implementation of feature X in 
product Y") to ensure that all the money you give will get to the project you 
want.  And most donors simply don't bother to have their lawyers go over their 
gift endorsement before signing the check.

I'd be very surprised if the GNOME Foundation passed along *all* funds untouched 
donated with a simple earmark for the GIMP to the GIMP people; I would fully 
expect them to take an "administrative fee" of between 5% and 50% (maybe even 
more).  You might want to have an agreement in writing on this point before you 
start using them to fundraise.

Kelly

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

Re: [Gimp-developer] Joining the GNOME Foundation

[Kelly Martin]

Daniel Rogers wrote:

Dave neary and I talked to Tim Ney about this.  There is goign to be a 
small cut taken by TGF.  It is very close to the lower end of your 
range, but I won't know specifically until the board approves the number 
(which they are supposed to do soon).
Another matter you should have made clear and in writing: in the event that you 
do choose to spin off and separate from them, you should be able to withdraw all 
earmarked funds (less any agreed administrative levies) to start the new 
organization.  Absent such an agreement, you'll be on their grace to get those 
funds, which might not be available if the parting is on less than best terms.

Remember: I went to law school.  I've been trained to contemplate the worst that 
can happen and so must mention it, even I don't expect it to.

Kelly

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

[Gimp-developer] [patch] Major speedup for whirl&pinch plugin

[Kelly Martin]

On Thu, 5 Apr 2001 19:04:10 +0200, Georg Acher <[EMAIL PROTECTED]> said:

>Hi, I don't know who's currently "responsible" for the whirl&pinch
>plugin, so I post my patch to this list.

Nominally it's either mine or Federico's, but I don't think either of
us is active in development.

>I have modified whirl&pinch slightly to use "blocking", ie. doing all
>calculations in small squares (32*32). With that technique very
>common in numerical computing, the CPU caches (and for GIMP) the tile
>cache have a much higher hit rate. The boost is quite spectacular:
>The original whirl&pinch on a larger image (1400*1400) needs on a
>Athlon-600 30s to complete, with my patch only 6.5s.  That's a
>speedup by a factor of 4.5 without any change in the algorithm
>itself!

I was under the impression that whirlpinch used tile regions, which
should do blocking automatically.  It's been a couple years since I
looked at the code, though.

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

[Gimp-developer] [patch] Major speedup for whirl&pinch plugin

[Kelly Martin]

On Thu, 5 Apr 2001 12:36:05 -0500, Kelly Martin <[EMAIL PROTECTED]> said:

>>I have modified whirl&pinch slightly to use "blocking", ie. doing
>>all calculations in small squares (32*32). With that technique very
>>common in numerical computing, the CPU caches (and for GIMP) the
>>tile cache have a much higher hit rate. The boost is quite
>>spectacular: The original whirl&pinch on a larger image (1400*1400)
>>needs on a Athlon-600 30s to complete, with my patch only 6.5s.
>>That's a speedup by a factor of 4.5 without any change in the
>>algorithm itself!

>I was under the impression that whirlpinch used tile regions, which
>should do blocking automatically.  It's been a couple years since I
>looked at the code, though.

Hm, it does not.  The issue with whirlpinch is that there's only a
weak locality relationship between destionation pixels (which are
iterated across the image) and source pixels (which are fetched with
the pixel fetcher).  I haven't looked too closely at your blocking
patch, but I suspect that much the same improvement would be had by
using a pixel region (which respects tiles) to iterate across the
destination region.  

Whirlpinch also has an optimization to do the top and bottom whirls
simultaneously to save calculations.  This might actually be more of a
loss because of the locality hit on the tile cache.

If I get some spare time, I might look at this more closely.

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

Re: [Gimp-developer] [patch] Major speedup for whirl&pinch plugin

[Kelly Martin]

On Thu, 5 Apr 2001 20:35:02 +0200, Georg Acher <[EMAIL PROTECTED]> said:

>I don't know how large a tile is

Tiles are 64x64 by default, and changing them is a bad idea because it
makes your .xcf files nontransportable.

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

[Gimp-developer] [patch] unbelievable speedup for bumpmap...

[Kelly Martin]

On Thu, 5 Apr 2001 23:55:57 +0200, Georg Acher <[EMAIL PROTECTED]> said:

>Hi, I just looked into bumpmap.c and tried to figure out if it can
>profit from blocking and played a bit with the code. It seems that
>there is some major (performance) problem with the
>gimp_pixel_rgn_get/set_row-calls in Gimp 1.2.1.

>The original bumpmap took for my 1400*1400 image about 30s, when I
>commented out one of the gimp_pixel_rgn_get/set_row() that access the
>source or the destination image, the whole stuff took only about
>2.4s, while the calculations were still done!

>I experimented a bit, and found out, that apparently the "switch"
>between get and set seems to be the problem. I changed the code to
>get 32 rows, calculate them and the write the 32 back. It took only
>3s overall, the resulting image is the same as with the 30s boiling
>time.

I suspect this is because the libgimp tile cache is too small.
Libgimp allows a plugin to ask libgimp to cache a small (or not so
small, if it wants to burn memory) number of tiles in its own process
space so as to avoid fetches over the wire.  There's a call to
gimp_tile_cache_ntiles in bumpmap.c but it may simply not be large
enough, or there may be a problem with the tile caching code in
libgimp.  

Another thing to look at in my copious spare time. :)

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

Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...

[Kelly Martin]

On Fri, 06 Apr 2001 14:55:32 +0200, Ernst Lippe <[EMAIL PROTECTED]> said:

>Other improvements are still possible. I expect that it should be
>possible to rewrite the algorithm such that the tile cache contains
>only 3 tiles. From what I see the algorithm is the same in the
>horizontal and vertical direction. The current implementation uses 3
>extra buffer-rows so when we add 3 extra buffer-columns it should be
>possible to rewrite the algorithm so that it processes one tile at a
>time instead of a full row.

If the algorithm is pixel-by-pixel (each output pixel depends only on
exactly one input pixel from each region being iterated over, and
those regions are all the same size) there is absolutely no excuse not
to use the pixel region iterator, which will automagically minimize
tile accesses to the lowest number possible.  IIRC, the bumpmap
drawable need not be the same size as the input/output drawable, so a
pure region iterator cannot be used, but at least using the region
iterator for the input & output would limit the use of direct fetches
to the bumpmap drawable.

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

Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...

[Kelly Martin]

>When the output pixel depends on neighboring pixels (e.g. I strongly
>suspect that bumpmap uses a 3 x 3 neighborhood) the region iterator
>does not work very well.

Not on its own.  However, if you iterate the output region with the
pixel region iterator, and use a pixel fetcher like the one in
whirlpinch for the input sourcing, and there is at least some weak
relationship between input and output locality, the standard tile
cache should be enough to obtain decent efficiency.

Obviously, the more you know about your data access patterns, the more
efficient an access strategy you can develop.  

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

Re: [Gimp-developer] [patch] Major speedup for whirl&pinch plugin

[Kelly Martin]

On Mon, 9 Apr 2001 23:02:44 +0200 (CEST), [EMAIL PROTECTED] said:

>On 5 Apr, Kelly Martin wrote:
>>Tiles are 64x64 by default, and changing them is a bad idea because
>>it makes your .xcf files nontransportable.

> Not to forget that this size is more or less hardcoded.

It's a #define, yes.  And because the file format is tightly bound to
the tile size, changing it at compile time breaks XCF save and load in
ways I don't even want to think about.  I don't think that XCF v0 or
v1 specifies the tile size anywhere in the data stream, either.

I tried to modify the XCF loader & saver once to do reblocking, but it
gave me a headache and I moved on to other, more interesting things,
like feeding my cats. :)

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

[Gimp-developer] Can I avoid Gimp creating new coulours ???

[Kelly Martin]

On Fri, 13 Apr 2001 16:06:22 +0100, David Kirkby <[EMAIL PROTECTED]> said:

>Hi, I'm trying to do something with Gimp that is perhaps a little
>unusual.  This is causing me a problem, but I'd like to know if it
>can be overcome easily. I'm using Gimp 1.2.0 on a Sun SPARCstation
>with Solaris 8.

>I would like to create a bitmap (.BMP) with Gimp that can be read by
>a scientific application I have written. This application looks for
>specific colours such as red (0xff), black (0x00), white
>(0xff) and green (0x0x00ff00).

>I need to create an image that uses these colours and *only* these
>colours. However, when I draw a red circle using pure red, on a pure
>white background, the edges of the circle are pink, containing some
>red, and equal amounts of green and blue.

>Likewise if I create a small bitmap (say 5 x 5 pixels) and set these
>pixels to the values I want, expanding the image in Gimp creates
>pixels of intermediate colours.

>I appreciate this is more aesthetically pleasing, but Gimp's
>interpolating colours is causing me a problem. Is there any obvious
>way to stop colour interpolation ?

Use indexed mode.

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

Re: [Gimp-developer] The GIMP Webpage

[Kelly Martin]

On Wed, 23 May 101 10:23:57 -0500 (CDT), [EMAIL PROTECTED] (Miles O'Neal) said:

>I know, I know.  Since we're probably going to rewrite the site in
>something less arcane and more known, now is the ideal time to revamp
>the look and feel.

I hate it when sites change things.  (My credit card company changes
their online customer service system every couple of months and it
drives me nuts.)  There is nothing at all wrong with the current look
and feel, and I see no reason at all to change it.

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

Re: [Gimp-developer] The GIMP Webpage

[Kelly Martin]

On Wed, 23 May 2001 18:21:16 +0200, Christoph Rauch <[EMAIL PROTECTED]> 
said:

>Many sites have never changed since 1995. Some are changing too
>frequently.  With gimp.org we have sort of the first one (even if its
>not THAT old). With a redesign in both content and structure we can
>be more flexible and add more things which are usefull to both new
>and "old" users. The current webpage organises all html-pages in the
>root-direcotry of the server. This is definitely NOT flexible enough.

>Example: http://www.gimp.org/download/ Result: 404 - not found

That's not a "look and feel" issue, it's just a broken link problem
that has nothing to do with look and feel.

>The site-design neednt be redesigned from scratch. It may be enough
>to polish it up and remove the "Gimp-standard-script"-look, which was
>copied all over the web and today has a bit trashy touch. Definitely
>not a good representation for the greatest graphic program on
>earth. :-)

Imitation is the sincerest form of flattery.

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On Wed, 25 Jul 2001 17:57:50 +0100, "Adam D. Moss" <[EMAIL PROTECTED]> said:

>* What are pango and atk, and why do we suddenly require them (if
>indeed we do)?

>* Are there compelling advantages to using CVS-GTK which outweigh the
>cons of forcing developers and users to upgrade?  Is GTK 1.3 not
>backwardly compatible with the GTK 1.2 API?  My concern is that with
>such a casual-user oriented application as GIMP we can easily lose
>users by the wayside with each additional stipulation.

>* For those of us with pieces of the tree's core which diverge
>somewhat from the trunk, how much of a no-brainer is converting our
>code to GTK 1.3-isms?

I would add:

* are there Windows versions of pango and atk?
* do we reasonably expect Windows ports of the HEAD versions of all of
  these libraries before 1.4 is released?

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On 25 Jul 2001 20:12:28 +0200, Michael Natterer <[EMAIL PROTECTED]> said:

>IMHO the pro's outweigh the con's by far, as it's simply not possible
>without grand hacks to write an internal object model and a nice
>generic GUI with Gtk 1.2.

If this is the real reason, then I can understand the desire, but I
would really rather not see reliance on unreleased versions of _any_
library without a compelling reason.

>After all, isn't is just natural for GIMP HEAD to use the GIMP
>Toolkit's bleeding edge version? This is unstable development.

For example, this is a great of example of a reason which is NOT
compelling, or even rational.  

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On Wed, 25 Jul 2001 21:41:03 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said:

>There is cvs, so knowledge about "HEAD doesn't work, try last week's
>version" will spread soon through developer circles. 

This qualifies as one of the worst excuses I've heard yet.

If you have to use a "development" version at least pick a fixed point
in development and use that.  Otherwise you're coding to not one, but
two moving targets: your own code PLUS the moving code in the library
you depend on.  Or, in this case, five.  

If your goal is to make development as chaotic and difficult as
possible, you are on the right track.

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On Wed, 25 Jul 2001 22:59:11 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said:

>It's more of a social problem: do we *trust* the gtk development
>model to be stable most of the time? I did trust the gimp developers
>that they want working code as well, and it worked fine. If gtk+ is
>as chaotic as you think it is, it is evry bad and gimp shouldn't use
>the HEAD revision.

Why should we expect the GTK+ developers to keep their HEAD revision
compilable at every moment?  That is a completely unreasonable
expectation in the first place.  If I were a GTK+ developer I would be
asking that you NOT do what you're proposing because it creates
pressure on them to keep their HEAD "workable" at all times instead of
doing what they need to do in order to further their own development.

If GTK stable release (1.2) is not acceptable for further development
in the GIMP (which it probably is not), I would strongly urge picking
a relatively stable snapshot of GTK+ current development (possibly,
but not necessarily HEAD today) and use that.  We might have to adjust
later to any changes GTK+ makes to its HEAD after that snapshot, but
at least we won't have to adjust to them willy-nilly as they make
them.

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On 26 Jul 2001 00:17:03 +0200, Sven Neumann <[EMAIL PROTECTED]> said:

>you are obviously not well informed about the current state of
>GTK+-2.0.  

No, I don't _care_ about the current state of the development of an
unreleased package.  We should not be using unreleased code.

Why can't we just use 1.3.6?  That's a frozen release that should be
reasonably close to the eventual 2.0.0 release.  Why should we
introduce this sort of instability to GIMP development when we don't
have a good reason to?  When 1.3.7 comes out, we can advance to that.
There is simply NO good reason to be dependent on the CVS HEAD, no
matter how stable the GTK developers think it might be.

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On Thu, 26 Jul 2001 05:13:09 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said:

>because that's what they do, what gimp does, what every other project
>does.

Gimp 1.1.x, as I recall, was set up to work with any GTK 1.1.y for
sufficiently large y.  We bumped y as it became necessary.  The HEAD
revision was only occasionally required, and usually only for a short
time until GTK+ released a new unstable version.

I don't know what "every project" you've worked on.  This is a
completely INSANE model for any project of any size that wants to
actually get anything done.  (Of course, project leadership in most
open-source projects is almost completely nonexistent, but that is no
reason why GIMP development has to be that way.  It wasn't in 1.0, at
least.  I wasn't as involved in 1.2.)

> if the head revision isn't compilable nobody can wotk with it.

Which is precisely why GIMP developers should not rely on it.  GIMP
developers are developing GIMP, not GTK+.

If an individual developer WANTS to work with the head revision,
that's fine, but development should not REQUIRE it, and developers
should be wary of introducing dependencies on features not yet
stabilized.  You should require the OLDEST version that suffices, not
the newest.  (This is a general rule of using libraries, not one
specific to GIMP's usage of GTK+.)  Application authors should NEVER
assume that their users like to live on the cutting edge.  Most users
do not.  I only upgrade the Linux systems that I'm paid to maintain
when something breaks, and we should not force users to upgrade a
nonbroken library unless the upgrade provides essential (or at least
strongly desirable) functionality.

>As sven has said, they made an API freeze recently. That means they
>are already pretty late in the development phase. I think it's
>totally unreasonable to expect non-compilability on a regular
>base. How often couldn't you compile gimp-1.1.2x?

I broke 0.99.x and 1.1.x on several occasions. 

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On 27 Jul 2001 21:30:01 +0200, Michael Natterer <[EMAIL PROTECTED]> said:

>Nick Lamb <[EMAIL PROTECTED]> writes:
>>NB I am not blind and I don't write code in Hebrew

>I respect your extraordinary tolerance regarding this, so please
>respect that the people actually working on a project tend to make
>the decisions.

Please respect the fact that people who used to work on a project may
once again choose work on it, and may have something of value to
contribute notwithstanding their current degree of participation.

On the issue of using GIMP to debug GTK: not all of the people who
might work on the GIMP have an infinite amount of time to dedicate to
this project.  If you have four hours a week to spend on GIMP
development and it takes you two of those hours to get your GTK up to
whatever revision is presently being used, you've just spent half your
time on what amounts to unproductive activity as far as GIMP is
concerned.

I don't do GIMP development right now because I have to work for a
living and don't have 120 hours a week to spend on hacking code for
free.  And given the attitude just expressed, it would appear that
there are better uses for my limited spare time than working on the
GIMP.  Thanks for making this clear for me.

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

>I think we need to ask ourselves why users would want to try the
>latest developer releases of Gimp. If they want to have the latest
>because of having the latest, I don't think they'll mind getting CVS
>HEAD branches and weeding out possible compile problems. 

Think "plugin authors".  These people are going to want to start
working on porting their plugins to 2.0 well in advance of 2.0's
release but are not likely to want to cope with being GTK debuggers on
top of being GIMP debuggers.  

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On Fri, 27 Jul 2001 22:18:32 +0200, Lourens Veen <[EMAIL PROTECTED]> said:

>I may be misunderstanding, I'm not a project expert, but if the Gtk
>API is frozen, the only difference between the CVS HEAD branch and
>the latest developer release is bugfixes right? So then there should
>be actually less bugs in the CVS HEAD. The only risk you are running
>is of it not being compilable, well, as we saw today, that might
>happen with a release as well ;).

"99 bugs in the code, in the code.
 99 bugs in the code.
 Fix one bug, compile again.
 100 bugs in the code, in the code."

Bugs get introduced during debugging quite frequently.  Sometimes they
things get worse before they get better.

>In the end it's a matter of trusting the Gtk developers, or rather
>the CVS maintainers. Do we trust them not to break things too often,
>and if the compile is broken, fix it quickly.

It's not a matter of trust.  It's a matter of recognizing that the
development branch is under development and may break at any time.
Rather than trusting the GTK developers not to break the head branch
of their development code, we should simply abstain from demanding
that promise from them in the first place.  I don't want them going
"Well, we can fix this bug the right way or the wrong way, but the
right way will probably break something those GIMP people are doing
and the wrong way won't.  And we promised not to break their stuff."
I want them to be able to do the right thing and not have to worry
about whether that inconveniences us for a few hours, days, or weeks.

Kelly

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

Re: [Gimp-developer] glib/gtk+ 2.0 port

[Kelly Martin]

On Fri, 27 Jul 2001 22:18:32 +0200, Lourens Veen <[EMAIL PROTECTED]> said:

>I may be misunderstanding, I'm not a project expert, but if the Gtk
>API is frozen, the only difference between the CVS HEAD branch and
>the latest developer release is bugfixes right?

No, because the HEAD branch could contain preliminary attempts at
bugfixes that don't actually fix the bug or which introduce new bugs.
I expect things like that to appear (and subsequently disappear) from
time to time on the development head.  In my experience, a bugfix will
appear on the head branch once the developer who found the bugfix has
verified that the code compiles with the fix and appears to fix the
bug, but before the bugfix has been thoroughly tested by other
developers.  

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

Re: [Gimp-developer] Re: patch for gimp/po/fr.po

[Kelly Martin]

On 29 Aug 2001 10:59:06 +0200, Sven Neumann <[EMAIL PROTECTED]> said:

>One more thing to consider: Localisation in GIMP HEAD is considerably
>broken since we have to switch all the po files to UTF-8. You can
>create some nice crashes if you try to start GIMP from CVS HEAD with
>LC_ALL != C since GTK+-2.0 doesn't like to be passed invalid UTF-8
>strings.

Has this been reported as a bug in GTK?  

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

Re: [Gimp-developer] Re: patch for gimp/po/fr.po

[Kelly Martin]

On 29 Aug 2001 14:44:49 +0200, Sven Neumann <[EMAIL PROTECTED]> said:

>>Has this been reported as a bug in GTK?

>Huh? It's not a bug, it's a feature. All strings in GTK+-2.0 are
>UTF-8 encoded and the application has to assure that only valid UTF-8
>strings end up at the toolkit level. This is the only reasonable
>solution to the encoding mess and it works just perfect.  It allows
>for example to have different languages with different "native"
>encodings in the same widget. Why do you consider this a bug?

In my opinion, a library which crashes when fed inappropriate external
data is buggy by definition.

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

Re: [Gimp-developer] Re: patch for gimp/po/fr.po

[Kelly Martin]

On Thu, 30 Aug 2001 10:05:15 +1000, Stephen Robert Norris <[EMAIL PROTECTED]> said:

>So it's the library's fault if I pass it a bad pointer and it causes
>a SEGV?

Yes.  

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

Re: [Gimp-developer] Re: patch for gimp/po/fr.po

[Kelly Martin]

On 29 Aug 2001 16:59:18 -0500, Larry Ewing <[EMAIL PROTECTED]> said:

>Ah so it is the libraries fault that it crashes when you pass it an
>unterminated string?  

Yes, in this case bad design on the part of the library designer for
allowing such behavior.  I realize that the use of null-terminated
strings is a legacy of the original C runtime library.  That doesn't
mean that it's right.

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

Re: [Gimp-developer] Re: patch for gimp/po/fr.po

[Kelly Martin]

On Thu, 30 Aug 2001 13:42:05 +1000, Stephen Robert Norris <[EMAIL PROTECTED]> said:

>I'd be interested to know how to avoid that. I'm pretty sure I can
>construct a scenario (with multiple threads and memory mapping, for
>example) where it's impossible to tell until you get the SEGV. For
>instance, I memory map a file, pass a pointer into the mapped region
>into the library and then unmap it some time later from another
>thread.

>Even if the library were checking (and I'm not sure how it could)
>that the pointer points to valid address space, there will be a time
>gap between the check and the use, and my unmapping can get in there.

>Having the library install its' own signal handler is not an
>acceptable solution, either.

Sounds like a fundamental problem with the UNIX environment design,
then.

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

[Gimp-developer] makefile.mingw warnings

[Kelly Martin]

CVS current throws warnings regarding makefile.mingw in several
directories.  An example:

make[2]: Entering directory `/home/kmartin/gimp/libgimpbase'
Makefile:505: warning: overriding commands for target `makefile.mingw'
Makefile:254: warning: ignoring old commands for target `makefile.mingw'
make[2]: Nothing to be done for `all'.

Looking at the Makefile.am for libgimpbase leads me to strongly
suspect that the makefile.mingw line in Makefile.am is wrong and
should be deleted, but I'd like one of the w32 people to look at it
and decide for sure.

The affected directories:

libgimpbase
libgimpcolor
libgimpmath
libgimpwidgets
libgimp
app
plug-ins

Kelly

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] memory leak?

[Kelly Martin]

Maybe I'm just losing it, but it looks very much to me like
gimp_image_construct_layers in app/core/gimpimage.c leaks the
reverse_list.  

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] memory leak?

[Kelly Martin]

On Mon, Nov 26, 2001 at 10:20:35AM +0100, Sven Neumann wrote:
> Hi,
> 
> Kelly Martin <[EMAIL PROTECTED]> writes:
> 
> > Maybe I'm just losing it, but it looks very much to me like
> > gimp_image_construct_layers in app/core/gimpimage.c leaks the
> > reverse_list.  
> 
> very well spotted indeed. I'll check in a fix later for HEAD and
> gimp-1-2.

gimp_image_construct_channels has the same problem, btw.

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Professional use of Gimp (was: Developers and users (was: Bug week like thing for GIMP?))

[Kelly Martin]

On Tue, Nov 27, 2001 at 02:33:22PM +0100, Lourens Veen wrote:

> Yes, but then we're still talking about printers here. The colour posters I 
> designed were printed as well (on a "digital press" as they called it, which 
> from what I gather is just an industrial strength printer), but that only 
> goes up to A3, and the colours aren't that good (especially the orang bits 
> came out a bit faded). All the other stuff my university printed for the 
> anniversary was four-colour printed, which means CMYK. The website at 
> http://www.bobs.co.uk/print/4colourProcess.html suggests that most stuff is 
> CMYK too.

My housemate works for one of the larger prepress firms in the
country.  From what she's said to me, I feel safe in stating that
virtually all commercial printing is CMYK, CMYK plus one or
two spot colors, or one, two, or three spot colors alone.  Spot colors
are virtually always drawn alone (the graphics program is not expected
to generate spot layers from an RGB source).

Doing CMS-based color matching is probably hopeless: there are too
many patents and trade secrets in this area that we will have
virtually no chance of negotiating licenses that will not interfere
with the GPL.

Using channels as a substitute for spot layers is not entirely
acceptable because channels are always above all layers of the image.
This may not always be desirable.  

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

Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)

[Kelly Martin]

On Tue, Nov 27, 2001 at 02:10:47PM +0100, Avi Bercovich wrote:

> CMYK, halftoning etc. would be nice indeed, but possibly a Photoshop xcf
> plugin might be easier?

I don't know of any GIMP developer willing to spend the $$$ to get the
SDK for Photoshop.  


-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp 2?

[Kelly Martin]

On Tue, Nov 27, 2001 at 02:48:33PM -0700, Laramie Leavitt wrote:

> Is anyone actively working on GIMP 2?

Insofar as there is activity on GIMP 1.4, yes.

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

Re: [Gimp-developer] Re: patch for gimp/po/fr.po

[Kelly Martin]

On 02 Oct 2001 16:44:18 -0500, Federico Mena Quintero <[EMAIL PROTECTED]> said:

>It is physically impossible to synchronize clocks.

>Sounds like a fundamental problem with the design of the universe.

Indeed.  We should return the universe for a refund.

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

Re: [Gimp-developer] Current work

[Kelly Martin]

I am currently working on developing a single abstraction for
representing internal arrays of pixels and converting all code working
with such entities to use this abstraction.  This includes, for
example, eliminating the use of TempBufs for storing pixel data (but
not for storing previews; that's someone else's problem), eliminating
hard-coded dependencies on tile size outside of the tile code itself,
and other such encapsulation.  This abstraction is intended to be
vaguely analoguous to the ImageData class in GEGL, although it is by
no means an exact match.  In most cases, PixelData objects will
replace TileManagers as well as TempBufs.

Please do not do anything related to tiles, tile managers, or pixel
regions without consulting me first.

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] XCF support added to ImageMagick

[Kelly Martin]

On Tue, Dec 04, 2001 at 07:35:55AM -0500, Leonard Rosenthol wrote:

> Don't you have to maintain backwards compatibility with your own 
> user base?  I certainly expect that you will change things to support new 
> features (CMYK, etc.), but since old GIMP users have to be able to read 
> those files, your changes would have to be backwards compat.

We can easily write our XCF loader to handle multiple file formats.
(There are already two XCF file versions; the loader identifies the
version based on a magic cookie in the header and changes its loader
behavior appropriately; the saver uses the oldest version that is able
to accurately represent the image being saved.)  We're not really that
concerned with older GIMPs being able to read XCF files saved by newer
GIMPs.

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: your so called optimizations and why we don't like them

[Kelly Martin]

On Tue, Dec 04, 2001 at 11:34:59AM +0100, Sven Neumann wrote:
> the side effects of unsigned integers are not what people are used to
> think about when designing an algorithm. You are changing the
> mathematical base in an unneeded and hardly foreseeable way. Code that
> looks correct and used to work fine, suddenly starts to behave
> wrong. I doubt that you've checked each and every usage of the
> variables you changed lately.

There are places in tiles, tile managers, and pixel regions that use
negative numbers in unexpected ways (for example, theres's a spot in
the shapeburst code that uses a negative rowstride to go backwards
through an image buffer).  Changing these variables to unsigned will
obviously break things.

> If you are about to optimize parts of the GIMP, the first thing you
> should do is write a test suite and benchmarking facility for this
> part of The GIMP. No optimization should be allowed without such a
> test suite.

I can't agree more with this.  Profile the GIMP before you try
optimizing it.  You may be surprised to discover where the GIMP spends
most of its CPU time.  And trying to optimize a moving code base is
just plain stupid.

Kelly


-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: your so called optimizations and why we don't like them

[Kelly Martin]

On Tue, Dec 04, 2001 at 01:39:36PM +0100, [EMAIL PROTECTED] wrote:

> I'm talking about nested function calls. If a function deep inside fails 
> it should be handled as quickly as possible instead of propagating it
> through the code.

Uh, this is C, not Scheme.  We don't throw exceptions.  Calling
gimp_fatal_error is not an option in most cases (most errors are not
fatal).  The correct response to an error condition is to return an
error indication in accordance with your API.  Upstream callers are
responsible for checking error returns except for errors which cause
transfer-of-control with longjmp or exit.

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: your so called optimizations and why we don't like them

[Kelly Martin]

On Tue, Dec 04, 2001 at 12:24:34AM +0100, Sven Neumann wrote:

> > I've applied exactly this scheme to tile_manager_get_tile_num () in 
> > tile-manager.c and together with replacing the ongoing errorchecking
> > throughout the callees was able to save a whooping 480 bytes in object
> > size on PPC and got faster code while (IMHO) making the code clearer.
> 
> you also removed a good bunch of debugging code that might still be
> needed (Kelly is working on this code) and "unsignified" lots of
> integers, which is why I choose to revert the changes in this file in
> a whole. I do hope you will post the tile_manager_get_tile_num()
> part of your change to the list.

Please don't make any changes in any tile-related code without talking
to me first.  That code is touchy and even small, seemingly innocuous
modifications can wreak havoc that may be difficult to detect.  I am
in the process of ripping that code entirely to shreds, so you're
really rather wasting your time fiddling with it.  Most of it is
already subtantially rewritten; I would probably have committed it
over the weekend if it wasn't for my network access problems.

I realize I've been incommunicado for a few days (fuck you very much,
Excite@Home), but that's no excuse for not talking about changes
before committing.

Kelly

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: your so called optimizations and why we don't like them

[Kelly Martin]

On Wed, Dec 05, 2001 at 01:11:56AM +0100, [EMAIL PROTECTED] wrote:

> I say using a type that represents the actual type of the value
> closely is a feature and not a bug. What wrong about seing:
> Hey, this value is supposed to be unsigned?

Because that's not what "unsigned" does in C.  Unsigned is a promise
to the compiler by the programmer; don't make the promise if you're
not certain you can.  The compiler doesn't enforce type safety with
respect to unsigned (except very trivially).

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Give me cool plugins !!!

[Kelly Martin]

On Thu, Dec 06, 2001 at 09:53:30AM +0100, Fabian Fr?d?rick wrote:

> Who cares about the size.Everybody wants a lot of plugins !

Lots of us care about the size.  

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GNU/Linux vs. Linux

[Kelly Martin]

The "G" in GIMP stood, once upon a time, for "General".  It was changed to
"GNU" at Richard Stallman's insistence (but with the consent of S&P, so it's
not like it was completely hijacked).  See the S&P interview at
http://www.xach.com/gg/1997/1/profile/1/.

Yet another case where Stallman's zealous efforts to push his brand name on
people was successful.  How long before we have GNUburgers and GNUfries with
our GNUlunch?

Kelly

- Original Message -
From: "Marlon Sandford" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 05, 2002 7:21 AM
Subject: Re: [Gimp-developer] GNU/Linux vs. Linux


>  when=Fri, 5 Apr 2002
00:46:24 +0200>
>
>
> > For those who do not know: the OS Linux was built by Linux Torvalds
> > in 1991.
>
> Don't mean to be rude but its Linus Torvalds, not Linux Torvalds. :-)
> In Ebonics I think that would be "the T man".
>
> The "OS Linux" is just a kernel called Linux, not a complete OS.
>
> > I grepped the current stable CVS (well, that of a few weeks ago) and
> > found that a few files (mostly of the documentation type) mention
> > Linux instead of GNU/Linux.
> >
> > Should we change these instances to GNU/Linux?
>
>  No matter how much of a GNUisance this might be,
> IMO the G in GIMP should be thought of whilst carefully replacing all
> the instances of Linux with GNU/Linux. 
>
> Seriously though my vote is for changing them :-)
>
>
> --
> +-+---+---+
> |^| Marlon Sandford   |"Carpe Noctum" |
> |   'v'   | marlon [at] xealon.com+---+
> |   / \   | PO Box 75585 Seattle WA 98125 | http://www.debian.org |
> | /{   }\ | Mobile: +44 07855 627468 (London) | http://www.gnu.org|
> |  ^^-^^  | xealon.com/marlon/publickey.txt   | http://www.kernel.org |
> +-+---+---+
> ___
> Gimp-developer mailing list
> [EMAIL PROTECTED]
> http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
>

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

Re: [Gimp-developer] Pattern image licenses

[Kelly Martin]

>  seems to imply that somebody called sopwith
> has uploaded these two files to the CVS-tree gimp-data-min.
>
> However, sopwith appears all over these directories, both for changes
> made by  and by
> .

"sopwith" (Elliot Lee) made the original checkin of the current CVS tree, so
a Really Old file checked in by sopwith probably means a file introduced to
the GIMP prior to whenever the prior CVS repository went byebye (1998
sometime, I think).  I think, but am not entirely sure, that the two
patterns being referenced were part of 0.56, which would mean they trace
back to S&P.  However, I seem also to recall that some of the pattern files
in 0.56 were, um, questionably appropriated from other sources (including
Adobe).  I think the long and the short is that we don't really know where
they came from or who (if anyone) holds a copyright interest in them.

Kelly

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

Re: [Gimp-developer] CONFIGURE missing from CVS?

[Kelly Martin]

Please read "HACKING" first.  INSTALL is for people installing from a
distribution tarball.  Instructions on how to proceed are in there.

Kelly
- Original Message -
From: "Jean-Claude Gervais" <[EMAIL PROTECTED]>
To: "Gimp Developers" <[EMAIL PROTECTED]>
Sent: Tuesday, September 24, 2002 1:32 PM
Subject: [Gimp-developer] CONFIGURE missing from CVS?


> Hi,
>
> I checked out the current version of The Gimp from CVS and read the
INSTALL
> text file, which says to run
>
> ./configure
>
> To build Gimp.
>
> Oddly enough, I couldn't find the configure script in the /gimp directory,
> but the is a configure shell script in the /gimp/plug-ins/perl folder.
>
> What are the steps to build Gimp?
>
>
> ___
> Gimp-developer mailing list
> [EMAIL PROTECTED]
> http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
>

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

Re: [Gimp-developer] tentative GIMP 2.0 release plans

[Kelly Martin]

Patrick McFarland wrote:
I am one of these active users that have been lead to believe that gimp 2.0
will use GEGL. So, all the developers out that think 2.0 is yet another small 
gimp release, or something else (imho) stupid, can just go away or something.

Im actually kind of sick of listening all of you bicker back and forth.
From my outsider point of view, 2.0 is set in stone, and what it will include
will be set in stone. Also, from my outsider pov, stuff like gegl is a very
cool idea. Anything that allows gimp to be more powerful is always a good
thing. I also see gegl as a major feature, something that would produce a 2.0.
However, the more you all bicker, the less work is actually getting done.
I hate to have to be the one saying this, but you should just be coding,
because in the end, whoever codes gimp 2.0 is the one who gets to say what
happens, or _nothing happens at all._
Gegl is basically the end all be all gimp graphics rendering engine. It will
be able to do what no popular graphics manipulation program has done before.
(I think.) 16-bit per channel graphics is good, and internal floating point
based calculations independent of the actual image's bitdepth is good as well
(due to the fact multi-layered images often go above 1.0 and below 0.0, and
clipping severely damages the output.)
Also, while Im on the pro gimp 2.0 kick, I read the xcf2 threads. I agree,
something like gimp2 will need a better file format. Internally, I dont care
whats in it. Im not a gimp developer, Im a user, so I should have to care.
_However_, it needs to be able to be very extendable. I want to be able to
store all future gegl supported bitdepth and color space types with it, I want
to be able to depend on it to be stable the same way the professional people
depend on psd being a half way decent format, and I want it to someday exist,
the same way I want gimp2 to someday exist.
A lot of users out there are depending on the gimp development team to get
gimp2 done sometime in their lifetimes, and from what I see on here, this may
never happen. And Im going to be severely disappointed if this happens.
Two bits from a former developer, here.  We talked a lot about what 2.0 
would have after we released 1.0.  CVS current is nothing close to that. 
 I'd be disappointed if it were released as 2.0.  So would a lot of the 
people I talk to about the GIMP.  A lot of people have seen the GEGL 
documents.  People have expectations for 2.0 that this release will not 
meet.  I personally think you shouldn't call it 2.0 until it supports 
Lab as a native color space, but that's because I really like Lab.

The relative lack of serious technical progress in recent versions is 
why I now use Photoshop 7 for most image editing, these days.  I only 
use GIMP when I want one of the plug-in effects that isn't available 
from PS7, or when I'm on a computer that I don't have a PS7 license for. 
 Maybe I'm the only one like that, but I doubt it.  PS5 and Gimp 1.0 
were pretty competitive in most areas, with a few well-noted 
shortcomings.  PS7 completely blows away CVS HEAD.  Releasing it as 2.0 
will invite comparisons, and you don't want to do that right now.

I'm not actively involved in the project anymore, so it's not really my 
fish to fry, but I'd ask the current project maintainers to reconsider 
releasing the current HEAD branch as 1.4 instead of 2.0.

Kelly

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

Re: [Gimp-developer] tentative GIMP 2.0 release plans

[Kelly Martin]

Sven Neumann wrote:
The ball is rolling now and any further discussion about it is only
hurting GIMP's reputation.
You're going to do what you're going to do.  I'm just offering my 
counsel.  Claiming that offering my counsel is "hurting GIMP's 
reputation" is a hamfisted way of telling me to shut up because you 
don't like my opinion.  Releasing 1.4 as 2.0 will do more to hurt GIMP's 
reputation than anything I could say about why you shouldn't do so.

As to why PS7 is better: the PS7 features I make the most use of are the 
better colorspace support, PS7 dynamic brushes, adjustment and effect 
layers, and the "healing brush".

Kelly

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