Re: [Gimp-developer] AUTHORS.xml

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 other

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

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 enga

Re: [Gimp-developer] The GIMP Foundation

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 re

Re: [Gimp-developer] more gimp foundation stuff

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 b

Re: [Gimp-developer] The GIMP Foundation

Sven Neumann wrote: If sueing copyright violators is the main goal, I'd rather let the Free Software Foundation do this job. It is probably in a lot better position when it should ever come to a law-suit. The FSF can't sue someone unless it owns at least some part of the code in question. The F

Re: [Gimp-developer] The Mark Shuttleworth offer

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

Re: [Gimp-developer] The Mark Shuttleworth offer

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, GimpIm

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

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,

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

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

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

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

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

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 tha

Re: [Gimp-developer] making plans

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 go

Re: [Gimp-developer] PDB requirements

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

Re: [Gimp-developer] PDB requirements

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 c

Re: [Gimp-developer] PDB requirements

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 p

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

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 alterna

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

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

Re: [Gimp-developer] Joining the GNOME Foundation

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

Re: [Gimp-developer] Joining the GNOME Foundation

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

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

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 modif

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

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 cache

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

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

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

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

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

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 vertica

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

>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

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

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

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

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

Re: [Gimp-developer] The GIMP Webpage

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 comp

Re: [Gimp-developer] The GIMP Webpage

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 flex

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

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

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

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 desi

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

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 "dev

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

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 ch

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

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 u

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

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 H

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

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 m

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

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

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

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 le

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

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 c

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

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

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

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 t

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

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

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

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

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

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

[Gimp-developer] makefile.mingw warnings

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' ma

[Gimp-developer] memory leak?

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

Re: [Gimp-developer] memory leak?

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

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

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

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

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 ca

Re: [Gimp-developer] Gimp 2?

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/listi

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

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 ___

Re: [Gimp-developer] Current work

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

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

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 >

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

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

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

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

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

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 PP

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

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

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

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 goo

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

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 zealo

Re: [Gimp-developer] Pattern image licenses

> 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

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

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

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

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 al

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

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