Re: [Gimp-developer] API for time of last change vs. last export
On Sun, Nov 18, 2012 at 3:12 AM, Akkana Peck akk...@shallowsky.com wrote: On the thread-which-shall-be-nameless, when folks were asking for a way to quit GIMP without being prompted to save files that had already been exported, Alexia wrote: Oh, let me throw up this idea for you - you do not need a fork, just a script to override the default close... Very easy to install, maintain and distribute. No fork needed. Alexia, how? I looked into it, but couldn't figure out any way to do it. Good question. I asked mitch if this is possible and he said yes. My idea was to override the close, but now that I look at it, the problem is, that you seem to be unable to get the display for user opened image to close it... -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feedback and personal comments about Gimp 2.8
Hi Alexia. I'm providing feedback on a particular issue I had raised earlier. --- En date de : Ven 3.8.12, Alexia Death alexiade...@gmail.com a écrit : III.1. Tablet-specifics, Pen/Eraser consistency First thing I noticed in 2.8 is that I now need to select the eraser tool when I flip my pen to use the eraser. I didn't have to do that in 2.6. Your tablet is not recognized or set up right then. On gimp side, if pen and eraser are reported as separate devices, they can have separate tools. Just tested it on my system(linux, wacom tablet) It works. I've checked my two tablets, Cintiq 22HD and Bamboo Fun Pen Touch and the same issue happens in Gimp 2.8 with both tablets. Upon starting Gimp 2.8 and the first time I flip the pen to the eraser I have to manually select the eraser tool (either with the keyboard or with the toolbox icon). Both my tablets are enabled in Gimp 2.6 and 2.8. They're both recognized by the operating system (Gentoo Linux) and Gimp; they work properly. In Gimp 2.6 flipping the stylus for the eraser automatically switched to the eraser tool. In Gimp 2.8 the airbrush is selected by default for the eraser. Selecting the eraser tool manually is kept until I close Gimp. I have Gimp 2.8.2 at the time of writing this. All three (stylus, eraser and pad) are enabled, mode screen in both cases (Bamboo and Cintiq) and in both versions of Gimp. Shall I file a bug? Best regards, Vince C. ___ 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
Graeme Gill (grae...@argyllcms.com) wrote: Simon Budig wrote: We cannot just make the assumption that oh, its a JPEG. *clearly* the user wants us to discard information on saving. You really think they want you to save a lot of invented bits and blow their file up in size with all that false data ? As soon as the User does some little tiny editing we no longer can discern reliably between invented bits and important bits. They want you to save the same visible information, without any obvious further degradation. That's easily achieved by saving in a lossless format, but not very clever, and doesn't honour the quality/file size trade-off they've already agreed to and want, since they are saving back to the lossy file format they opened. The whole point we're trying to make and which you refuse to understand is, that they already agreed to and want only applies for images they created themselves from scratch. It breaks down immediately when they're working with images from other sources, like the clueless marketing droid sending you a jpeg logo file. Here the user does *not* do a concious descision towards a lossy file format. He did *not* agree to loose bits on saving even when he opened a JPEG. This whole user indicates his intent by the file format he opens just breaks down when working with images from other sources. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feedback and personal comments about Gimp 2.8
Von: Vincent Cadet v_ca...@yahoo.fr IIRC I started with a blank profile but I don't exclude I did that by accident. Look, I'll wipe out my current profile and check again to make sure. (I'm currently not able to do that right now but in a couple of hours.) Please don't do that. Wiping your profile in order to solve problems is similar to cleaning up a crime scene to make it more cozy for the cops; you'll destroy evidence that can be crucial to determine whether there might be a bigger problem than a configuration setting. See http://docs.gimp.org/2.8/en/gimp-pimping.html#gimp-prefs-tool-options for what I have in mind. You can save the settings there once, or have them saved on exit. I'm not 100% sure if this saves the tools per device (have to get back to my tablet to try it myself), bvut at least it is an option to try. Regards, Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feedback and personal comments about Gimp 2.8
--- En date de : Lun 19.11.12, Michael Schumacher schum...@gmx.de a écrit : IIRC I started with a blank profile but I don't exclude I did that by accident. Look, I'll wipe out my current profile and check again to make sure. (I'm currently not able to do that right now but in a couple of hours.) Please don't do that. Wiping your profile in order to solve problems is similar to cleaning up a crime scene to make it more cozy for the cops; you'll destroy evidence that can be crucial to determine whether there might be a bigger problem than a configuration setting. LOL. Sorry, I didn't write but of course backing it up was implied. Also, as I haven't used Gimp 2.8 thoroughly (barely at all to be honest) my current configuration is close to the defaults, except I've probably been fiddling with the settings more than I have used Gimp to paint. In the end starting with a blank Gimp profile will definitely tell if my tablets are handled properly or not from scratch. If they work properly from a blank profile then I must have saved the state of the eraser along. Or if I still need to assign the eraser tool to the eraser with a blank profile then Gimp must be doing something wrong. In both cases I don't care my Gimp profile for all I have done so far is just mess with just a few settings. See http://docs.gimp.org/2.8/en/gimp-pimping.html#gimp-prefs-tool-options for what I have in mind. You can save the settings there once, or have them saved on exit. I'm not 100% sure if this saves the tools per device (have to get back to my tablet to try it myself), but at least it is an option to try. Good. Will check that, thanks. Cheers, Vince C. Regards, Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ 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 11/19/2012 12:50 PM, Alexandre Prokoudine wrote: On Mon, Nov 19, 2012 at 2:45 PM, Alberto Mardegan wrote: for my needs was optimal; but I would also like to try to address the problems that the new export functionality tries to solve, except that I don' have a clear idea of what they are (except the image quality for compressed formats). 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). 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. But the second time you'll be more careful -- 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. :-) 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, so we could reverse the reasoning and say that the new changes don't help. Though I agree that losing layers with 2.8 is much more difficult, you will never be able to protect those users who don't carefully read your dialog messages... I would argue that gimp's target users are those who are attentive enough to read the questions presented to them before clicking on a button, and also know that JPEG is a lossy format. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ 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, Nov 19, 2012 at 3:11 PM, Karl Günter Wünsch wrote: but this is thought too short. Assuming that people know about the lossy behaviour of jpeg is just wrong. Then by all means educate them + previously created XCF via export - having the program prompt me to save to the original name resulted in overwritten valuable XCF with rubbish ones which only ever should exist in exported format! means that we should educate you :) Alexandre Prokoudine http://libregraphicsworld.org ___ 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, Nov 19, 2012 at 3:17 PM, Karl Günter Wünsch wrote: On 19/11/12 11:50, Alexandre Prokoudine wrote: http://gui.gimp.org/index.php/Vision_briefing, and another group of people carefully ignores these links. I'm citing from the above: GIMP is user-configurable to automate repetitive tasks; - why then is it ignored when numerous people ask for a way make the export behave and be automatied in a way that the tools get out of the way of getting things done and allow for accelerating the workflow for those who get to know them? Because you understand this sentence arbitrarily while looking for offences. Automating repetitive tasks refers to scripting and future macros recording. Alexandre Prokoudine http://libregraphicsworld.org ___ 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
Hi Alexandre, leaving aside the other points, on which I'm sure we will never agree :-), can you help me with this instead: On 11/19/2012 01:07 PM, Alberto Mardegan wrote: 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 :) 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? If yes, how? Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ 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, 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. Secondary workflow = overwriting original files. 2.6 made it easier, but it's not the primary workflow, and there are well-known workarounds. 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 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? Alexandre Prokoudine http://libregraphicsworld.org ___ 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, 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. Alexandre Prokoudine http://libregraphicsworld.org ___ 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 19 November 2012 11:50, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Mon, Nov 19, 2012 at 2:45 PM, Alberto Mardegan wrote: 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 :) In fairness, that also applies to the prompt that now reminds the user of exported-but-not-saved images. A difference is perhaps that closing an image/application (which is when this prompt is shown) is expected to be potentially destructive (where as saving is not), so the prompt gets more attention. -- Jon Nordby - www.jonnor.com ___ 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 19 November 2012 12:11, Karl Günter Wünsch k...@mineralien-verkauf.dewrote: Worse still, since most of the time I am opening and preparing a preview image out of a previously created XCF via export - having the program prompt me to save to the original name resulted in overwritten valuable XCF with rubbish ones which only ever should exist in exported format! So basically because of your idiot proof mode prompted me to lose my time consuming work because it was overwritten with an inferior version from which I can not recover! This is a real issue. It is caused mainly by GIMP not having a good way of creating/exporting multiple views of a document. It is further exacerbated by us not storing undo/redo history in the document. Both these are things to fix on the path to less/non-destructive workflows. -- Jon Nordby - www.jonnor.com ___ 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, 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? One a more personal note, it's all right to exercise the freedom of speech, but do you think you could use a personal blog instead? Alexandre Prokoudine http://libregraphicsworld.org ___ 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, Nov 19, 2012 at 3:37 PM, Jon Nordby wrote: You seem to be under impression that people actually read text in prompts :) In fairness, that also applies to the prompt that now reminds the user of exported-but-not-saved images. True :) If you can think of cleaner way to notify the user about images that were only exported, speak up :) Alexandre Prokoudine http://libregraphicsworld.org ___ 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 19/11/12 12:45, Alexandre Prokoudine wrote: I think I already understand that you dismiss existence of other experienced users who like the change. I don't dismiss their existence, there are workflows that this change fits perfectly in, but you dismiss that there are users - very experienced users I might add - whose workflows at times conflicts with the change. Do you really need to remind about that over and over again? You on the other hand do seem to require a reminder that you are dismissing the existence of experienced users who don't like the change at all! It's not as if this topic comes up every now and then because everybody and his dog is happy! It's not as if you should completely revert the behavior, just adding a simple tiny option to make the export suffice in not triggering the not saved warning would make the whole issue disappear. It's so annoying that you spend more time trying to dispute away the issue or even personally attack the people who bring up the issue rather than take a dispassionate look at the issue as something that can be resolved easily, just by allowing for a small option to be added... -- regards Karl Günter Wünsch ___ 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, Nov 19, 2012 at 4:09 PM, Karl Günter Wünsch wrote: On 19/11/12 12:45, Alexandre Prokoudine wrote: I think I already understand that you dismiss existence of other experienced users who like the change. I don't dismiss their existence Then please stop generalizing. You on the other hand do seem to require a reminder that you are dismissing the existence of experienced users who don't like the change at all! We know. We said so. The only effect you are likely to achieve is that we get tired and stop replying. It's so annoying that you spend more time trying to dispute away Then stop giving us the reason for the dispute. Switch to 2.6. Use no-xcf fork. Start your own fork. Do something constructive. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Stop this thread! (was: Save/export, option to go back to old behaviour)
Von: Jeff Maples grapn...@gmail.com It's not communistic, or totalitarian... Oh, btw, something in regard to all these the devs are foo/bar/baz- messages: Accusing the GIMP developers of being anything will only achieve the following: - increase their popcorn consumption - make future LGMs much more enjoyable (do you remember that mail thread? *smirk* *snort*) - cause them to spontaneously hug you and sprinkle you with fairy dust, should they ever meet you in person Regards, Michael ___ 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
Hi Alexandre. It looks to me you're one of the still most motivated developers to defend and explain the changes the developers made to Gimp 2.8, while Michael Natterer asked the debate to be over.. My deep respect for that. Far from me to throw gas where one needs water but I also feel, like you and other Gimp developers, probably, this discussion is likely to never end. I'd just like to add my 2¢ again -- I haven't followed the whole discussion nor all the previous threads that relate to the topic, I'm sorry. However I have noticed what I think are a few inconsistencies that I would like to share. First an example, fictional and stupid. Yet a plausible example. -- Story 1 -- User: Gimp 2.6. I've saved my image as a JPG file. How do I recover my layers? Alexandre: It's impossible. You should save in XCF to save your layers along. User: Ah? Didn't know that. Thanks. Morality: - the project lost its layers - but the user learnt one of the differences between XCF and JPG -- Story 2 -- User picks an image on the net, does changes. Wants to save, presses Ctrl+S then sends the XCF file to his friend. Friend: I can't open your file! Can't you simply send me a JPG? User: Uh...? Sure, I will send you a JPG. ** Tries to find how to save as JPG *** Variant 1: figures the export menu on his own. (Eventually ranting.) Variant 2: asks another friend or Gimp forums or Gimp users list. Gets the answer: the Export menu. User: Exports as JPG, deletes the XCF (useless anyway). ** Later ** User A: Gimp 2.8. I've saved my image as a JPG file. How do I recover my layers? Alexandre: It's impossible. You should save in XCF to save your layers along. User: Ah? Didn't know that. Thanks. Morality: - one project lost its layers - but the user learnt one of the differences between XCF and JPG My deductions: - Did the new Save workflows help? No. - Does the new Save menu workflow help learning the differences between XCF and JPG? No. - Did Gimp behave as expected? Yes. - Did the developers put every effort in making Gimp a lossless imaging application? Yes. - Did the user miss anything? Yes. - Did the developers miss anything? Yes. You *will* run into such a life use-case. Will probably take time but you will. If you want your users to make the difference between destructive and non-destructive file formats, why not just teach them directly so? Changing the UI won't for sure and it's not the prime requirement (the UI serves driving the softare, not teaching purposes). What changing the UI will do is raise questions, not necessarily the most appropriate ones. Now. Gimp is said to be a high-end [imaging] application. On the other hand there are people who don't read messages when prompted. But [the developers of] a high-end application need to make at least a few assumptions. If one of these assumptions is «users have to understand the differences between destructive [JPG] and non-destructive [XCF]» then it is acceptable to me and to other people who have posted here, correct me if I'm wrong, guys. I'm not saying Photoshop is right or wrong. It's just a different approach, similar to what Gimp 2.6 did. In PS there is «Save» and «Save As...» and also an Export function. Optionally there is a «Save for the web» option. There are hence less «Save» paths. If you open a layer-less file, make changes but don't add a layer and then save the file, it's saved keeping the initial format, destroying quality even more, as expected. If you make changes and add one or more layers and save, PS suggests to save as a PSD. In both cases the internal structure is PS native. And Photoshop is also a high-end application used by many professionals. But you know that. As a Gimp user, from what I have read so far, I have the impression you guys (developers) have wanted to conciliate two opposite goals: professional (high-end) imaging application and ready-for-everyone (or *any*one). It's only an impression so I could be wrong. But there's at least two facts: 1 - there are too many paths to save an image to the user's perspective 2 - the new file save menu workflow won't help people understand the implications between file formats. If the reason was «people need to make the difference between destructive and non-destructive» then explaining that difference is always possible without a change in the UI: just *tell* them. Now if people don't read the prompts... -- Story 3 -- Dummy: but I wasn't told my cat would die if I put him in the microwave oven! Whirlpool: make manuals and disclaimers! ** Later ** Dummy: but I wasn't told my cat would die if I put him in the microwave oven! Whirlpool: didn't you read the manuals and disclaimers? Dummy: what the...? Ma...? Whirlpool: make ovens smaller. (repeat with decreasing in size: chiuahua, guinea pig, mouse...) ** Later ** Cook: how come can't I put a cake in my microwave oven? It's too small and there's no bigger device! Whirlpool: ...
Re: [Gimp-developer] Save/export, option to go back to old behaviour
Alberto Mardegan (ma...@users.sourceforge.net) wrote: 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. Or do you have reports when this did not occur for some reasons? * User creates a multi-layered image * User saves to JPG, gets prompted for flattening * User either does not understand about layers or flattening or does understand it, but really just wants the JPEG file for sharing. * JPEG file gets saved * Gimp 2.6 marks the image as saved. --- critical! * User quits Gimp, no prompt for unsaved images Layer information lost. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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] Feedback and personal comments about Gimp 2.8
--- En date de : Lun 19.11.12, Vincent Cadet v_ca...@yahoo.fr a écrit : I'll wipe out my current profile and check again to make sure. I can confirm: Gimp 2.8 defaults to assigning the airbrush to the stylus *and* eraser until I change it. Either tip of the pen remain with the assigned brush until I close Gimp. I have checked with the default Gimp 2.8 profile, as I suspected I had done it initially. Here's what I did: 1. run: find ~/.gimp-2.8 -delete (it's been backed up beforehand ;-) 2. run: Gimp 2.8 3. enable Bamboo Fun (pad, pen, eraser) and Cintiq (pad, pen, eraser) devices, mode screen 4. use the pen: notice airbrush selected 5. flip the stylus to use the eraser: notice airbrush selected 6. select the eraser tool 7. flip back to the pen: notice airbrush selected 8. flip again to the eraser: notice eraser selected. Repeat 4. - 8. for the other tablet. Takes longer to write than do but that's it :D . Cheers, Vince C. ___ 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
I know I shouldn't comment on this thread, but I think everyone is missing an important point. If you simply open a jpeg, and then save it as a jpeg without modification, you will lose data. Jpeg is always lossy. More compression artifacts will be introduced in the saved image. There is no sane way to avoid this behavior. If you allow the user to save back to jpeg, then you will not honour the quality/file size trade-off because the user will be slowly destroying their image every time they save and re-open. We're not saying that you can't slowly destroy your image - you still have the freedom to do that. We just want you to click a single button that says, yes, I want to destroy my image, if you really do like destroying images. I don't think that's too much for us to ask of the user. I don't think that clicking a single button is something to get worked up about. I'm going to stop reading this thread now, so don't bother to reply to me. -- drawoc On Sun, Nov 18, 2012 at 11:29 PM, Graeme Gill grae...@argyllcms.com wrote: Simon Budig wrote: We cannot just make the assumption that oh, its a JPEG. *clearly* the user wants us to discard information on saving. You really think they want you to save a lot of invented bits and blow their file up in size with all that false data ? They want you to save the same visible information, without any obvious further degradation. That's easily achieved by saving in a lossless format, but not very clever, and doesn't honour the quality/file size trade-off they've already agreed to and want, since they are saving back to the lossy file format they opened. Graeme Gill. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ 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
drawoc wrote: If you simply open a jpeg, and then save it as a jpeg without modification, you will lose data. Jpeg is always lossy. More compression artifacts will be introduced in the saved image. There is no sane way to avoid this behavior. Technically that's true (but see below), but have you actually seen this ? Given a certain moderate compression ratio, how many open/slight edit/save cycles does it take before you can visually notice that the quality is worse than what you started with ? 2 ? 5 ? 10 ? If you allow the user to save back to jpeg, then you will not honour the quality/file size trade-off because the user will be slowly destroying their image every time they save and re-open. It turns out that (typically) open/save of a jpeg does not cause a steady decrease in quality, instead it asymptotes to a steady state. That's because once DCT coefficients have been quantised, they tend to get re-quantised to the same values. There is no question that a lossily compressed format is not what you want to use to create original artwork or do high quality editing or re-purposing, but I think I can be confident that the vast majority of image use is casual and non critical and in the jpeg format - all those billions of digital photo's taken every day by ordinary people. We're not saying that you can't slowly destroy your image - you still have the freedom to do that. We just want you to click a single button that says, yes, I want to destroy my image, if you really do like destroying images. But you're saving to a lossy compressed file format - by doing that you have made that choice. Having a nag telling you all the time that you do realise that jpeg is lossy, don't you? seems fairly pointless. Graeme Gill. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Gimp choking on python invocation
Hello,
Newcomer on this list but old time python coder with a Gimp itch
someone might have an idea how to scratch.
Task seem simple enough: make Gimp do some back-flips from afar
through snaky incantations ... This imply combining 2 libs: gimpfu and xmlrpc.
Well, after a sleepless night trying to solve this query, I am almost
ready to give up.
so I feel ready to get enlightened. I'm most probably doing something
stupid someplace,
but I need another pair of eyeballs to put me on the right track to
see my error.
My simple test-case below, followed by some simple test output I get.
I'm on ubuntu, my gimp is 2.6.8, python version is ... whatever is
embedded there
---
#! /usr/bin/env python
from gimpfu import *
# xmlrpc
from SimpleXMLRPCServer import SimpleXMLRPCServer
from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler
# Restrict to a particular path.
class RequestHandler(SimpleXMLRPCRequestHandler):
print 'TRACE RequestHandler()'
rpc_paths = ('/RPC2',)
# Create server
server = SimpleXMLRPCServer((localhost, 8000), allow_none=True)
def echo(*args):
print echo:, args
server.register_function(echo, 'myecho')
def farmsg(msg):
return 'farmsg is: %s' % msg
server.register_function(farmsg)
def pixh(*args):
print args:, args
src_path = args[0]
print 'pixh src%s' % (src_path)
img = pdb.file_jpeg_load(src_path, 1)
pdb.gimp_image_undo_disable(img)
h = img.height
print 'pixh result%d' % (h)
return 'pixh result%d' % (h)
server.register_function(pixh)
register(
clientecho, , , , , ,
Toolbox/Xtns/Languages/Python-Fu/Test/_Console Echo, ,
[
(PF_STRING, arg0, argument 0, /tmp/t/default.jpg),
(PF_INT,arg1, argument 1, 100 ),
(PF_FLOAT, arg2, argument 2, 1.2 ),
(PF_COLOR, arg3, argument 3, (0, 0, 0)),
],
[],
# echo
pixh
)
print 'TRACE entering main()'
main()
print 'TRACE entering serve_forever()'
server.serve_forever()
--
Some output I'm getting (or lack of)
STARTING SERVER WITH:
gimp --no-interface --batch '(python-fu-clientecho RUN-NONINTERACTIVE
/tmp/t/rihanna.jpg)'
TALKING TO SERVER WITH (xmlrpc server seem to work Ok, it's the Gimp
which fails below):
import xmlrpclib
s = xmlrpclib.ServerProxy('http://localhost:8000')
TRACE RequestHandler()
TRACE entering main()
TRACE entering serve_forever()
s.myecho('s')
$ echo: ('s',)
s.farmsg('homr')
'farmsg is: homr'
s.pixh('/tmp/t/rihanna.jpg')
pixh src/tmp/t/rihanna.jpg
... then nothing
My understanding is that Gimp chokes on this code for some unknown reason.
Perhaps I am not invoking it correctly?
Killing a Gimp child gaves some error message:
GIMP-Error: Opening '/dd/d/devel.../MY/(gimp-quit 1)' failed: No such
file or directory
So I removed the '(gimp-quit 1)' startup invocation...
That error dissapeared, but so did Gimp's conversational skills...
I know what you're saying: by now I should just start learning Scheme
and use extrans/gimpclient.py
to send Scheme instructions to the embedded Gimp-server. But my question is:
why can't I invoke gimp-python remotely as the scheme crowd can?
Where am I putting my foot in my mouth in this code?
I know others have solved this puzzle, as I see a few web-apps using
gimp as their graphics workhorse.
But can it be solved in python alone (no scheme)?
PS. if this has been answered before elsewhere, a link to that post
would be most appreciated.
But I've googled this topic non-stop for over 24 hours straight now,
with no luck. Not expecting miracles.
Anyway, any suggestion very welcome ;)
Cheers!
zaz
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Exported-but-not-saved prompt (was: Save/export, option to go back to old behaviour)
Am 19.11.2012 12:48, schrieb Alexandre Prokoudine: True :) If you can think of cleaner way to notify the user about images that were only exported, speak up :) Hello, I really tried to stay out of this thread until now, but this is a subtopic I'm quite interested in. I'd recommend a two-step approach: 1. Introduce an export-icon in the file-menu. This will help newcomers to easily find the export-option since options without icons are often dismissed as unimportant or seldom-used. One might argue that it just adds visual clutter, but to be honest: that war has been lost long ago, at least in that particular menu. Looking at other applications (openOffice, inkscape) the blank sheet (New ...) with an arrow to the right might be a good choice for this. 2. When closing, reuse the save- and export-icons paired with checkmark and cross to indicate whether a image has been saved and/or exported (naturally, save will always say no, but it's good to show it anyway so that the user will understand why the prompt pops up). If possible, one could even add the dates of the last save and export so that the user can compare these. People might not read the text in prompts, but it's pretty hard not to see a huge, iconic image right in front of you. In case this should not be formulated clearly, here is a very quick, very dirty sketch of the concept: http://tobl.deviantart.com/art/exported-but-not-saved-prompt-338649284 Personally, I've never really understood why GIMP doesn't use more graphical elements in its UI (yes, I know, GIMP already uses quite a bit, but given that it's a program for photo-manipulation, we can assume that most of it's users are inclined towards visual information as opposed to textual). They seem to be quite busy at the moment, but it'd sure be nice to hear about this from someone on the UI-team. Also, I unfortunately am not enough of a programmer to implement this myself. However, should you decide to implement it, I would, of course, be willing to provide the assets. bw, Tobias Lunte//Tobl ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp choking on python invocation
On 19 November 2012 22:54, Vio zaza...@gmail.com wrote: snip print 'TRACE entering serve_forever()' server.serve_forever() This script will not return control back to GIMP, so the application probably cannot continue past the loading of this script. You will need to do this in an async fashion. You can try to register a glib timeout/idle handler, though I am not sure if it will work. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Exported-but-not-saved prompt (was: Save/export, option to go back to old behaviour)
Tobias Lunte (tobias.lu...@hfg-gmuend.de) wrote: Personally, I've never really understood why GIMP doesn't use more graphical elements in its UI (yes, I know, GIMP already uses quite a bit, but given that it's a program for photo-manipulation, we can assume that most of it's users are inclined towards visual information as opposed to textual). In fact *because* we're dealing with lots of graphical elements we have to avoid distracting from the image the artist is working on. We had requests for a grayscale icon theme in the past, I wouldn't be surprised if too much icon clutter would impact the usability badly. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp choking on python invocation
On 11/19/2012 10:54 PM, Vio wrote:
Hello,
Newcomer on this list but old time python coder with a Gimp itch
someone might have an idea how to scratch.
Task seem simple enough: make Gimp do some back-flips from afar
through snaky incantations ... This imply combining 2 libs: gimpfu and xmlrpc.
Well, after a sleepless night trying to solve this query, I am almost
ready to give up.
so I feel ready to get enlightened. I'm most probably doing something
stupid someplace,
but I need another pair of eyeballs to put me on the right track to
see my error.
My simple test-case below, followed by some simple test output I get.
I'm on ubuntu, my gimp is 2.6.8, python version is ... whatever is
embedded there
---
#! /usr/bin/env python
from gimpfu import *
# xmlrpc
from SimpleXMLRPCServer import SimpleXMLRPCServer
from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler
# Restrict to a particular path.
class RequestHandler(SimpleXMLRPCRequestHandler):
print 'TRACE RequestHandler()'
rpc_paths = ('/RPC2',)
# Create server
server = SimpleXMLRPCServer((localhost, 8000), allow_none=True)
def echo(*args):
print echo:, args
server.register_function(echo, 'myecho')
def farmsg(msg):
return 'farmsg is: %s' % msg
server.register_function(farmsg)
def pixh(*args):
print args:, args
src_path = args[0]
print 'pixh src%s' % (src_path)
img = pdb.file_jpeg_load(src_path, 1)
pdb.gimp_image_undo_disable(img)
h = img.height
print 'pixh result%d' % (h)
return 'pixh result%d' % (h)
server.register_function(pixh)
register(
clientecho, , , , , ,
Toolbox/Xtns/Languages/Python-Fu/Test/_Console Echo, ,
[
(PF_STRING, arg0, argument 0, /tmp/t/default.jpg),
(PF_INT,arg1, argument 1, 100 ),
(PF_FLOAT, arg2, argument 2, 1.2 ),
(PF_COLOR, arg3, argument 3, (0, 0, 0)),
],
[],
# echo
pixh
)
print 'TRACE entering main()'
main()
print 'TRACE entering serve_forever()'
server.serve_forever()
--
Some output I'm getting (or lack of)
STARTING SERVER WITH:
gimp --no-interface --batch '(python-fu-clientecho RUN-NONINTERACTIVE
/tmp/t/rihanna.jpg)'
TALKING TO SERVER WITH (xmlrpc server seem to work Ok, it's the Gimp
which fails below):
import xmlrpclib
s = xmlrpclib.ServerProxy('http://localhost:8000')
TRACE RequestHandler()
TRACE entering main()
TRACE entering serve_forever()
s.myecho('s')
$ echo: ('s',)
s.farmsg('homr')
'farmsg is: homr'
s.pixh('/tmp/t/rihanna.jpg')
pixh src/tmp/t/rihanna.jpg
... then nothing
My understanding is that Gimp chokes on this code for some unknown reason.
Perhaps I am not invoking it correctly?
Killing a Gimp child gaves some error message:
GIMP-Error: Opening '/dd/d/devel.../MY/(gimp-quit 1)' failed: No such
file or directory
So I removed the '(gimp-quit 1)' startup invocation...
That error dissapeared, but so did Gimp's conversational skills...
I know what you're saying: by now I should just start learning Scheme
and use extrans/gimpclient.py
to send Scheme instructions to the embedded Gimp-server. But my question is:
why can't I invoke gimp-python remotely as the scheme crowd can?
Where am I putting my foot in my mouth in this code?
I know others have solved this puzzle, as I see a few web-apps using
gimp as their graphics workhorse.
But can it be solved in python alone (no scheme)?
PS. if this has been answered before elsewhere, a link to that post
would be most appreciated.
But I've googled this topic non-stop for over 24 hours straight now,
with no luck. Not expecting miracles.
Anyway, any suggestion very welcome ;)
Cheers!
zaz
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
To expand on Jon's answer, I believe that what you want to do is doable,
but a bit differently. You have to start Gimp as if running in batch
mode, specifying a Python script to initiate. This script (that doesn't
need to register, and shouldn't do so) should then be able to run your
processing loop.
___
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
Em 19-11-2012 19:46, Graeme Gill escreveu: drawoc wrote: If you simply open a jpeg, and then save it as a jpeg without modification, you will lose data. Jpeg is always lossy. More compression artifacts will be introduced in the saved image. There is no sane way to avoid this behavior. Technically that's true (but see below), but have you actually seen this ? Given a certain moderate compression ratio, how many open/slight edit/save cycles does it take before you can visually notice that the quality is worse than what you started with ? 2 ? 5 ? 10 ? If you allow the user to save back to jpeg, then you will not honour the quality/file size trade-off because the user will be slowly destroying their image every time they save and re-open. It turns out that (typically) open/save of a jpeg does not cause a steady decrease in quality, instead it asymptotes to a steady state. That's because once DCT coefficients have been quantised, they tend to get re-quantised to the same values. There is no question that a lossily compressed format is not what you want to use to create original artwork or do high quality editing or re-purposing, but I think I can be confident that the vast majority of image use is casual and non critical and in the jpeg format - all those billions of digital photo's taken every day by ordinary people. We're not saying that you can't slowly destroy your image - you still have the freedom to do that. We just want you to click a single button that says, yes, I want to destroy my image, if you really do like destroying images. But you're saving to a lossy compressed file format - by doing that you have made that choice. Having a nag telling you all the time that you do realise that jpeg is lossy, don't you? seems fairly pointless. Graeme Gill. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list Well, I have a couple of opinions of my own for why I liked the new workflow. Supose you are using Blender. Blender is a 3d modeller. 3d files aren't image files, so the default save is for a 3d Blender file. While you have a lot of ways for exporting it - you can render and export an image, or even export to a 3d file format different than the native Blender one. Basically, this is the same for Gimp - XCF files are not regular image files, they're Gimp files. So, like in Blender, you save the program's data on a program's file, while the export generates files that are for viewing or interchanging. If you create a Blender file, export an image and try to close it, you will receive an alert message (ok, /bad/ example. Blender by default /don't/ ever asks if you really want to close the program before saving. But that feature is already implemented for windows and there's progress to another platforms too. I think that not asking is really really bad... the default behavior *should* be asking, even with the auto-save I think. You got the point, I guess :P). So I was already familiarized with this way of doing things when the change came. I guess Inkscape have this same behavior (and would be a very better example, because it do ask before closing :P). Also, I nearly always save a file that I edited, even if it's for small changes. I usually keep the .xcf and the export image in the same folder. It's like a posture, an attitude. I don't rely on myself on doing things right every time, because I am a human being. So I prefer to choose the caution way, and I think this is the most secure workflow. Of course, not everyone have to work the way I do, or plan things the same way I do... But if a software would have to choose for the default way of action, it should be the way with more caution. So, for advanced users, why wouldn't it be possible to just making Gimp stop asking if you want to save an exported image? Well, if you think about the /Blender/ and /Inkscape/ case, the answer would be obvious - if you exported an image, you didn't saved the blender/svg/xcf file. So having that option native in the software would be a conceptual mistake by the developers. It cannot be there while Gimp makes that file differentiation. So, if the message box is **really** getting in the way of your workflow, you can uncheck the /Confirm closing of unsaved images/ box in the Environment preferences. When you change to an important .xcf file, you check it back again. It's a little confusing I guess, but at least it would let you export files without being annoyed - I am suposing that you and the users that like the 2.6 behavior do a lot of quick edits instead of spending reasonable amounts of time editing the images. I might be wrong. 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
Re: [Gimp-developer] Feedback and personal comments about Gimp 2.8
Hi, On Tue, Nov 20, 2012 at 3:05 AM, Vincent Cadet v_ca...@yahoo.fr wrote: --- En date de : Lun 19.11.12, Vincent Cadet v_ca...@yahoo.fr a écrit : I'll wipe out my current profile and check again to make sure. I can confirm: Gimp 2.8 defaults to assigning the airbrush to the stylus *and* eraser until I change it. Either tip of the pen remain with the assigned brush until I close Gimp. I have checked with the default Gimp 2.8 profile, as I suspected I had done it initially. Here's what I did: 1. run: find ~/.gimp-2.8 -delete (it's been backed up beforehand ;-) 2. run: Gimp 2.8 3. enable Bamboo Fun (pad, pen, eraser) and Cintiq (pad, pen, eraser) devices, mode screen 4. use the pen: notice airbrush selected 5. flip the stylus to use the eraser: notice airbrush selected 6. select the eraser tool From what I recall, I also had this behavior (did not try to reproduce just now, but I remember at the time it took a while to actually realize I could select a different tool for the eraser tip). That would indeed be much more friendlier to have the eraser selected by default. 7. flip back to the pen: notice airbrush selected 8. flip again to the eraser: notice eraser selected. Repeat 4. - 8. for the other tablet. Takes longer to write than do but that's it :D . Well I'd propose you copy that down in a bug report on our bugzilla and post the ticket ID on this thread after. :-) Jehan Cheers, Vince C. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Exported-but-not-saved prompt (was: Save/export, option to go back to old behaviour)
On Tue, Nov 20, 2012 at 12:13:35AM +0100, Simon Budig wrote: Tobias Lunte (tobias.lu...@hfg-gmuend.de) wrote: In fact *because* we're dealing with lots of graphical elements we have to avoid distracting from the image the artist is working on. We had requests for a grayscale icon theme in the past, I wouldn't be surprised if too much icon clutter would impact the usability badly. Yes, definitely. This is important. -- Matthew Miller mat...@mattdm.org http://mattdm.org/ ___ 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 23:07:35 -0200, wanderer wrote: Well, I have a couple of opinions of my own for why I liked the new workflow. ... I guess Inkscape have this same behavior (and would be a very better example, because it do ask before closing :P). Also, I nearly always save a file that I edited, even if it's for small changes. I usually keep the .xcf and the export image in the same folder. It's like a posture, an attitude. I don't rely on myself on doing things right every time, because I am a human being. So I prefer to choose the caution way, and I think this is the most secure workflow. There's nothing wrong with that. It's a perfectly good workflow. It's just not the one I (and apparently many other people) always want to use. My own safety mechanism is to simply never edit originals. I always export a copy out of kphotoalbum before editing it in any way (even EXIF rotating it). In fact, I keep files within my image tree read only, so the OS protects me. That, in fact, is one reason I like kphotoalbum: it does not, under any circumstances, modify the file under management in any way. And with big projects (like panoramas or other images I care about), I almost always edit .xcf files. But for smaller things, or throwaways that I'm just going to email someone or stuff on a web site, it simply isn't worth the bother. I know full well that editing a JPEG file is the Wrong Thing To Do, but again, the loss of quality simply doesn't matter in that case. Says me, and I'm the one doing it, so I'm right by definition :-) If someone then wants to take that JPEG, jack up the contrast something ridiculous, and observe artifacts, tough on them. Of course, not everyone have to work the way I do, or plan things the same way I do... But if a software would have to choose for the default way of action, it should be the way with more caution. I have no problem with that as a *default*. The problem is having no way to turn it off. So, for advanced users, why wouldn't it be possible to just making Gimp stop asking if you want to save an exported image? Well, if you think about the /Blender/ and /Inkscape/ case, the answer would be obvious - if you exported an image, you didn't saved the blender/svg/xcf file. So having that option native in the software would be a conceptual mistake by the developers. It cannot be there while Gimp makes that file differentiation. And here's where we part company. Software, like any tool, is used by people, and putting architectural purity above usability is missing the point. So, if the message box is **really** getting in the way of your workflow, you can uncheck the /Confirm closing of unsaved images/ box in the Environment preferences. When you change to an important .xcf file, you check it back again. It's a little confusing I guess, but at least it would let you export files without being annoyed - I am suposing that you and the users that like the 2.6 behavior do a lot of quick edits instead of spending reasonable amounts of time editing the images. I might be wrong. EEEK Earlier today, I posted a comment about alarm fatigue. This is a serious problem in hospitals, where there are so many alarms that are set to such a high sensitivity that medical staff often shut them off when they know that there isn't really a problem. Unfortunately, it leads to a good number of patient deaths: http://www.imsbundle.com/Blog/index.php/03/alarm-fatigue-blamed-in-hospital-deaths/wireless-communications What you're proposing here is exactly that -- disable a useful alarm and rely on the user to then re-enable it when it matters. One thing is, though, it's very easy to forget to re-enable it. If you decide that it's too dangerous to shut off confirmation of closing unsaved images -- and that's a pretty dangerous thing to do -- you open yourself up to another data loss situation. If your workflow is to edit JPEG files and re-export them, you'll get a warning message when you don't save to an XCF file. The problem is that it doesn't tell you whether you've actually exported to the JPEG file or not. If you thought you did, and you didn't, then again you've just lost your work. And there's another danger scenario, if you do things the way the GIMP developers intend, and always save to an XCF file. Suppose you forget to export back to the JPEG file (overwriting the previous version). I don't think GIMP warns you that you haven't exported it; there's no reason that it should, since you may well not want to export the file until you've done editing it. Now, let's suppose the edit that you did is to crop something out that you really, really didn't want to be in there (like your credit card, with the number visible), and you post that to the net. Oops... My point here is that a feature that was devised with the good intention of preventing data loss has multiple scenarios where the feature itself, in conjunction with common working habits,
