Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
Glimmer Labs wrote: > However, even if we were to build this in an > extension, from looking at re and ftx, it seems like we'd still need > mk_foreign_func'ed functions, at least one of which would still need > to use scheme_call. Do you know of another way to assign arguments to > and evaluate a closure passed to a foreign function from tinyscheme? Have you also looked at init_procedures() and marshall_proc_db_call() in the scheme_wrapper.c file? You will find other examples of defining Scheme routines that will call C when invoked and which require parameters. That is about all I can suggest for the moment without knowing the specifics of the situtation where you feel you have to use scheme_call. > Do you know if Jonathan Shapiro/Dimitrios Souflis are still actively > maintaining tinyscheme? AFAIK, they are still maintaining TinyScheme although I don't know how actively. Jonathan had also talked of doing a rewrite of TinyScheme but I haven't heard anything further on that issue. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 2007-07-10 at 19:41 +0200, Sven Neumann wrote: > On Mon, 2007-07-09 at 18:37 -0400, Liam R E Quin wrote: > > > For my part I miss "save a copy as..." which in some programs > > saves the file like Save As but doesn't change the filename of > > what's being edited. > > GIMP 2.3 has this feature for quite a while already. Oops, so I missed it but Gimp didn't -- thanks for replying!! > > I wonder if it'd be possible, for gimp 2.6, to consider unifying > > the output plugins a bit, so that you can have a pull-down of file > > formats and see the parameters for each format before you hit save, > > Something along those lines has been suggested before. It's rather > difficult to implement but if someone would come up with a decent plan > it would be worth trying. I'll take some time to think about it, in case it is of use, and will write something up for 2.6. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
So I broke my promess. > creating interaction requires making hard choices, because you > cannot make an application for everybody. I have to agree. A good UI doesn't do what users ask. It does what is better for the users. ;-) This approach of taking the lossy format to an import/export section instead of open/save is very interesting and, even though users will have to get used to, will define a more robust professional workflow. For now, the "Save as" patch is a good temporal fix. What's very important is that the problem of the arbitrary behaviour of the jpeg saving was addressed and users who ignore the whole issue won't be wrecking their images anymore. Thanks! Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Mon, 2007-07-09 at 18:37 -0400, Liam R E Quin wrote: > For my part I miss "save a copy as..." which in some programs > saves the file like Save As but doesn't change the filename of > what's being edited. GIMP 2.3 has this feature for quite a while already. > I wonder if it'd be possible, for gimp 2.6, to consider unifying > the output plugins a bit, so that you can have a pull-down of file > formats and see the parameters for each format before you hit save, Something along those lines has been suggested before. It's rather difficult to implement but if someone would come up with a decent plan it would be worth trying. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor
Quoting [EMAIL PROTECTED]: > On Tue, 10 Jul 2007 01:24:40 +0200, > <[EMAIL PROTECTED]> wrote: > >> If I have >> a Quality setting of 95 and I load an image that was saved with a >> Q=50, I should be very disappointed if the GIMP degraded to that level >> when I have specified that I expect less loss when saving. > > It would NOT degrade it because it already was that quality. Saving it > a 95 would increase filesize by about a factor of 8 without any gain in > quality! You would not have less loss. > You presume that I have done nothing to improve the content of image. The file saved IS degraded relative to the image I am editing. > If you want to change the nature of the image format user SaveAs. > > Save should keep things the way they are as near as possible. No. If you want to specify something other than a user-specified default for an acceptable level of quality while editing in the GIMP (for example, overriding it with an image-specific value), that is when you should use Save As. If file size is your main concern, use Save For Web. If honoring the user's expectations with regard to image quality is your focus, Save should recognize user-specified default settings. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On 7/10/07, Raphaël Quinet wrote: > GIMP parasites, etc. In fact, even the current XCF loses some > information if you consider that it does not record the full undo > history and the current tool contexts, but this is something that > most users accept. They really do? Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 09:51:24 -0700, Akkana Peck <[EMAIL PROTECTED]> wrote: > Another thing I'm unclear on in this thread: when I first heard the > idea of forcing Export instead of Save, the plan seemed to be that > Save would always save XCF, and anything else would require Export. > But now you seem to be telling us that the issue is lossiness, and > the point of Export is to make it more hassle to save to lossy formats, > to discourage use of those formats. Does that imply that Save will > include PNG, TIFF and other non-lossy formats? If you consider the whole image (including layers, metadata, etc.), then the only lossless image format is XCF. All other formats drop some information: PNG cannot save layers, TIFF cannot save all GIMP parasites, etc. In fact, even the current XCF loses some information if you consider that it does not record the full undo history and the current tool contexts, but this is something that most users accept. So I think that the statement from Peter that singled out indexed image formats and JPEG was slightly misleading (and this triggered my initial reaction). Basically, only XCF would be "saved" and all other image formats would be "exported". -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
peter sikking writes: > But in between, as long as it is not finished, there is no role for > jpeg. Only one decompression at the beginning and a compression of the > end result is defendable in high-end graphics. I'm seeing an unspoken assumption in this thread that most photos are edited in multiple sessions: read into gimp, do a few operations, write to disk, read back in (perhaps hours or days later), do a few more operations, write back out, repeat. In my experience, it's much more common to read a jpeg in once and do a lot of operations on it in one session, saving periodically. There's no cumulative loss of quality: the intermediate saves are in case of disaster like a power failure, not a way to quit gimp and continue the editing process later. But I think I remember Sven saying recently that Export would be able to save without prompting each time, after the first time. (I guess that means there will also be an Export As, in case you need to change the filename?) So those of us who often work in JPEG could use it just like we use Save now, and even bind ^S to it. > If users get the hint > that opening and saving the same jpeg again and again is a pain (also > for the quality) and that either adopting a high-end GIMP file workflow > or moving to another (mid-fi) app to work in their lossy jpeg way. Another thing I'm unclear on in this thread: when I first heard the idea of forcing Export instead of Save, the plan seemed to be that Save would always save XCF, and anything else would require Export. But now you seem to be telling us that the issue is lossiness, and the point of Export is to make it more hassle to save to lossy formats, to discourage use of those formats. Does that imply that Save will include PNG, TIFF and other non-lossy formats? -- ...Akkana "Beginning GIMP: From Novice to Professional": http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 18:26:38 +0200, "Michael Schumacher" <[EMAIL PROTECTED]> wrote: > Von: "Raphaël Quinet" <[EMAIL PROTECTED]> > > We also have to be humble and remember that writing down the current > > vision only took us a couple of hours, not 5 years (basically one hour > > of discussion at LGM plus some e-mail exchanges while we were > > polishing the minutes). > > ... plus the better part of two days during the GIMP usability weekend in > Essen. And this does still not take Kanila's and Peter's effort into account. I was referring to the vision, not to the use cases. But you are right that a lot of work was also invested in the usability aspects derived from the vision, and Peter and Kamila should of course be credited for that. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking <[EMAIL PROTECTED]> wrote: > There is also a real benefit in opening a jpeg and then saving > the result in another (GIMP) file. We see from the explanations in this > thread that opening a jpeg and then saving it again means a loss of > information. So overwriting an original is a loss. Working on a > full-fidelity copy version is preferred. Note that in the workflow that I described, I never mentioned overwriting the original. On the contrary, I said that the final JPEG file would be saved under another name. > The early part of this thread is full of misunderstanding at which > point working with jpeg incurs quality loss. I say it is because of > the "you can work in jpeg" myth. I am still confused that you talk > about saving intermediate results while working on a jpeg. Either > each save reduces quality (implicit save and reload, ouch) or there > is a penalty for closing the file and reopening it, because you > lost the full-fidelity internal (GIMP) representation, ouch. I am not sure about what others had in mind in this thread, but I I was mostly focusing on corrections to the source photos such as correcting the exposure or color balance and making other minor edits with the clone tool, etc.. These steps can be performed in a single session without having to save any full-fidelity internal representation. When I mentioned saving intermediate results, I meant saving copies of the image that you are currently working on, if you want to check how the final output will look like (including losses due to compression). If you intend to work further on the image or to re-use some parts of it in a collage or in a more complex work, then it certainly makes sense to save the XCF version (or any other lossless format). The same applies if you work more than a few minutes on the image and it would cost too much to re-do these changes from the original in case you decide some weeks later that you need to apply more changes to the image. But for the simple workflow that I described (which is or was rather common for me), in which simple corrections have to be applied to a large number of images without intending to work on them further, then it makes sense to have JPEG as input and as output without wasting time or space with intermediate formats. > So I see real benefits for a high-end image manipulation program > that lossy formats are pushed out to the very beginning and very > end of the workflow. That the working copy of the file is GIMP format, > in full fidelity, any GIMP operation naturally possible, and with > no penalty for opening and closing the file. I am not disputing that. We should encourage users to use the lossless XCF format for all things that may need to be edited later or re-used in other images. As long as this can be done without breaking common workflows, then it's fine. I don't mind if the simple load-edit-save cycle for JPEG images produces a warning the first time I do that, telling me that saving in JPEG will result in a quality loss and recommending XCF for saving any work-in-progress. But would mind getting this warning every time or being forced to use a different menu option than the normal Save for the second and subsequent attempts at saving the image. This is how I interpreted your initial reaction. If I misunderstood what you meant and you did not intend to break the flow, then I am sorry for the misunderstanding and we can forget about it because there is really no issue. -Raphaël P.S.: If this issue is cleared and we ignore the arguments for the sake of argumenting (my previous message), then I think that I have a solution for the original issue mentioned in this thread: this is very close to the patch proposed by Tor and it also supports JPEG files that were not created by libjpeg. More about that later, when my code is ready. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 16:32:11 +0200, peter sikking <[EMAIL PROTECTED]> wrote: > Raphaël wrote: > > I would like to temper this a bit (not agent provocateur as gg, > > but maybe devil's advocate): a team that is too rigid about its > > vision and never adapts it over time runs a real risk of > > becoming irrelevant after a while. On the other hand, having > > no vision at all or ignoring it and running like headless > > chicken is usually worse. > > I agree that a product vision, like a national policy, > should be reviewed every, say, 5 years. Do realise that > when you chance the the vision, that you restart, from zero, > a process that takes about 5 years. And thanks for saying > that ignoring the vision is worse. We also have to be humble and remember that writing down the current vision only took us a couple of hours, not 5 years (basically one hour of discussion at LGM plus some e-mail exchanges while we were polishing the minutes). Again, I am playing the devil's advocate here, just trying to counter-balance your argument: I agree with the vision and I think that we should all follow it; however, I also want to be realistic and not see it as a sacred thing that is cast in stone. > > But one should always balance the interest of the few who are > > targeted by our product vision with the interest of the > > majority of the users who are not necessarily part of that > > vision. > > Few? there are millions of users within our vision out there. > And if we work to make GIMP represent this vision coherently > in the UI, then GIMP will become a viable, natural choice for > the people we want to use it. Sorry, but I have to disagree here. If you just look at the part of the product vision that says "GIMP is ...", then it could apply to a large number of GIMP users. But if you look at the context of the vision (which is not explicitely written in that section, but is part of the "Targeted user base" in the meeting minutes and the "user scenarios" + "expert evaluation" on gui.gimp.org), then it is clear that the vision is targeted at experienced, professional users. This is at best a small percentage of the current GIMP users. As I wrote elsewhere, our current vision is rather elitist (the vision itself or how it is usually referred to). Again, there is nothing wrong with that because this is usually the only way to have real progress. But we have to acknowledge that the vision (or the way we use it) is targeted mainly at a minority of users. This minority is almost certainly the most interesting subset of our users, but it is a minority nonetheless. > And I thought that we all understand that there is a > choice of several free software programs out there for > users who want to do simple red-eye removal from their > holiday jpegs. Unfortunately, until that choice really exists this is a moot point. Basically, there is currently no good free software alternative to Photoshop Elements or even to the simple program (proprietary, Windows-only) that was delivered with my camera and allows one to quickly browse images, correct red eyes, exposure or color casts, crop/resize images and view/edit metadata. F-Spot comes very close to doing all that, but still has some weak spots that require you to use GIMP, Krita, mtPaint or Paint.NET for adjustments. Many of the quick actions provided in Photoshop Elements (which comes bundled with some cameras) are not available in any free program yet. Again, I am not saying that we should do all that and try to solve all problems in GIMP. I prefer to stick to the current vision. I am just continuing my devil's advocate role and stating that you should not claim that there is a choice when the choice does not really exist. > > In other words, a decision that provides a small > > improvement for the target users but implies a significant > > regression for all other users should be considered very > > carefully. > > Actually in this case it the other way around. There is > a significant improvement for target users, with clarification > of image degradation of everyone, and little or no regression > for the lossy-jpeg users. We seem to disagree on that, but maybe it is better if I address this point in a reply to your previous message. > > Again, to temper things a bit: this was only a subset of the > > developers present at LGM last year (GIMPCon 2006, see the > > minutes at http://developer.gimp.org/gimpcon/2006/ and read > > the section "GIMP Vision"). > > This is a slippery slope. If anybody can excuse themselves from > the vision when they personally do not like the logical outcome > of applying it to a hairy UI design question, and bang in their > "yeah, but what about me" feature into svn, then we are back at > the headless chickens state. Unfortunately, you skipped the part of my message in which I wrote: "It is always possible for someone to propose someting that goes against the current consensus and hopefully convince others that this is the ri
Re: [Gimp-developer] jpeg quality factor.
Von: "Michael Schumacher" <[EMAIL PROTECTED]> > Kanila's Kamila, sorry for misspelling your name. Michael -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Von: "Raphaël Quinet" <[EMAIL PROTECTED]> > We also have to be humble and remember that writing down the current > vision only took us a couple of hours, not 5 years (basically one hour > of discussion at LGM plus some e-mail exchanges while we were > polishing the minutes). ... plus the better part of two days during the GIMP usability weekend in Essen. And this does still not take Kanila's and Peter's effort into account. HTH, Michael -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Raphaël wrote: >> creating interaction requires making hard choices, because you >> cannot make an application for everybody. For that you use the >> product vision that you set as a team at the beginning of the >> project. And then you don't fudge when the moment is there. > > I would like to temper this a bit (not agent provocateur as gg, > but maybe devil's advocate): a team that is too rigid about its > vision and never adapts it over time runs a real risk of > becoming irrelevant after a while. On the other hand, having > no vision at all or ignoring it and running like headless > chicken is usually worse. I agree that a product vision, like a national policy, should be reviewed every, say, 5 years. Do realise that when you chance the the vision, that you restart, from zero, a process that takes about 5 years. And thanks for saying that ignoring the vision is worse. >> You make hard choices about which features to include and >> which not. Which workflows to actively support and streamline, >> and which go on the back seat. About beginners vs. Experts. > > But one should always balance the interest of the few who are > targeted by our product vision with the interest of the > majority of the users who are not necessarily part of that > vision. Few? there are millions of users within our vision out there. And if we work to make GIMP represent this vision coherently in the UI, then GIMP will become a viable, natural choice for the people we want to use it. And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs. We cannot make GIMP for them if we want to make it for the high-end market. One of them has the priority, and the other can use GIMP at their own risk. It took me 5 second to agree with the maintainer of Krita to agree that GIMP and Krita are not competitors, they serve two different markets, and can happily live side by side. > In other words, a decision that provides a small > improvement for the target users but implies a significant > regression for all other users should be considered very > carefully. Actually in this case it the other way around. There is a significant improvement for target users, with clarification of image degradation of everyone, and little or no regression for the lossy-jpeg users. > Our current vision is rather elitist. This is not a bad > thing because this is often the only way to make real > progress. But we should also be aware of its consequences. Well, you have chosen that GIMP is a fast driving machine, able to compete with the best. Do you mind that I try to focus us on that when the question is "what about going shopping?" or "what about taking driving lessons in our machine?" >> Sven did not set the product vision, the GIMP team did by >> consensus. I only moderated that session. But I am here to >> implement that vision on an user interaction level. > > Again, to temper things a bit: this was only a subset of the > developers present at LGM last year (GIMPCon 2006, see the > minutes at http://developer.gimp.org/gimpcon/2006/ and read > the section "GIMP Vision"). This is a slippery slope. If anybody can excuse themselves from the vision when they personally do not like the logical outcome of applying it to a hairy UI design question, and bang in their "yeah, but what about me" feature into svn, then we are back at the headless chickens state. Please, do not get cold feet when the law of nature that we cannot make everybody happy becomes apparent. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 12:29:23 +0200, peter sikking <[EMAIL PROTECTED]> wrote: > creating interaction requires making hard choices, because you > cannot make an application for everybody. For that you use the > product vision that you set as a team at the beginning of the > project. And then you don't fudge when the moment is there. I would like to temper this a bit (not agent provocateur as gg, but maybe devil's advocate): a team that is too rigid about its vision and never adapts it over time runs a real risk of becoming irrelevant after a while. On the other hand, having no vision at all or ignoring it and running like headless chicken is usually worse. > You make hard choices about which features to include and > which not. Which workflows to actively support and streamline, > and which go on the back seat. About beginners vs. Experts. But one should always balance the interest of the few who are targeted by our product vision with the interest of the majority of the users who are not necessarily part of that vision. In other words, a decision that provides a small improvement for the target users but implies a significant regression for all other users should be considered very carefully. Our current vision is rather elitist. This is not a bad thing because this is often the only way to make real progress. But we should also be aware of its consequences. > Sven did not set the product vision, the GIMP team did by > consensus. I only moderated that session. But I am here to > implement that vision on an user interaction level. Again, to temper things a bit: this was only a subset of the developers present at LGM last year (GIMPCon 2006, see the minutes at http://developer.gimp.org/gimpcon/2006/ and read the section "GIMP Vision"). I hope that this was a representative subset of the GIMP contributors (of course it was, I was there!) but we should also keep in mind that nobody has absolute authority over the GIMP project. It is always possible for someone to propose someting that goes against the current consensus and hopefully convince others that this is the right thing to do. This may be good or bad depending on the context (it should also be possible to stop useless arguments by saying that something is out of scope for GIMP). I am not judging the merits of the way we work, but just stating that this is something to keep in mind. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
gg, my dear agent provocateur, creating interaction requires making hard choices, because you cannot make an application for everybody. For that you use the product vision that you set as a team at the beginning of the project. And then you don't fudge when the moment is there. You make hard choices about which features to include and which not. Which workflows to actively support and streamline, and which go on the back seat. About beginners vs. Experts. Sven did not set the product vision, the GIMP team did by consensus. I only moderated that session. But I am here to implement that vision on an user interaction level. That means I make hard choices, based on the vision, the way thing work technically and our workplace observations. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor
Quoting [EMAIL PROTECTED]: > On Tue, 10 Jul 2007 01:24:40 +0200, > <[EMAIL PROTECTED]> wrote: > >> If I have >> a Quality setting of 95 and I load an image that was saved with a >> Q=50, I should be very disappointed if the GIMP degraded to that level >> when I have specified that I expect less loss when saving. > > It would NOT degrade it because it already was that quality. Saving it > a 95 would increase filesize by about a factor of 8 without any gain in > quality! You would not have less loss. > You presume that I have done nothing to improve the content of image. The file saved IS degraded relative to the image I am editing. > If you want to change the nature of the image format user SaveAs. > > Save should keep things the way they are as near as possible. No. If you want to specify something other than a user-specified default for an acceptable level of quality while editing in the GIMP (for example, overriding it with an image-specific value), that is when you should use Save As. If file size is your main concern, use Save For Web. If honoring the user's expectations with regard to image quality is your focus, Save should recognize user-specified default settings. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tuesday, July 10, 2007, 8:09:04, Chris Mohler wrote: > I understand that JPEG drops data. My point: in most applications, > 'save' means "save your data". In the image editing world, 'save' has > come to mean "save as much data as you want given the limitations of > the format - here are (or might be) some options". Maybe GIMP could do it the way CoolEdit (audio editor for windows) does it - when you save to a lossy format, it pops up a warning telling you that you shouldn't use that file for intermediate storage, but only for the final product. -- < Jernej Simončič ><><><><>< http://deepthought.ena.si/ > Nothing ever gets built on schedule or within budget. -- Cheops's Law ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Suggestion] Windows .lnk shortcuts
ICMP Request writes: > Although I have to recognize that it's a very low priority issue, could > be nice to see it implemented on new versions. Thanks for the suggestion. This problem is already reported in our bug tracking system. See http://bugzilla.gnome.org/show_bug.cgi?id=163544 . It will be fixed eventually. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [Suggestion] Windows .lnk shortcuts
Hello guys! Gimp is a GREAT program, not only for Linux but also for Windows, and I'm loving it. However I have a suggestion: Sometimes on Windows Explorer I create the windows version of "Symbolic Links", the Shortcuts, which are redirects to, e.g., another folder. So if I have e.g. C:\Test\Gimp, "Gimp" can be a shortcut to something like D:\Gimp . Windows Explorer makes it as an .lnk file. However, Gimp does not recognize it when using the open/save menu and say it's an "invalid file" rather than following the shortcut to its destination folder. Although I have to recognize that it's a very low priority issue, could be nice to see it implemented on new versions. Regards, -- ICMP Request - Don't forget to call me when you ping! Mail/MSN: [EMAIL PROTECTED] x86 Intel Prescott 32-bit Platform - Linux 2.6.20.1 Registered Linux User #449464 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
