Re: [Gimp-developer] Isn't this behaviour unintuative?
On 28/06/2011 13:33, peter sikking wrote: On Jun 28, 2011, at 11:35, SorinN wrote: But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm. Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog, first of all, ctrl-shift-e was chosen because it works like that cross application (inkscape and co). also think about it: when working on a project (serious work = our priority in design vs. hit and run editing) then there will be in quite a few workflows a lot more ctrl-E (equivalent to ctrl-S) for reviewing, than ctrl-shift-E (equivalent to ctrl-shift-S) for anchoring to another export file(-path/-format). this is why I am insisting that it is not going to change, in the future. How about the change where we leave the ctrl-E shortcut, but automatically set it up to do something (at the moment it does nothing) when a file is imported into GIMP? My suggestion is an export (to the original file name and file type), but with a 'are you sure you want to overwrite?' dialog before the export happens, with the focus automatically on the cancel so 'enter' will cancel the export. -- Best regards, Jeremy Morton (Jez) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
2011/6/30 Jeremy Morton ad...@game-point.net: My suggestion is an export (to the original file name and file type), but with a 'are you sure you want to overwrite?' dialog before the export happens, with the focus automatically on the cancel so 'enter' will cancel the export. The popup is good when the user did in fact not want to overwrite the file, whenever the user *do* want to overwrite the file, that popup will be very annoying. Imagine a are you sure you want to save-dialog each time you press Ctrl+S. / Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
My suggestion is that this only happen the *first* time the over presses ctrl-E after importing and editing a file, though. Subsequent presses once the user has confirmed would overwrite without confirmation. It's just to avoid overwriting by accident. -- Best regards, Jeremy Morton (Jez) On 30/06/2011 11:04, Martin Nordholts wrote: 2011/6/30 Jeremy Mortonad...@game-point.net: My suggestion is an export (to the original file name and file type), but with a 'are you sure you want to overwrite?' dialog before the export happens, with the focus automatically on the cancel so 'enter' will cancel the export. The popup is good when the user did in fact not want to overwrite the file, whenever the user *do* want to overwrite the file, that popup will be very annoying. Imagine a are you sure you want to save-dialog each time you press Ctrl+S. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Thu, Jun 30, 2011 at 1:34 PM, Jeremy Morton ad...@game-point.net wrote: My suggestion is that this only happen the *first* time the over presses ctrl-E after importing and editing a file, though. Subsequent presses once the user has confirmed would overwrite without confirmation. It's just to avoid overwriting by accident. I would really hate it if Ctrl-E would overwrite after import even with confirmation. What I personally expect to happen is to have the export dialog pop up just as the save dialog does letting me CHOOSE what I want to do. At this point I can opt to overwrite, by selecting the original file or to save new file next to it. On subequent calls, the export would be silent. This is how save shortcut works. Dialog first, silent on next calls, if the file to be saved to is established. I find it extremely annoying that it does nothing and I need to reach for shift to get even the inital dialog. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
But it's more intuative to assume the imported file's location and format. If you've imported a file and edited it, it's quite likely you will want to write the changes back out to that file. If you want to write them somewhere else, it's easy to bring up the advanced export dialog. -- Best regards, Jeremy Morton (Jez) On 30/06/2011 11:53, Alexia Death wrote: On Thu, Jun 30, 2011 at 1:34 PM, Jeremy Mortonad...@game-point.net wrote: My suggestion is that this only happen the *first* time the over presses ctrl-E after importing and editing a file, though. Subsequent presses once the user has confirmed would overwrite without confirmation. It's just to avoid overwriting by accident. I would really hate it if Ctrl-E would overwrite after import even with confirmation. What I personally expect to happen is to have the export dialog pop up just as the save dialog does letting me CHOOSE what I want to do. At this point I can opt to overwrite, by selecting the original file or to save new file next to it. On subequent calls, the export would be silent. This is how save shortcut works. Dialog first, silent on next calls, if the file to be saved to is established. I find it extremely annoying that it does nothing and I need to reach for shift to get even the inital dialog. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Thu, Jun 30, 2011 at 1:56 PM, Jeremy Morton ad...@game-point.net wrote: But it's more intuative to assume the imported file's location and format. If you've imported a file and edited it, it's quite likely you will want to write the changes back out to that file. If you want to write them somewhere else, it's easy to bring up the advanced export dialog. This assumption, that the overwrite is desired, is wrong for any photographic workflow. You import your pretty 12Mpix raw or JPG photo, scale and crop and adjust and it would be a tragedy if you destroyed the original at the end. The desired behavior is to keep the type perhaps, but certainly not overwrite. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Thu, Jun 30, 2011 at 2:08 PM, Jeremy Morton ad...@game-point.net wrote: So you're assuming that the user is going to 'accidentally' press ctrl-E, then 'accidentally' click on overwrite even though it's not the default selected button? No, Im telling you that for photographic workflows, desire to overwrite is rather rare. However, users will assume export shortcut to behave analogously to save shortcut, that being, dalog on first evocation, silent save on rest. I know I do. Hence the annoyance with nothing happening. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On 30/06/2011 12:17, Alexia Death wrote: On Thu, Jun 30, 2011 at 2:08 PM, Jeremy Mortonad...@game-point.net wrote: So you're assuming that the user is going to 'accidentally' press ctrl-E, then 'accidentally' click on overwrite even though it's not the default selected button? No, Im telling you that for photographic workflows, desire to overwrite is rather rare. However, users will assume export shortcut to behave analogously to save shortcut, that being, dalog on first evocation, silent save on rest. I know I do. Hence the annoyance with nothing happening. OK, that would seem like a good fix too, as long as that dialog defaulted to the path and filename of the imported file so I could just press enter and click 'replace' to export back to the imported file. -- Best regards, Jeremy Morton (Jez) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
No, Im telling you that for photographic workflows, desire to overwrite is rather rare this is true, can be an unrecoverable mistake, even for one unique picture but sometime overwriting is convenient and desired Probably the best way is to have this choice in Preferences Also from an Usability point of view - probably for the first use of Ctrl+E in a work session - it's ok to present him in pop-up the choices he have - then the user will choose what he want also he will choose his option for the whole session. So if the user choose Overwrite without confirmation - then all that session Ctrl+E will act this way If he will choose Bring me the save window every time - then he will see all export options If user will choose Export a Copy - then for the whole session the file can be saved using incremental sufix Also as a new option probably is ok to have Save using Preset - that mean a place where user can make reusable patterns with rules for saving files. Example of a preset for a mass save scenario: 1) preserve the original anyway 2) make an incremental file with PNG extension and the same filename in the folder /home/web/X (with all compression options ..etc) 3) make an image with sdfasdfasdfasd name and JPG extension in folder /media/hdd4/Y (with compression options etc). 4) and so ... 2011/6/30 Alexia Death alexiade...@gmail.com: On Thu, Jun 30, 2011 at 2:08 PM, Jeremy Morton ad...@game-point.net wrote: So you're assuming that the user is going to 'accidentally' press ctrl-E, then 'accidentally' click on overwrite even though it's not the default selected button? No, Im telling you that for photographic workflows, desire to overwrite is rather rare. However, users will assume export shortcut to behave analogously to save shortcut, that being, dalog on first evocation, silent save on rest. I know I do. Hence the annoyance with nothing happening. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On 30/06/2011 13:30, SorinN wrote: No, Im telling you that for photographic workflows, desire to overwrite is rather rare this is true, can be an unrecoverable mistake, even for one unique picture but sometime overwriting is convenient and desired Also I would imagine any sensible user would always save a lossless version of a lossy-format image before editing it and saving. If you're directly opening a JPEG for editing and then lossy-saving it somewhere else, what are you thinking?! You're going to keep losing quality. -- Best regards, Jeremy Morton (Jez) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Thu, Jun 30, 2011 at 3:40 PM, Jeremy Morton ad...@game-point.net wrote: Also I would imagine any sensible user would always save a lossless version of a lossy-format image before editing it and saving. Why would I save it lossless somewhere BEFORE editing a file Ive imported from a JPG? The loss has already happened, I can always get the exactly same quality for this particular file from the JPG. After editing the only sane format to SAVE to is xcf. Not only is it lossless, you wont lose any of the layers/objects you have made in the process. If you're directly opening a JPEG for editing and then lossy-saving it somewhere else, what are you thinking?! You're going to keep losing quality. You dont SAVE to lossy format. You export. Save is to xcf - the only sane starting point for future editing. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
OK, well that's a terminology thing. I meant export. Why would you keep exporting it to a JPEG? I was saying what you're saying; if you're opening/importing a JPEG with the intention of editing it and exporting it, it only makes sense to save a lossless (probably XCF) before you get started. The criticism of ctrl-E writing to the original file seems to be that you'll lose the quality of the original JPEG, but if you're doing that without having first saved a lossless copy, your workflow is... probably flawed. -- Best regards, Jeremy Morton (Jez) On 30/06/2011 14:09, Alexia Death wrote: On Thu, Jun 30, 2011 at 3:40 PM, Jeremy Mortonad...@game-point.net wrote: Also I would imagine any sensible user would always save a lossless version of a lossy-format image before editing it and saving. Why would I save it lossless somewhere BEFORE editing a file Ive imported from a JPG? The loss has already happened, I can always get the exactly same quality for this particular file from the JPG. After editing the only sane format to SAVE to is xcf. Not only is it lossless, you wont lose any of the layers/objects you have made in the process. If you're directly opening a JPEG for editing and then lossy-saving it somewhere else, what are you thinking?! You're going to keep losing quality. You dont SAVE to lossy format. You export. Save is to xcf - the only sane starting point for future editing. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Thu, Jun 30, 2011 at 4:21 PM, Jeremy Morton ad...@game-point.net wrote: OK, well that's a terminology thing. I meant export. Why would you keep exporting it to a JPEG? I was saying what you're saying; if you're opening/importing a JPEG with the intention of editing it and exporting it, it only makes sense to save a lossless (probably XCF) before you get started. The criticism of ctrl-E writing to the original file seems to be that you'll lose the quality of the original JPEG, but if you're doing that without having first saved a lossless copy, your workflow is... probably flawed. It isnt. Sample workflow: Open jpg, Crop, scale, unsharp mask, export for saving to web. I have no reason to save the xcf of neither the source JPG or the resulting web file however I would be extremely distressed If the source JPG got overwritten. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
Jeremy: You have some good points, but also Alexia and the rest have. All this stuff was studied and the consensus was to go ahead with the current implementation. Of course it's hard to please everyone and this can look bad for some people while looks excellent for others. You already can have a single keystroke overwrite by assigning manually a key combination to that command, so your need is covered. Arguments against unifying export and overwrite are strong, based on preserving the integrity of original files from reckless/distracted users. Overwriting the original file with a modified version is irreversible and it's fine if the proposed workflow protects users from that, leaving the option of overriding that protection only to advanced users who have to assign voluntarily a kestroke for the overwrite command. Sounds fair to me. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
I wrote: I will update the spec now to formalise this. done, and it was not a one-liner. Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes. thanks, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] Isn't this behaviour unintuative?
2011/6/30 peter sikking pe...@mmiworks.net: I wrote: I will update the spec now to formalise this. done, and it was not a one-liner. Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes. It looks straightforward and I expect to be able to update the code for 2.8. One gripe: The spec says give secondary support to workflows where the input and output are the same non-xcf file and you just made this a bit harder (OK-ing the Export to dialog) For the record: Would you still want the new approach in the spec if Ctrl+E would previously have been an unused keyboard shortcut? BR, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
Martin wrote: 2011/6/30 peter sikking pe...@mmiworks.net: I will update the spec now to formalise this. done, and it was not a one-liner. Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes. It looks straightforward and I expect to be able to update the code for 2.8. One gripe: The spec says give secondary support to workflows where the input and output are the same non-xcf file and you just made this a bit harder (OK-ing the Export to dialog) no, nothing changed in the Overwrite workflows. today's changes can be summarised as: - in the cases where before Export to was insensitive, it is now sensitive and mapped to invoke Export... (the dialog) - in the cases where Overwrite blocks Export to out of the File menu, the shortcut of Export to is still active and mapped to invoke Export... everything else works like before For the record: Would you still want the new approach in the spec if Ctrl+E would previously have been an unused keyboard shortcut? I noticed the equivalence between the Export and Save departments a long time ago. Today's changes take that one step further. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] Isn't this behaviour unintuative?
2011/6/30 peter sikking pe...@mmiworks.net: no, nothing changed in the Overwrite workflows. today's changes can be summarised as: - in the cases where before Export to was insensitive, it is now sensitive and mapped to invoke Export... (the dialog) - in the cases where Overwrite blocks Export to out of the File menu, the shortcut of Export to is still active and mapped to invoke Export... everything else works like before Thanks for the clarifications, I've made this change now: commit c73bdc097188a926f01062a009f9f22ff32dad4e Author: Martin Nordholts mart...@src.gnome.org Date: Thu Jun 30 23:44:50 2011 +0200 app: Make 'Export to' fall back to 'Export...' Make 'Export to' always sensitive (as long as there is an image at all). And make it fall back to 'Export...' if no export target has been set yet. Note that it is not necessarily visible at all times, sometimes 'Overwrite' shadows it. It shall still be invokable though. Reference: [Gimp-developer] Isn't this behaviour unintuative? http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html @Jeremy: Does this work better? / Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
2011/6/26 Jeremy Morton ad...@game-point.net: When I open a non-GIMP format file, like a PNG, by drag-dropping it into GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and nothing happens. This is because what I actually have to do is select File | Overwrite (filename.png). Wouldn't it be more intuative to behave as if you'd just exported (filename.png), or whatever file you've just imported into GIMP, so that once you've edited it you can just press ctrl+E and easily export it back to its native format? Yes it would be more intuitive, and that was also the initial design. The reason it works the way it works today is to avoid data-loss. In GIMP 2.6, the keyboard shortcut Ctrl+E invokes the harmless View - Shrink Wrap action. In GIMP 2.8, it overwrites an original file. In other words, this sequence of events is harmless in GIMP 2.6: 1. File - Open file-I-dont-want-to-lose.jpg 2. Make some significant changes 3. Press Ctrl+E while in GIMP 2.8 the file-I-dont-want-to-lose.jpg would be lost if we made Ctrl+E invoke Overwrite by default and a user, quite reasonable, expects Ctrl+E to still be Shrink Wrap. The idea was that by forcing users to manually assign Ctrl+E to Overwrite, they would confirm that ok I know Ctrl+E will potentially destory my originals. That file-overwrite and file-export can't have the same keyboard shortcut is a bug, that is meant to work. Quite an oversight that it doesn't... Once people have learned that Ctrl+E is export and not Shrink Wrap, we can make Ctrl+E be the default keyboard shortcut for both Overwrite and Export. Until then, I just made a commit so that you can use Alt+F, W instead at least: commit 9ae0dc034b7791c15479649f71ef4cda8caaf34e Author: Martin Nordholts mart...@src.gnome.org Date: Tue Jun 28 08:53:45 2011 +0200 Make 'w' a mnemonic for File - Overwrite ... See [Gimp-developer] Isn't this behaviour unintuative? http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm. Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog, 2011/6/28 Martin Nordholts ense...@gmail.com: 2011/6/26 Jeremy Morton ad...@game-point.net: When I open a non-GIMP format file, like a PNG, by drag-dropping it into GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and nothing happens. This is because what I actually have to do is select File | Overwrite (filename.png). Wouldn't it be more intuative to behave as if you'd just exported (filename.png), or whatever file you've just imported into GIMP, so that once you've edited it you can just press ctrl+E and easily export it back to its native format? Yes it would be more intuitive, and that was also the initial design. The reason it works the way it works today is to avoid data-loss. In GIMP 2.6, the keyboard shortcut Ctrl+E invokes the harmless View - Shrink Wrap action. In GIMP 2.8, it overwrites an original file. In other words, this sequence of events is harmless in GIMP 2.6: 1. File - Open file-I-dont-want-to-lose.jpg 2. Make some significant changes 3. Press Ctrl+E while in GIMP 2.8 the file-I-dont-want-to-lose.jpg would be lost if we made Ctrl+E invoke Overwrite by default and a user, quite reasonable, expects Ctrl+E to still be Shrink Wrap. The idea was that by forcing users to manually assign Ctrl+E to Overwrite, they would confirm that ok I know Ctrl+E will potentially destory my originals. That file-overwrite and file-export can't have the same keyboard shortcut is a bug, that is meant to work. Quite an oversight that it doesn't... Once people have learned that Ctrl+E is export and not Shrink Wrap, we can make Ctrl+E be the default keyboard shortcut for both Overwrite and Export. Until then, I just made a commit so that you can use Alt+F, W instead at least: commit 9ae0dc034b7791c15479649f71ef4cda8caaf34e Author: Martin Nordholts mart...@src.gnome.org Date: Tue Jun 28 08:53:45 2011 +0200 Make 'w' a mnemonic for File - Overwrite ... See [Gimp-developer] Isn't this behaviour unintuative? http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Jun 28, 2011, at 11:35, SorinN wrote: But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm. Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog, first of all, ctrl-shift-e was chosen because it works like that cross application (inkscape and co). also think about it: when working on a project (serious work = our priority in design vs. hit and run editing) then there will be in quite a few workflows a lot more ctrl-E (equivalent to ctrl-S) for reviewing, than ctrl-shift-E (equivalent to ctrl-shift-S) for anchoring to another export file(-path/-format). this is why I am insisting that it is not going to change, in the future. since the GIMP team (and I as interaction architect particularly) have the duty not to encourage overwriting/destructing the original file by accident, there is no shortcut on overwrite by default. Users can set it by hand, it is their call on the convinience vs. danger balance. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] Isn't this behaviour unintuative?
this is why I am insisting that it is not going to change, in the future. don't get me wrong - as is right now - is very convenient for me and probably for many others, but seems to disturb a part of designers who comes with various backgrounds. to be clear ..when I see for first time that Ctrl + E just overwrite without confirmation, in the very next second in my mind come that Ctrl + Shift + E should do the job I've asked for. It was true ..and logic. Can't be other - so I can say it's quite intuitive as is. Btw. I rarely use File entry on menu bar. Now I've just discovered there text helpers (Ctrl + E and Shift + Ctrl + E) which indicate the keyboard shortcuts for mentioned functions ;) - funny. 2011/6/28 peter sikking pe...@mmiworks.net: On Jun 28, 2011, at 11:35, SorinN wrote: But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm. Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog, first of all, ctrl-shift-e was chosen because it works like that cross application (inkscape and co). also think about it: when working on a project (serious work = our priority in design vs. hit and run editing) then there will be in quite a few workflows a lot more ctrl-E (equivalent to ctrl-S) for reviewing, than ctrl-shift-E (equivalent to ctrl-shift-S) for anchoring to another export file(-path/-format). this is why I am insisting that it is not going to change, in the future. since the GIMP team (and I as interaction architect particularly) have the duty not to encourage overwriting/destructing the original file by accident, there is no shortcut on overwrite by default. Users can set it by hand, it is their call on the convinience vs. danger balance. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
Let's put it another way: I'm the user and I want GIMP to do that. How can I get it to? -- Best regards, Jeremy Morton (Jez) On 26/06/2011 14:18, Alexandre Prokoudine wrote: On Sun, Jun 26, 2011 at 4:08 PM, Jeremy Morton wrote: When I open a non-GIMP format file, like a PNG, by drag-dropping it into GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and nothing happens. This is because what I actually have to do is select File | Overwrite (filename.png). Wouldn't it be more intuative to behave as if you'd just exported (filename.png), or whatever file you've just imported into GIMP, so that once you've edited it you can just press ctrl+E and easily export it back to its native format? Intuition is unrelated. IMO the distiction between exporting and overwriting is quite clear: You can overwrite imported file or export it to save under a different name. GIMP should not try to guess whether you are editing original image or creating a new modification to be saved next to original file. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Sun, Jun 26, 2011 at 5:43 PM, Jeremy Morton wrote: Let's put it another way: I'm the user and I want GIMP to do that. How can I get it to? You can't Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
It should be possible. -- Best regards, Jeremy Morton (Jez) On 26/06/2011 14:48, Alexandre Prokoudine wrote: On Sun, Jun 26, 2011 at 5:43 PM, Jeremy Morton wrote: Let's put it another way: I'm the user and I want GIMP to do that. How can I get it to? You can't Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Sun, Jun 26, 2011 at 5:49 PM, Jeremy Morton wrote: It should be possible. You are in fact suggesting to heavily break use pattern. I don't think developers and UI team will fall for that. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
As far as I can tell the usage pattern has already changed heavily from 2.6. In 2.6 there was only one save option; now there's a save and export. You've already changed that significantly. -- Best regards, Jeremy Morton (Jez) On 26/06/2011 14:57, Alexandre Prokoudine wrote: On Sun, Jun 26, 2011 at 5:49 PM, Jeremy Morton wrote: It should be possible. You are in fact suggesting to heavily break use pattern. I don't think developers and UI team will fall for that. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Sun, Jun 26, 2011 at 6:00 PM, Jeremy Morton wrote: As far as I can tell the usage pattern has already changed heavily from 2.6. In 2.6 there was only one save option; now there's a save and export. You've already changed that significantly. Yes, and there should be a better reason for going half the way back and introducing a crossbreed of 2.6 and 2.8 than just it should be possible. I wouldn't really want to rely on arguments like it doesn't make any sense, but in truth it's exactly what I think. Overwrite says exactly what it does. You can assign a shortcut to it. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
The way I think of the workflow, I'm importing a file, editing it, and exporting it. Overwriting the file on disk is a mere side-effect of that workflow, and GIMP will prompt me in any case just in case I don't want to overwrite the file. The thing is, if I go about it a different way and export another file to overwrite that file, I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting. -- Best regards, Jeremy Morton (Jez) On 26/06/2011 15:14, Alexandre Prokoudine wrote: On Sun, Jun 26, 2011 at 6:00 PM, Jeremy Morton wrote: As far as I can tell the usage pattern has already changed heavily from 2.6. In 2.6 there was only one save option; now there's a save and export. You've already changed that significantly. Yes, and there should be a better reason for going half the way back and introducing a crossbreed of 2.6 and 2.8 than just it should be possible. I wouldn't really want to rely on arguments like it doesn't make any sense, but in truth it's exactly what I think. Overwrite says exactly what it does. You can assign a shortcut to it. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
He's right here = I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting. He doesn't know that Ctrl + Shift + E bring to you the Export Dialog where you can choose your different filename AND / OR different extension. 2011/6/26 Jeremy Morton ad...@game-point.net: The way I think of the workflow, I'm importing a file, editing it, and exporting it. Overwriting the file on disk is a mere side-effect of that workflow, and GIMP will prompt me in any case just in case I don't want to overwrite the file. The thing is, if I go about it a different way and export another file to overwrite that file, I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting. -- Best regards, Jeremy Morton (Jez) On 26/06/2011 15:14, Alexandre Prokoudine wrote: On Sun, Jun 26, 2011 at 6:00 PM, Jeremy Morton wrote: As far as I can tell the usage pattern has already changed heavily from 2.6. In 2.6 there was only one save option; now there's a save and export. You've already changed that significantly. Yes, and there should be a better reason for going half the way back and introducing a crossbreed of 2.6 and 2.8 than just it should be possible. I wouldn't really want to rely on arguments like it doesn't make any sense, but in truth it's exactly what I think. Overwrite says exactly what it does. You can assign a shortcut to it. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On 06/26/2011 09:22 AM, Jeremy Morton wrote: The thing is, if I go about it a different way and export another file to overwrite that file, I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting. Yes, it's going to take some getting used to. However, the HUGE benefit of the new Export functionality is that you will not have to repeatedly specify/confirm the settings of the file format you wish to save to. In the old version hitting Save was very general-purpose. As a result you would have to confirm two or sometimes three (Are you sure you want to overwrite that file?) dialog windows to save a file. For someone like a web developer/designer, especially working through iterations on one design project, the new approach is a big time-saver. Now if only the Save for Web dialog would remember the destination folder from save to save Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On 26/06/2011 15:31, Jason Simanek wrote: On 06/26/2011 09:22 AM, Jeremy Morton wrote: The thing is, if I go about it a different way and export another file to overwrite that file, I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting. Yes, it's going to take some getting used to. However, the HUGE benefit of the new Export functionality is that you will not have to repeatedly specify/confirm the settings of the file format you wish to save to. And I've already gotten used to that; it is logical. My issue is when you open a non-GIMP format file and then you want to export it back to its original format; I think it makes more sense to just be able to press ctrl+E (with a popup confirming that you want to overwrite) to do that, rather than having a *third* save option, which is File | Overwrite. I mean, what I am wanting to do is export the image... so ctrl+E makes sense. -- Best regards, Jeremy Morton (Jez) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Sun, Jun 26, 2011 at 6:42 PM, Jeremy Morton wrote: And I've already gotten used to that; it is logical. My issue is when you open a non-GIMP format file and then you want to export it back to its original format; I think it makes more sense to just be able to press ctrl+E (with a popup confirming that you want to overwrite) to do that, rather than having a *third* save option, which is File | Overwrite. I mean, what I am wanting to do is export the image... so ctrl+E makes sense. So you'd rather email the list than configure shortcuts? :) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
I can't configure the same shortcut for 2 things (file-overwrite and file-export), and anyway I'm making the point that I don't see a meaningful difference between the two. Once you've executed file-overwrite once, file-export does exactly what I'd want anyway. Why not make file-export just do that first time around, but prompt you with a popup just in case you didn't mean to overwrite the file? -- Best regards, Jeremy Morton (Jez) On 26/06/2011 15:59, Alexandre Prokoudine wrote: On Sun, Jun 26, 2011 at 6:42 PM, Jeremy Morton wrote: And I've already gotten used to that; it is logical. My issue is when you open a non-GIMP format file and then you want to export it back to its original format; I think it makes more sense to just be able to press ctrl+E (with a popup confirming that you want to overwrite) to do that, rather than having a *third* save option, which is File | Overwrite. I mean, what I am wanting to do is export the image... so ctrl+E makes sense. So you'd rather email the list than configure shortcuts? :) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
On Sun, Jun 26, 2011 at 7:14 PM, Jeremy Morton wrote: I can't configure the same shortcut for 2 things (file-overwrite and file-export), Oh, I finally see what you mean :) Sorry :) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
