Re: [Gimp-developer] Is there any way to free Gimp memory and avoid restarting it?
On Wed, 6 Feb 2019 11:14:21 +0200, Ofnuts wrote: > On 2/5/19 5:35 PM, jEsuSdA 8) wrote: >> El 2/2/19 a las 9:58, Ofnuts escribió: >>> The fact that the memory isn't marked free doesn't mean it is >>> unusable. Tried in Gimp 2.10 on Ubuntu: >>> >>> - load 5 20MPx Jpegs: memory is 1.35GB >>> >>> - close all: memory still at 1.35GB >>> >>> - load them again: memory is 1.4GB >>> >>> - close all: memory still at 1.4GB >>> >>> - load them again: memory is 1.4GB >>> >>> - close all: memory still at 1.4GB >>> >>> So the memory seems reused... >> >> I was thinking about your tests and the values seems to be a bit >> strange: I mean, I you load 5 images and Gimp takes 1.35GB Memory, why >> when you close all the images gimp still taking 1.35GB instead of less >> than? >> >> In the same way, if you load again the same images, why Gimp consumes >> more memory and its memory consumption rises from 1.35 to 1.40... and, >> again, when the images are closed the memory does not get back to a >> lower value. >> >> I think this values can corroborate my theory about Gimp lack of >> memory release I suffer and which is absolutely needed when working in >> professional environments. >> >> Why Gimp does not free the memory? >> Any idea? > > If memory was truly leaked, I would have seen 1.35, 2.7, > 4.05... Since there is no significant memory increase, we can assume > that this memory is reused. For the rest, see Øyvind's answer. It's possible that some memory was leaked, just not all of it. -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Participation at Apple Developer Program
On Tue, 27 Mar 2018 09:21:31 +0200, Kristian Rietveld wrote: > >> On 27 Mar 2018, at 03:25, Jehan Pagès <jehan.marmott...@gmail.com> wrote: >> >> But right now, we are discussing paying to distribute a version of GIMP >> which is barely kept alive. This is a bit doing things in the wrong order >> IMO. > > In fact, I think this is the main point. Even in the case we do decide to pay > for an account, we need to incorporate this into our build system. And I > consider it more important to first get regular 2.10 builds off the ground > than to produce signed binaries. > > [I am near having a script that completely automates the build and DMG > creation. I wanted to have 2.10 DMGs available already, but unfortunately due > to some family related events early this year I had to stall his work for a > while. It is my intention to pick it up again now]. > > I voted “I don’t care”, because manually enabling the binary is in my opinion > a minor nuisance to some of the other issues that need fixing. Also I don’t > need this feature myself, but if the community wants to see this fixed I can > look into it. Just a note about this -- in the Mac world, signed binaries are perceived to be a security issue. We (Gutenprint) had always planned to sign our binaries after this came out, but it took us some time to get the details right even with an experienced Mac person on the team and we got a lot of complaints from our Mac users until we got it all set up. -- Robert Krawitz <r...@alum.mit.edu> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] To developers of GIMP: Process or batch editing - Barrel distortion
On Wed, 31 Aug 2016 01:10:22 +0200, =?UTF-8?Q?Manuel_Ace=C3=B1a?= wrote: > To developers of GIMP: > > *Process or batch editing - Barrel distortion* > I detected something that I think could help significantly large number of > users: > > Almost all do photos to documents with the mobile phone, and we also > thought of using a camera installed permanently for it, being much faster > than the scanner table. But we found that the pictures are distorted, > generally convex, whether we do with a smartphone or a traditional camera. > > Many smartphone apps include automatic document edge detection, but have > not found any way to correct lens distortion (barrel distortion). This is a > very serious problem when we take pictures of planes, which are > invalidated, or when we want to take pictures of any image that must remain > correctly proportioned. > > GIMP itself that corrects barrel distortion quickly and easily using a > filter, but only when a single image editing. Unfortunately, you can not do > that function working in batches, when I think that developers would be > simpler than the batch also included that role, assigning a group of photos > -made with a fixed camera one correction (Example: "Barrel distortion - > Main: - 22 ") > > *I request that you make every effort to include this feature among > supported in batch editing.* > > *Thank you* for providing such an *excellent program!!!* GIMP isn't the right tool for the job. You'd be a lot better off using darktable or rawtherapee, which are designed for batch processing, for that purpose. Both of these tools work on JPEGs as well as RAW files, and if you're always using the same lens at the same focal length (with the same distortion characteristics) you can save the parameters and easily apply them to more shots in the future. -- Robert Krawitz <r...@alum.mit.edu> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Problems with JPG?!
On Sun, 31 Jan 2016 22:22:55 +, Kevin Payne wrote: > Yes it's almost certainly the bug that won't get fixed raising it's ugly head > again: https://bugzilla.gnome.org/show_bug.cgi?id=723153 Manufacturers simply aren't going to fix their firmware, particularly for older devices (read: are already on the market). And it's possible that a firmware fix wouldn't even be enough, since printers would need more memory to buffer the entire image rather than just reconstituting it one row of blocks at a time. There's also the added testing expense. Phones and cameras don't generate progressive JPEGs, so printer, TV, etc. manufacturers don't have any real incentive to support them. The manufacturers probably don't even write their own firmware; they contract it out. Progressive JPEGs are nice for displaying big images in browsers over slow links (which my 1500/368 DSL qualifies as). I admit that they're easier for me in that context. But given the confusion this is causing, and that it requires non-trivial knowledge (and tools) for people to fix after the fact, I'd argue that this should be revisited. > > From: gimp-developer-list <gimp-developer-list-boun...@gnome.org> on behalf > of Michael Schumacher <schum...@gmx.de> > Sent: 31 January 2016 20:31 > To: gimp-developer-list@gnome.org > Subject: Re: [Gimp-developer] Problems with JPG?! > > Am 31.01.2016 um 16:29 schrieb Stefan Rohde: > >> I can not display images that I have prepared and saved with GIMP 2.8.14 >> (under Windows 10) in jpg-format on my TV or via a digital box (WD TV). > >> Do you have an idea or information !? > > It's most likely the Progressive option in the advanced part of the JPEG > export dialog. -- Robert Krawitz <r...@alum.mit.edu> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] wtf with the download?
On Mon, 01 Jun 2015 01:40:10 +0200, Michael Schumacher wrote: On 06/01/2015 01:14 AM, Gez wrote: El dom, 31-05-2015 a las 17:14 +0100, C R escribió: It does say via BitTorrent on the teal link. There's a good case to be made for just listing the torrent file as a smaller text-link after the orange download button, though. If I had my way, we would not be listing a torrent at all for windows users, as there are far too many things that can go wrong for that platform. However, I'm trying to present a solution that everyone is okay with. Esp the developers who will, in the end, be applying these patches to the site. Most of the devs have been supportive of keeping the torrent link (at least as) prominent as the direct download link. Hi, I just followed the previous posts and I confirm that it looked bad before you trimmed the text as Michael said. Now text fits, but the problem wasn't the length of text but its font. Thank you for taking care of this. Let me know if you need a hand. This change is live now - it was rather easy to apply into the current layout. Thanks, C R. I've tested it on http://testing.gimp.org/downloads/ and started the deployment to http://www.gimp.org/downloads/ I like the look of that. I suggest that the same change be made to the Mac native installer. -- Robert Krawitz r...@alum.mit.edu *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] wtf with the download?
On Fri, 08 May 2015 17:21:15 +0200, Michael Schumacher wrote: On 05/08/2015 04:46 AM, Robert Krawitz wrote: To what end? Is this to help GIMP users in some way It helps them to get download speeds that are reasonable, even if many (or actually, the more) people download the files at a given time. Mirroring would help too. There are plenty of services that provide that without messing with the content. If I understand it correctly, BitTorrent also by default makes you an uploader as well as a downloader. If you're running on a slow DSL connection, that might make for a nasty surprise; if you're using a service provider that forbids running servers, that might get you into other trouble. And a lot of ISP's, for better or worse, block or otherwise muck with BitTorrent traffic, which is going to be hard for users to debug. Expecting people to learn to configure proxies, TOR, and what have you to get around this just to download an image editing program is, IMHO, not reasonable. P.S. can you make your mail client reply to the list directly, instead of cc'ing it? The list needs to set the reply-to: to make that work. It sets the corresponding mailing list headers already, so List-Reply in mail clients that support this will work. If some clients don't implement it, it would be nice if their users could ask the developers to do that. I see. Manually changing the To: address is also possible, this is what I do for clients - for example web interfaces - that do not support List-Reply. If one remembers to do that. -- Robert Krawitz r...@alum.mit.edu *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] wtf with the download?
On Fri, 08 May 2015 20:46:43 -0400, Liam R. E. Quin wrote: On Fri, 2015-05-08 at 22:04 +0100, C R wrote: I'd be ok with having two links labeled Download GIMP 2.8.14 via HTTP and Download GIMP 2.8.14 via Bittorrent right above each other, in any order. This should also help to reduce the explanation for Bittorrent to one short paragraph To make this a bit more obvious, I'm imagining something like this instead of the current few lines: How about this? http://opendesignstudio.org/gimp/samples/gimp_windows_download_buttons2.png Close. I'd still put the Bittorrent one first with text like Get GIMP for Windows using Bittorrent. Fastest download. Least load on the GIMP servers. Requires a bittorrent client. Learn more... Get GIMP for Windows over the Web with HTTP. Slower but no special program is needed. Note, I'm repeating GIMP for Windows to minimize doubt. Think about this from the perspective of photographers or other graphic artists who otherwise aren't particularly tech-savvy. They don't know what load on the GIMP servers means and don't care. The download's really not that big anyway; they'll spend more time learning about BitTorrent (much less installing it) than they will just downloading it via HTTP. It's 87 MB or so; over my piddly little 1500/368 DSL link, that works out to about 9 minutes. I spent more time than that just reading about BitTorrent to even comment here. If you're asking people to go to wikipedia with a huge list of BitTorrent clients (which is intended as a reference, not as a guide) and telling them to select one, you're going to drive them crazy. If they pick an adware or malware client inadvertently (or because it has changed since el Wik listed it), they're going to blame GIMP for it (hey, you're the ones who told us to go here!). Downloading by browser is simple and everyone has done it countless times. If you provide an ftp link, the browser can even restart it if it's interrupted (which for something that small isn't very likely). The reason BitTorrent puts less load on download.gimp.org is that it puts that load on people who have downloaded and are downloading GIMP. Once you start downloading it, others may then downloads chunks of it from *you*. Aside from potential TOS violations and the like, that's going to take up some of your bandwith, which the wording proposed above doesn't tell anyone. You're asking -- not forcing, I know, but trying very hard to encourage -- people to do something they aren't likely to understand and can go wrong with in a lot of ways just to reduce gimp.org server load. That load could be reduced in other ways, such as by mirroring on Sourceforge, kernel.org, wherever. -- Robert Krawitz r...@alum.mit.edu *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] wtf with the download?
On Fri, 08 May 2015 02:16:47 +0200, Michael Schumacher wrote: On 05/07/2015 09:39 PM, C R wrote: Yes, and to also force Bittorrent knowledge upon users. If I were a new user, I'd Google torrent and immediately get links for Pirate Bay and other dodgy stuff... nothing having to do with GIMP. Exactly. The torrent files for GIMP are there to explicitly provide examples that are different to e.g. movie downloads - to make sure that this download method is not inherently linked to those. To what end? Is this to help GIMP users in some way, or to promote BitTorrent for reasons unrelated to GIMP per se? If it's the latter, it has the feel of bundleware, the various helpful add-ons that are included with all too many freeware downloads. I realize there's not the same kind of commercial tie-in, but it has the same effect of trying to foist something on the user that isn't going to make his or her life any easier. Thought we were trying to prevent people from going to 3rd party websites and downloading viruses accidentally. Having to install a 3rd party downloader just to install GIMP is a pretty big hurdle for a lot of people, and they are likely to encounter lots of dangerous DOWNLOAD NOW buttons. ;) It takes trust in two different software packages just to install one program. Yes, this is a problem - and the current way of linking the Wikipedia Bittorrent clients list is not as good as linking one particular safe client for the current platform. For example, I pondered to go for Deluge for Windows, but didn't want to remove people's choices in favor of my own personal preference - but if there is some general agreement on good client options, we may link them directly. It also forces users to go through a bunch of extra steps for no purpose that's going to make their GIMP-using lives any easier: select a client (the wikipedia page really is all but useless for someone who's not particularly savvy already), hope that it's not yet another Trojan horse (the wikipedia page itself says that there are some clients that were discovered to be Trojans), download it, install it, and go through an unfamiliar procedure just to download GIMP. This is going to be more difficult for people to do than simply search el G00G for gimp, find somewhere else to download it from more easily...and that download has all kinds of uglies bundled with it. The combination of said uglies and association of GIMP with various unsavory things linked to BitTorrent would be a big turnoff for a lot of people. More persistent people will notice that there are direct download links without the complexity, but what's the gain from forcing people to go through this extra hassle? P.S. can you make your mail client reply to the list directly, instead of cc'ing it? The list needs to set the reply-to: to make that work. -- Robert Krawitz r...@alum.mit.edu *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On Sun, 03 May 2015 02:34:26 -0300, Gez wrote: El sáb, 02-05-2015 a las 12:40 -0400, Elle Stone escribió: Well, you might be able to answer that question. I'm not qualified. Personally I don't use alpha channels except in the extremely rare instance when I'm exporting a png with a transparent background for use on a website. See, this is exactly what I intended to discuss. You know a lot about linear and perceptual gamma, so in your opinion everything has to be tailored to allow you to play as you wish with gamma. For you it is essential. Now, you think you don't use alpha channels, so you don't care much about the options provided. But you actually use alpha channels a lot: every time you create a layer mask you're creating an alpha channel for that layer, and if that alpha is associated or unassociated makes a big difference. I agree, but draw a very different conclusion (my conclusion is in line with Elle's). AFAIK, most of the time alpha channel is unassociated in GIMP, but when you have to apply any convolution you have to pre-multiply it. And what about alpha channels being linear or perceptual? Why don't you care? In that case, developers chose for you, and you don't seem to feel too bad about it. Right. The problem is when you're one of the people who *do* care about it. And believe me, when it comes to alpha channel THERE IS right and wrong, no matter what the artist says. Perhaps, but someone may have a reason to want a particular workflow, even if that reason is nothing more than demonstrating what's wrong with it. -- Robert Krawitz r...@alum.mit.edu *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On Sat, 02 May 2015 11:21:37 -0300, Gez wrote: El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: I'd like to see this discussion heading towards a real world list of examples of real needs for such options that can't be satisfied with anything else than these toggles. You are presupposing that the devs can foresee every possible use to which a user might put a given editing operation. No, I'm saying that users like us should describe real world situations where certain options are needed in order to convince developers of the necessity of such options. Let me do whatever I want is not a good argument. Yes it is, because we don't know every possible use to which someone will put something. We've had the same issue come up in Gutenprint. Gutenprint exposes just about every internal control option to users, if they want to play with them. It allows things that could actually cause _physical_ damage to printers, in particular specifying ink limits so high that they would completely soak through non-coated paper and would form large puddles on coated papers that could gum up the print head. But then it turned out that people wanted to do things with printers that we had never envisioned: printing T-shirts, and doing chemical deposition (in one case, literally printing circuits onto paper using electroconductive inks). It turned out to be very fortunate for those users that we had never imposed limits of that kind because that isn't something anybody should be doing. The one concession that we did make was to group options into different levels of interface complexity, and add an option to the PPD file generator to generate simplified PPD files with only the basic options. But the default is to use the full-featured interface. Obviously there are resource constraints here; developers can only do so much, and have to make decisions about what to do that are mutually exclusive on time constraints alone. But deliberately leaving something out of this kind of project because there isn't an obvious real world use case is not, in my view, a good thing. -- Robert Krawitz r...@alum.mit.edu *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] OT: Looking for a Macintosh maintainer for Gutenprint
Apologies for the OT post, but our Macintosh maintainer retired from the Gutenprint project and we're looking for someone to take on the role. Is there anyone here with the Mac chops who would be interested in doing this for a couple of releases per year? Our previous Mac expert would be willing to help bring you up to speed on the particulars of the Mac stuff for the project. Thanks! -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congrats MIT Engineers 5 straight men's hoops tourney Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP System Requirements
On Wed, 23 Oct 2013 18:16:35 -0400, Jay Smith wrote: On 10/23/2013 05:52 PM, C R wrote: With GIMP, you just download it and try it out to see if it fits your needs. There is no consumer risk involved with doing this While I am in agreement with virtually everything you have said... I beg to differ with the point about no consumer risk. Over the years, I have lost days of my life to such try it and see if it works for me situations. To _me_ there is a very high consumer risk. I know that nothing is perfect and even paying lots of money usually does not mean that there is no consumer risk in terms of time. However, if (ha!) I knew FOR SURE (ha!) in advance that my choice was a) a couple of days of testing and struggling vs b) paying a few hundred dollars, I would rather pay the few hundred dollars. The problem -- and this is more so with GIMP than with many apps -- is that it really comes down to what you want to do and your level of patience. If you're using it on web images (maybe 1 MP or less), you're not doing anything fancy, and you're running a light weight desktop, particularly on an older distribution, you might be perfectly happy with 256 MB of memory and a Pentium 3 processor. If you're working on multi-layer 50 megapixel images, and you're doing a lot of transforms, you might find even 8 GB unpleasant. I'd be pretty confident in saying that you're not going to be happy with GIMP on a 16M color, 1024x768 display regardless of what you're doing. But beyond that, it's so dependent on your image size and structural complexity that I'd be completely unwilling to specify a minimum processor, memory, and disk space requirement. With an office suite like LibreOffice, there's typically less variation in document size. I have some spreadsheets in the 10 MB range, but this is very big for a spreadsheet and corresponds to no more than a 20 MP image with a single layer; plenty of people work with images that dwarf this. Maybe someone can toss together a benchmarking plugin that takes some sample images, and processes them in various ways and produces a user experience rating... That is a really good idea. It would be even more useful if combined that with a web page where testers then post their results in a very structured manner including information about their specific hardware, etc. Thus other potential users can see in advance how a specific Gimp version works in a specific environment. (Or are there still too many variables?) Yes, there are. There's so much variation in image size, and what people do, out there that none of this would be of any general value at all. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congrats MIT Engineers 5 straight men's hoops tourney Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Re : Feedback from an ordinary user
On Thu, 29 Nov 2012 05:30:35 +0400, Alexandre Prokoudine wrote: On Thu, Nov 29, 2012 at 5:10 AM, Monty Montgomery wrote: On Wed, Nov 28, 2012 at 10:27 AM, Alexandre Prokoudine Democracy is overrated :) Agreed. But despots get their feedback primarily through overripe fruit... and revolutions. Revolutions? :D So far it looks rather like I'm going to be your PITA until you give in. That's more like terrorism. And I'm not falling for that, my friend. All right, let's stop this nonsense. You have every right to do what you please with GIMP. By the same token, other people have a right to complain. And in this situation, where so many people are complaining so vociferously, you *could* decide to take a closer look at your assumptions. I've read your vision statement. It's fine. I have no basic quarrel with it. But your execution, frankly, sucks. You've gone out of your way to try to force everyone, no matter what their needs or how they work, to embrace your vision of images being projects, where you always want to work in the loss-free form and only export the result at the end into a portable image format. There are plenty of cases where that's fine. If I've carefully built a large panorama, and want to do major work on it, that's exactly what I do. Five years ago I put maybe 100 hours of work into this panorama (http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT#!i=450968307k=29fQmfW), and you'd better believe I did all the work in XCF format. I put a tremendous amount of work into cleaning it up, getting the sky just right without doing anything to the foliage nearby, and I used a lot of layers, which was an extremely painful process on the single core with 2 GB that I had at the time. And I have a lot of other panoramas there where I've done a lot of work (none as much as that). Some of them I did in XCF format, some in TIFF when I didn't need to use layers. Those are projects. But there are plenty of times I'm just interested in fairly minor tweaking of an image for use as a web graphic or whatnot, and the whole business of having to export rather than save, and then get nagged to save even when I'm quite positive I'm never going to need to do anything else, or if I do, I can accept the data loss (the fact that XCF still is 8-bit only makes it even less tempting to go through all the effort). I don't need GIMP to hold my hand through the damn crosswalk. I've done enough image editing over the years to have developed judgment about when I need to take my image editing seriously and when I don't. If I open a JPEG file and want to save it back out as a JPEG, I know what I'm doing. Maybe you don't think so, but I do. These are not projects. They're quick and dirty one-offs. I use GIMP because I know it. I don't want to go through the bother of learning a different tool just to edit images I don't want to turn into full-blown projects. It's not efficient. So if I have to support a fork by someone who's going to take users' needs more seriously, I will. I'd rather not, because this is a trivial issue. But it's a very, very annoying one. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Re : Feedback from an ordinary user
On Thu, 29 Nov 2012 06:13:05 +0300, Alexandre Prokoudine wrote: On Thu, Nov 29, 2012 at 6:41 AM, Robert Krawitz wrote: All right, let's stop this nonsense. After reading that I honestly expected that it's going to end at... You have every right to do what you please with GIMP. But no, it hasn't :) You've gone out of your way to try to force everyone... Who are you and what have you done to Robert Krawitz, developer of Gutenprint? Show me where you buried his bones. I'd like to pay the last tribute to a great mind that succumbed to the nonsensical notion that free software developers can or wish to enforce anything on anybody. :-) If I open a JPEG file and want to save it back out as a JPEG, I know what I'm doing. Maybe you don't think so, but I do. These are not projects. They're quick and dirty one-offs. I use GIMP because I know it. I don't want to go through the bother of learning a different tool just to edit images I don't want to turn into full-blown projects. It's not efficient. And you don't have to. Overwrite and be done with it. You'll have to find a good explanation why I cut about a hundred of screenshots yesterday (basically, open, crop, overwrite - nothing fancier) without yelling at GIMP. After all, isn't that exactly the kind of simple editing for which people are reluctant to learn a new tool? Could it be that I'm used to closing images in a batch of 20 images or so? :) In what format? I can see how dealing with the warning dialog at the closing step could be a wee bit annoying for someone who works om many _heavy_ images (which means lots of memory used by GIMP), _and_ I publicly said that better ideas are welcome (at least by me). Now, don't pretend you didn't read it. You did. And so far I've mostly seen just gimme a goddamn option kind of reaction, with few (admirable) exceptions. Maybe because people really, really want an option to at least just save back to the original file or original format without any nagging? Noone said it isn't possible to tweak few things within the project's vision. In fact we already tweaked some of them to meet requests from users. Does http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8id=062d38d141907d095b92e7a1adc05cd1bc870be2 ring a bell? What about http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8id=c3e904fab1b29224b7dd55bb5b4af49f34c3b335 Neither of these address what I (and many others) see as the real problem. I want a workflow where I can open a JPEG file, edit it, and save it right back without having to go through a dialog, and where I'll get warned if I try to exit or close the image without saving it back. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Tue, 20 Nov 2012 12:24:59 +0200, Alexia Death wrote: Just pointing this out again - in the future vision, that we are approaching step by step, the export operation with it's tasks, like scale etc should not require you creating a new image for this process... It would just be a view on top of the existing xcf project - very much like a target complation is in IDE-s. But this future can not happen in one single release. It will come iteratvely. This separation is just one step on a long way. First mandatory step... Existing XCF project. Here's the thing: not every image I want to edit is something I think of as a project. Sometimes it's just a bug fix or minor enhancement (such as crop/unsharp mask/rescale). I'm starting from a JPEG file and ending up with one, and have no practical reason to ever have an XCF file since I'm pretty confident I'm not going to be making a lot of further changes. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Tue, 20 Nov 2012 14:42:05 +0400, Alexandre Prokoudine wrote: On Tue, Nov 20, 2012 at 5:02 AM, Robert Krawitz wrote: This may change in future versions - where maybe you won't even have the choice not to save, because saving has become so cheap that it can be done any time, and the program just does it for you. This can become really annoying, really fast... Applications that helpfully save their constantly can cause a lot of grief if I change something I really, really didn't want to change that causes something very strange to happen. Yes, I know about the undo stack and all that, but... Are you familiar with the concept of saving history stack into project files? I presume you mean appending journal entries to the file? Yes, and that's a lot safer than other ways of doing it. But make sure that you handle situations of high latency (NFS/Samba) and low disk space well. Also, there needs to be a way to remove particular entries from the project file. Say I accidentally add a layer from a file that I *really* don't want to be in there (a scan of my credit card, for example). I want to be able to completely purge it. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Mon, 19 Nov 2012 15:45:24 +0400, Alexandre Prokoudine wrote: On Mon, Nov 19, 2012 at 3:34 PM, Karl Günter Wünsch wrote: Automating repetitive tasks refers to scripting and future macros recording. Still the unconditional enforcing to have to save to XCF violates the section the tools get out of the way of getting things done and allow for accelerating the workflow for those who get to know them - It is very much getting into the way of getting things done and the only way of accelerating the workflow for those who know would be to add an option to disable the everybody who doesn't save XCF all of the time is an idiot mode! Thus on one hand you want the users to believe in the vision you put forward but on the other hand you violate it in a way to alienate those experienced users... Only _some_ of those experienced users, and, it seems, the most vocal ones. The ones who won't stop even when facing a lack of plans to adjust GIMP's behavior. I think I already understand that you dismiss existence of other experienced users who like the change. Do you really need to remind about that over and over again? *No one's dismissing the existence of other users who like the change.* We're simply saying that some like it and some utterly detest it. Different people, and it's *not* experienced vs. inexperienced users (people like Graeme are *very* experienced), have different ideas about how they like to work, and have reasons why. Do you understand that? It's analogous to click to focus vs. mouse follows focus. Some people like one, some like the other. One's not right and the other's not wrong, whichever side you come down on. That's why both GNOME and KDE have options to let the user select focus policy. And yes, I know you've said interminably that you have no plans to change it. But the amount of heat this has generated ever since GIMP 2.8 came out should suggest to you that perhaps your initial assumptions were incomplete and should be revisited. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Mon, 19 Nov 2012 15:30:38 +0400, Alexandre Prokoudine wrote: On Mon, Nov 19, 2012 at 3:28 PM, Alberto Mardegan wrote: Reformulating: is it possible for a user *who reads and understands all question dialogs which appear to him/her*, to actually lose the layers when saving to JPEG with gimp 2.6? Yes. If yes, how? By being overly confident and not forward-thinking. And guess what? I've done that on occasion myself. But I don't blame my tool for that. What's more, the GIMP 2.8 solution wouldn't have prevented this, because I'd have done exactly the same thing anyway (that's the overly confident and not forward-thinking bit), just with a bit more inconvenience and grumbling on my part. Because my intent *at the time* was to just write out the JPEG or PNG without worrying about the layers. I repeat: *the new GIMP 2.8 behavior would not have prevented me from making this mistake, because the mistake was in fact my intention at the time, and it was only because I wasn't thinking forward in the specific case that it happened*. This was when I was well aware of layers and XCF files, so it wasn't ignorance -- it was that I didn't expect to need the layer information again. As it happens, nothing drastic happened as a result. I just had to repeat some work on another copy of the original, to my (minor) annoyance. But at least 99% of the time, when I want to save an image as a JPEG, I have no regrets later. I don't want to pay the price in workflow efficiency for that 1% or less where I'm mistaken. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Mon, 19 Nov 2012 15:29:25 +0400, Alexandre Prokoudine wrote: On Mon, Nov 19, 2012 at 3:07 PM, Alberto Mardegan wrote: There must be a reason why one group of people keeps linking to http://gui.gimp.org/index.php/Save_%2B_export_specification and http://gui.gimp.org/index.php/Vision_briefing, and another group of people carefully ignores these links. I swear I read them and I think that I understood the rationale. But that's note the same thing as saying that I understand what was wrong with the save functionality in 2.6 (because I still don't). It's simple. Primary workflow = creating original art from scratch, complex editing where preserving extras is a must. That's the workflow when you work iteratively. This workflow makes it easy to share your work in a delivery file format (e.g. exporting to a public Dropbox folder), while refining the actual project file. 2.6 didn't make it easy. OK, fine. That's a fully persuasive argument for the *ability* to separate export from save. I understand that part of your case, and it makes perfect sense. Secondary workflow = overwriting original files. 2.6 made it easier, but it's not the primary workflow, and there are well-known workarounds. What it is *not*, however, is an argument for making it impossible *not* to separate export from save -- particularly for the special case where you're saving back to the original file, and the slightly more general case where you're saving back to a different filename in the same format. Is it actually possible for a user to lose the layers when saving to JPEG with gimp 2.6? The JPEG plugin asks to flatten the image, at which points the users would cancel the process if he really cares about them. You seem to be under impression that people actually read text in prompts :) Maybe many don't, but at least they can't blame you for that, can they? :-) I mean, you can get burnt by this issue once, indeed. Not once, not even by a long shot. People tend to relax and become overly confident. And as I noted before, the GIMP 2.8 behavior does not protect against the kind of overconfidence where you think you're just not going to need the layer information in the future. You've made a conscious choice at that point not to save it. and in any case you can't blame the gimp developers if you didn't read a questions which appeared while saving your extremely important file. :-) Our job is not to point fingers and accuse. Our job is to create software for a certain target group of users described above. Or do you have reports when this did not occur for some reasons? https://mail.gnome.org/archives/gimp-user-list/2012-November/msg00190.html It seems that it happened with 2.8 Does it? What makes you think so? https://mail.gnome.org/archives/gimp-user-list/2012-November/msg00193.html -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Mon, 19 Nov 2012 15:33:06 +0100, Simon Budig wrote: Robert Krawitz (r...@alum.mit.edu) wrote: On Mon, 19 Nov 2012 14:44:12 +0100, Simon Budig wrote: [...] Layer information lost. (Note that this was just a specific scenario to answer Albertos Question if there is a workflow that actually loses data. Not intended as a new argument or anything) Fine. But after this happens once or twice, users will understand what's going on. It really isn't necessary for everyone to be inconvenienced, with no way out, just to protect inexperienced users. That the saved flag gets set after an export to JPEG is just wrong. It has bitten users regardless of their experience. Even worse: Even typing a filename ending in .xcf doesn't guraantee that a xcf actually gets saved: you could have selected the jpeg filetype manually in the drop down box manually. If a JPEG was opened, edited, and saved via file/save (rather than file/save as), particularly if no layers have been added, I think it's a reasonable assumption that that was the user's intention. If not, there could be a checkbox Warn me next time that the user could uncheck. Firefox does this when you try to close a window with a lot of tabs open; if you uncheck the box, you don't get the warning next time. But in that case you've made a conscious decision to ignore the warning. Note that this doesn't apply if you've actually opened an XCF file, or have ever in the session saved the file as an XCF file. In that case, I think you have a completely valid point. True, this is a contrieved example, but the whole point is, that it is not easy to tell at any given time, if an image currently is saved safely or unsafely. Sure, people with good memorizing capabilities can track the state, but they shouldn't have to. Perhaps it was never their intention to *ever* have an XCF file. By the way, I suggest reading up on alarm fatigue. This is a problem in hospitals, where there are lots of monitors designed to detect changes in a patient's condition and sound an alarm. This happens so much that staff often ignore alarms just because they simply cannot process them all. It isn't even necessarily conscious; it's just that after a while the alarms become so repetitive that they get ignored. I suggest that the 2.8 behavior may inadvertently have the same result: you get so many unsaved file dialogs thrown in your way to save a file as a JPEG and never save as an XCF that you inadvertently forget to save an *actual* open .XCF file (as opposed to 10 JPEGs you've been editing that you never intended to save as an XCF in the first place). -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Mon, 19 Nov 2012 15:35:59 +0100, Michael Schumacher wrote: Von: Robert Krawitz r...@alum.mit.edu And as I noted before, the GIMP 2.8 behavior does not protect against the kind of overconfidence where you think you're just not going to need the layer information in the future. You've made a conscious choice at that point not to save it. This may change in future versions - where maybe you won't even have the choice not to save, because saving has become so cheap that it can be done any time, and the program just does it for you. This can become really annoying, really fast... Applications that helpfully save their constantly can cause a lot of grief if I change something I really, really didn't want to change that causes something very strange to happen. Yes, I know about the undo stack and all that, but... Hopefully, it will be something like an incremental (journaling) save with periodic compaction/resave, so that if something goes wrong all I have to do is roll back the journal. There's also the problem that this will quickly consume a lot of disk space. Again, I'm well aware that disk space is cheap, but when you're editing 100 megapixel panoramas (which I do quite a bit of), it can chew up disk space in a hurry. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
, results in either data loss or unintended data disclosure. And don't say people should always be careful about what they do -- they aren't, which is exactly why this feature was devised, and the phenomenon of alarm fatigue is very real. I sometimes do quick edits and sometimes spend a lot of time editing an image (reasonable is in the eye of the beholder -- some people prefer to process lots of images, some people prefer to craft a single image with the utmost of care, and some people sometimes do both). For the latter, the new behavior is good, but for doing quick edits, it's very, very frustrating. So, for closing my arguments, I think it would not be hard to do a *script* that checks and unchecks that save confirmation preference for you when you open a .xcf file and a common image file. That would solve the problem AND be conceptually correct, at least in my humble point of view (I might be wrong with the easy to do script part :P ). BUT it cannot be native to the software, that is conceptually incorrect - at least in my way of seeing things. NO! NO! A THOUSAND TIMES, NO Apologies for the shouting, but this is absolutely *NOT* the way to do things! It's a great way to lose data, since you may have both .xcf files and JPEG files open in the same session, and you *don't* want to change that kind of a global preference for this purpose! The decision about save vs. export is a decision about an individual image, although many people may prefer to work one way or the other most or even all of the time. My suggestion, for what it's worth, is as follows: By default, GIMP uses the 2.8 behavior. However, an option is provided such that if the user opens a non-XCF file, edits it, and saves it back to another non-XCF format (lossy or lossless), no alarm is triggered (unless the image contains something that the format can't handle, such as layers, as 2.6 does). If an XCF file is opened, or an image is saved as an XCF file, then GIMP changes to the 2.8 behavior for that image for the duration of the session (it's meaningless to talk about it across sessions -- if you've saved it as an XCF file, exit, and edit the XCF file in a new session, it's an XCF file). No escape mechanism for that. By editing an XCF file, the user has clearly stated the desire to work that file in the native GIMP format, and conversion to any other format is then clearly an export. As far as lossless vs. lossy image formats, though, there's a much bigger problem than the slow decay of lossy formats (and that decay is pretty slow if you're starting from a 98 quality setting): 8-bit quantization. If you're doing curve manipulations, that often bits hard right from the get-go. Botching a curve edit is the most common reason to have to start over from scratch for me if I've lost the undo. Even if I haven't done that, it still causes severe quantization in a lot of cases. If the GIMP folks are worried about data loss, I suggest getting high bit depth working ASAP. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Mon, 19 Nov 2012 00:47:53 -0200, libre wanderer wrote: Em 19-11-2012 00:08, Graeme Gill escreveu: Alexia Death wrote: Even the act of loading a file into memory as pixel data and then recompressing on save is lossy for lossy formats and grayscale formats outright destroy information if the original is color. It is not This type of argument simply doesn't hold water. A file that holds the image data in a lossily compressed format positively indicates that this is what the user intends. They have chosen a certain image quality vs. file size tradeoff, and not maintaining this choice is discarding the users preferences. Sorry, I don't think is a good idea to base development decisions /suposing/ that the user knows /all/ of what he is doing. If an user don't understand loss of data and is never warned, he/she will keep saving over the file and increasingly losing data. It is much more 'humane' to start by the premise that the user should be warned. It's not very humane to keep warning the user even if the user knows perfectly well what s/he is doing and for one reason or another just doesn't care. This whole notion of the .xcf file being the project file, and everything else being derivative, is fine in principle. But it's being taken to the extreme of not recognizing that some things just aren't worth making into a full-blown project. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Fri, 16 Nov 2012 18:13:04 +0400, Alexandre Prokoudine wrote: On Fri, Nov 16, 2012 at 6:00 PM, Matthew Miller wrote: changes to the way things have been done before. But it'd also be nice if broader workflows could be taken into account. Here's mine: 1. Convert from RAW in other software. Save my originals there. 2. Select a dozen or so image for touchup work. Make jpg copies. (Occasionally, TIFF.) 3. Open all of those copies in gimp, make my adjustments (generally 5-15 minutes of work each), and close each as I'm done. So you are dumping your changes after editing and can't adjust them later. It is precisely the kind of workflow we call unsafe. We provided a secondary workflow to deal with that to a certain extent. Beyond that it's in the hands of community if they want the old scenario back and maintain some sort of a fork. Yes, and if I'm doing something quick and dirty, I'll take my chances on it. I know it's unsafe, and I don't care in that situation. There are plenty of cases where I *do* care, and I use .xcf format, but lots where I don't. It's also not always correct to say that they can't be adjusted later. They can in a lot of cases, with some loss of quality. I suspect it would solve 90% of the problems for people if you're always allowed to save back to the file format that the image was originally opened in (or even just to save, rather than save as). So if I open a JPEG file, ctrl-s should simply save (or internally export, if you will, and clear the modified flag). -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Fri, 16 Nov 2012 17:20:47 +0200, Alexia Death wrote: On Fri, Nov 16, 2012 at 5:14 PM, Matthew Miller mat...@mattdm.org wrote: To run with this analogy: the problem is when you *frequently* need something that is more than nano provides. In the specific case of Gimp, I don't think there's anything else that offers layers, curves, and a healing brush. I use those things all the time in quick JPEG editing. (The layers only temporarily, of course -- I'll be looking forward to adjustment layers when that work is done.) If we had a whole toolbox of photo editing tools at our disposal in Linux, I'd be less sad. There is quite a lot. Darktable and Digikam integrated editor both offer most of this(I thin latest digikam even had some healing) and are the breadknives of this workflow. Both can directly load RAW too, afaik Actually, that's the problem -- there *are* so many editors, and each one has a different interface and different limitations. I much prefer to just use one editor that has all the capabilities I need. It's important to use the right tool for the job, certainly, but image editing has the same basic primitives regardless of whether it's quick and dirty or a major project. Having to remember different commands to do curves, sharpening, denoise, levels, and such isn't very productive. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Fri, 16 Nov 2012 20:33:45 +0400, Alexandre Prokoudine wrote: On Fri, Nov 16, 2012 at 8:23 PM, Robert Krawitz wrote: XCF is always the internal state of the document. Images get imported into an internal XCF, not opened and manipulated directly. Yes, I know. But the *option* isn't fundamental. When you're driving a car, it's not a fundamental difference whether the powertrain is gasoline, diesel, steam, electric, hybrid, warp drive (well, maybe...). Your analogy is, frankly, weak. And hence the rest of it doesn't really apply. What you are saying, basically, is that users should not care how things work inside GIMP, and GIMP should not dictate the users how to work. I'm saying that users shouldn't have to care how things work internally, yes. Users who know how it works internally can get better results using XCF, but even expert users don't need that all the time. The thing is, we do not dictate users how to work, and neither does GIMP. We just make an editor for a particular workflow. Whether users, who rely on a different workflow, adopt it or not, is entirely up to them. You're throwing a gratuitous roadblock in the way of people who want to use it differently. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Fri, 16 Nov 2012 12:36:30 -0500, Liam R E Quin wrote: On Fri, 2012-11-16 at 12:04 -0500, Robert Krawitz wrote: On Fri, 16 Nov 2012 11:40:41 -0500, Liam R E Quin wrote: If you are making use of layers, you're into GIMP territory, and into the territory where saving as JPEG and losing the layers can be a problem. Emphasis on *can be*. But not always. Of course. You can drive without seatbelts if you like. You're cleverer than I am and more careful, and never have accidents on those short trips. I've only been using GIMP since 1998. But there have been times I've regretted not having layers in the saved file. Well, as it happens, this *has* happened on occasion. But the current solution wouldn't have solved the problem for me anyway, since the regret was after the fact (after I already would have exported it and exited GIMP). GIMP isn't about to revert the change. Use a script, or get used to control-shift-e instead of control-shift-s. Which still doesn't solve the problem of an exported image not being considered saved, and prompting me. I think it might be helpful if the gimp Save dialogue had a button to export instead, rather like levels has use these settings in curves. But I expect few if any of the developers are still reading this thread. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Purple fringing removal extension
On Sun, 15 Jul 2012 00:54:50 -0700, Martin Jambon wrote: On 07/14/2012 03:56 PM, Robert Krawitz wrote: On Sun, 15 Jul 2012 01:19:52 +0400, Alexandre Prokoudine wrote: On Sat, Jul 14, 2012 at 12:35 PM, Martin Jambon wrote: Hi, I am totally new here but I wrote a standalone program that does a decent job of removing purple fringing from photos, and I would like to be able to implement the same functionality for Gimp. Here are some examples of what it does: http://mjambon.com/purple-fringe/examples.html My algorithm needs to perform pixelwise operations (+, -, min, max between two channels; scaling of one channel) but I also would prefer something that is easy to install (for users) and easy to maintain (for me). The OCaml source code is here; it should give an idea of what's needed: https://github.com/mjambon/purple-fringe/blob/master/src/unpurple.ml (see functions make_purple_blur and remove_purple_blur, lines 103-177) My questions are: 1. Is it possible to do that using a Gimp script? 2. If so, Scheme or Python? 3. If a plugin makes more sense, will average users be able to install it for themselves or would I have to wait for the inclusion in some standard precompiled distribution? Just in case, are you aware of http://kcd.sourceforge.net/fix-ca.php ? BTW, Martin, I'd suggest optimizing it -- 1 second/megapixel is a fair amount of time for someone processing a lot of 18 MP images, and people with Nikon D800's will be even more unhappy. You may also want to talk with the ImageMagick folks about getting it included there. This could become a very important part of a photographic workflow. Right. I'd like to try built-in implementations of blur algorithms first, since it is likely to remain the bottleneck of my algorithm. If that's not enough, some parallelization should help. Have you profiled the code yet? -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Purple fringing removal extension
On Sun, 15 Jul 2012 01:19:52 +0400, Alexandre Prokoudine wrote: On Sat, Jul 14, 2012 at 12:35 PM, Martin Jambon wrote: Hi, I am totally new here but I wrote a standalone program that does a decent job of removing purple fringing from photos, and I would like to be able to implement the same functionality for Gimp. Here are some examples of what it does: http://mjambon.com/purple-fringe/examples.html My algorithm needs to perform pixelwise operations (+, -, min, max between two channels; scaling of one channel) but I also would prefer something that is easy to install (for users) and easy to maintain (for me). The OCaml source code is here; it should give an idea of what's needed: https://github.com/mjambon/purple-fringe/blob/master/src/unpurple.ml (see functions make_purple_blur and remove_purple_blur, lines 103-177) My questions are: 1. Is it possible to do that using a Gimp script? 2. If so, Scheme or Python? 3. If a plugin makes more sense, will average users be able to install it for themselves or would I have to wait for the inclusion in some standard precompiled distribution? Just in case, are you aware of http://kcd.sourceforge.net/fix-ca.php ? That fixes lateral chromatic aberration (the focal length, or image magnification, is different for different wavelengths but the focal plane is the same). Purple fringing is caused by longitudinal chromatic aberration (the focal plane is different for different wavelengths). It's a different lens defect and is much more difficult to fix (stopping down reduces the problem, since it increases depth of field, but there are often reasons why you don't want to do that). Lateral chromatic aberration will be zero at the center of the image and will increase toward the edges; longitudinal chromatic aberration will affect the entire image field (including the very center) more or less equally. Martin's tool looks very impressive, particularly for those of us who have the Canon 85 f/1.8 -- a truly great lens marred only by a fair bit of purple fringing at large apertures. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Purple fringing removal extension
On Sun, 15 Jul 2012 01:19:52 +0400, Alexandre Prokoudine wrote: On Sat, Jul 14, 2012 at 12:35 PM, Martin Jambon wrote: Hi, I am totally new here but I wrote a standalone program that does a decent job of removing purple fringing from photos, and I would like to be able to implement the same functionality for Gimp. Here are some examples of what it does: http://mjambon.com/purple-fringe/examples.html My algorithm needs to perform pixelwise operations (+, -, min, max between two channels; scaling of one channel) but I also would prefer something that is easy to install (for users) and easy to maintain (for me). The OCaml source code is here; it should give an idea of what's needed: https://github.com/mjambon/purple-fringe/blob/master/src/unpurple.ml (see functions make_purple_blur and remove_purple_blur, lines 103-177) My questions are: 1. Is it possible to do that using a Gimp script? 2. If so, Scheme or Python? 3. If a plugin makes more sense, will average users be able to install it for themselves or would I have to wait for the inclusion in some standard precompiled distribution? Just in case, are you aware of http://kcd.sourceforge.net/fix-ca.php ? BTW, Martin, I'd suggest optimizing it -- 1 second/megapixel is a fair amount of time for someone processing a lot of 18 MP images, and people with Nikon D800's will be even more unhappy. You may also want to talk with the ImageMagick folks about getting it included there. This could become a very important part of a photographic workflow. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
On Thu, 21 Jun 2012 14:40:09 +0400, Alexandre Prokoudine wrote: On Thu, Jun 21, 2012 at 2:31 PM, Karl Günter Wünsch wrote: BTW: I asked a few of my friends (who are less into image editing but well capable of using a computer and who at most only knew the GIMP by name) what export was supposed to mean and they all responded that it was the use of external resources to store the image (FB, Flickr, Dropbox)... And that proves exactly what? :) IMHO it only shows that the split of the function is artificial in nature and that the chosen command name for one of the most used function (no matter what you do, you can't upload an xcf for presentation on the web nor can you send in an xcf to a printer nor can you do anything worthwhile with an xcf outside the very limited world of the GIMP - so saving under a different format is a must for any user and export isn't the first command name that comes to mind of anyone if searching for this option) is ambiguous at best and progressively misleading in todays environment... What you are saying is: 1. We made a clear separation between saving and exporting... 2... where saving means preserving all project data for internal use 3... and exporting means saving a new file that is typically a JPEG or PNG for external use. No, export means the act of *sending* the image to the external resource, not converting the format. If a service provider accepts XCF files directly for download, the act of transferring the file is still an export by this definition. Think in physical terms. Transporting an object from country A to country B is exporting it from country A, whether or not anything is changed about the object (repackaging, changing the electrical plug, etc). 4. Your friends actually understand that separation on a user level. 5. Which makes us wrong. In other words, you've just given us an example that supports our vision, while claiming that it contradicts it. That's one hell of an IMHO from you :) -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
On Wed, 20 Jun 2012 22:50:01 +0400, Alexandre Prokoudine wrote: On Wed, Jun 20, 2012 at 7:53 PM, Guillermo Espertino (Gez) wrote: But I just had an idea (sorry if anybody already suggested it and I missed it): What if the merely harmeless to downright offensive popup saying that Save is for XCF offers an extra button labeled export anyway or something similar? A universally accepted truth is that users don't read warnings. This will surely freak out few geeks who do read warnings carefully and recite them occasionally over a pint of beer in a pub, but mostly people really try to make stupid dialogs go away ASAP. If they don't, their bad fortune. Making a common operation less convenient for everyone because some user may not realize what's going on -- and no way to turn off the inconvenience -- is unnecessarily paternalistic, IMHO. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
On Thu, 21 Jun 2012 01:13:29 +0400, Alexandre Prokoudine wrote: On Thu, Jun 21, 2012 at 12:48 AM, Robert Krawitz wrote: If they don't, their bad fortune. Making a common operation less convenient for everyone because some user may not realize what's going on -- and no way to turn off the inconvenience -- is unnecessarily paternalistic, IMHO. Well, if you don't read warnings in this very list about http://gui.gimp.org/index.php/Vision_briefing, it's your bad fortune :) It's been mentioned a thousand times that it's not just about making mistakes while saving, that there's also such a thing as creating complex images from scratch being the focus. And that's fine, but surely experienced users will know this before long? The real use case that I see is quick editing of a JPEG or PNG file. Something I suspect a lot of even hard core professional users do from time to time. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
On Sun, 17 Jun 2012 12:55:56 +0200, peter sikking wrote: I am going to summarise it because you are doing some catching up in there that bloats the mail: - you recognise that there is a competing situation between two different types of use There are more than two different types of use. - you say there is a problem with File-Open importing non-GIMP images - you have realised that xcf files are great for persisting work and are acknowledging the Project reality of graphics work. Absolutely. But sometimes the project is very simple, such that I'm very confident I'm not going to need to revisit it (or that I'm just going to tweak the curves or otherwise do something that doesn't need layers -- when GIMP has 16 or 32 bit depth, that might be a different matter, and if I think I might want to revisit it later, I'll simply save it as an XCF file). Certainly there are other tools around that are designed for simple things like that, but if I'm familiar with GIMP, it's easier to use the same tool for both. here is my reaction to that: in short you want the old situation back, with the clear and unambiguous working-on-a-GIMP-file workflows being secondary to the one-shot png-in, png-out (same for jpeg, tiff, etc) workflows. this is clear from how you label the menus. I have two reasons to say: no way. the first one is how GIMP works: it can only edit GIMP files. sure, this is a superset of the simple file formats that we all like to take as examples: jpeg/png/tiff. it is not for other ones (ps to start with, there must be more import/export supported formats that have things GIMP cannot do). the old fudge that we got rid of in 2.8 is GIMP communicating that it is editing a non-GIMP file, when it is not. How GIMP operates *internally* and what it presents to the user don't have to be one and the same. Libre/OpenOffice use ODF as the native file format, but if I want to save it as a Word file, I simply Save As, or Save if what I originally opened was a Word file. Internally, though, I believe it's operating on (a representation of) an ODF file. so you either import/export into GIMP format at the boundaries of the GIMP app and be clear about it. this is what we do now. or you do your plan, build in non-GIMP-file-workflows, where for each non-GIMP file type, you have to build a mode for GIMP where what is on the screen matches what is in the file, right after invoking Save. remember, this is the law. Why is that the law? If I'm saving as a JPEG, I know that there will be loss. But that's my lookout. the second reason for saying no is checking the vision and what it means: http://gui.gimp.org/index.php?title=Vision_briefing this makes me 100% sure that the Project/Work workflow with persisted GIMP files is number one for our target user groups. one-shot working is a distant second. That's fine, but how does preventing Save to a JPEG file interfere with that? Your target audience knows that a JPEG file will lose information. What it does is require using a separate operation for exporting, which would seem to get in the way of speed, speed, speed. save + export has been designed for that, with added benefits of independently saving and exporting the same Work, and no more lost Work. In 2.6, JPEG save already warns if the image has multiple layers. the success of this design is validated by the reaction of the target user groups, which ‘get it’ instantly, although I also changed _their_ keyboard shortcuts and put ‘unsaved changes’ dialogs in their way. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
On Sun, 17 Jun 2012 01:51:30 +0400, Alexandre Prokoudine wrote: On Sun, Jun 17, 2012 at 1:02 AM, gg wrote: Was it a deliberate attempt to spill some oil into the fire? Thank you for that. We are all extremely interested in another shout contest. No, it was a deliberate attempt to point out that you (one) cannot constantly use the top-end target argument , then turn around and the GUI has to guide the user to know what is safe or not and must be prevented from saving work which has layers in anything but xcf because they won't realise that png , whatever, will loose the layers. You (one) cannot use an argument when it suits you, then assume the opposite later. No oil, just a simple statement of logic. Logic? Awesome joke, gg. You are basically saying that professionals don't make mistakes, and if they do, it's all right, they don't fret. This is just silly. First of all, everyone makes mistakes, professionals are not robots. But this is not the point. The point is that saving means being able to have access to all the project/work data in the future. This has been stated millions of times, and the fact that you keep going on and on about this can only mean that you are trying to be a pain in the arse. The current behavior is designed for people who work on multiple layers and, generally, make the most of GIMP features. Noone says you've got to love it. Feel free to hate it, just do it elsewhere. It's designed for people who work on multiple layers and don't realize that saving in other formats destroys those layers. In 2.6, if you try to save an image with multiple layers as a JPEG, the save dialog warns you that you need to collapse them. If you save a single layer image as a JPEG, no warning. That seems like reasonable behavior. Forcing you to do something non-obvious in the case of doing a quick edit to a JPEG isn't. -- Robert Krawitz r...@alum.mit.edu MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four! Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] git print dialog doesn't see CUPS printers
On Sun, 01 Jan 2012 16:55:39 -0700, Michael J. Hammel wrote: I've got a printer configured under CUPS. GIMP 2.6 installed from yum on F14 sees the printer okay. My custom built GIMP 2.7 does not. I built the print plugin, which doesn't appear to have any CUPS related dependencies that I can see. The print plugin only shows print to file and print to lpr. Also, I wonder if the 2.6 build is just using the GTK+ print dialog? Seems a little different than the GIMP 2.7 Print plugin. I've looked through the configure options for GTK+ and GIMP and the only meaningful print option appears to be to disable building the print plugin for GIMP. I don't see anything related to specifically using CUPS. You may need to install the CUPS development package and rerun configure (remove config.cache first). Is there another library that needs configuration for use with CUPS in order for GIMP's print dialog to see the printer? FYI: I built Gutenprint's plugin and it sees the printer okay. Gutenprint uses a hacked-up mechanism based on lpstat or lpc (as appropriate) to query printers. It's ugly, but it works on a wide variety of systems. -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
