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 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] 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 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
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] 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, 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)
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 #parameter image 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)
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)
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)
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
[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 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
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
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
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] 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 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
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 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
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
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 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] 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 SP, so it's
not like it was completely hijacked). See the SP 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
quote who=Branko Collin [EMAIL PROTECTED] 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?
RMS impersonation 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. /end impersonation
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] 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 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] 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 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
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
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] 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 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?)
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?
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] 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 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
[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. ___ 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
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] 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 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] 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 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
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
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] 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 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
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
[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. 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] [patch] Major speedup for whirlpinch 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. 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] [patch] Major speedup for whirlpinch plugin
On Thu, 5 Apr 2001 12:36:05 -0500, Kelly Martin [EMAIL PROTECTED] said: I have modified whirlpinch 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 whirlpinch 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
