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
[Gimp-developer] OSPD
I have a free software project intention is to distribute free (GPL or LGPL) with much documented source code and pdfs a wiki where anyone with an account on sourceforge can contribute programs are free to develop and study the site already speaks of Java j2me sockets Irrlicht etc. expect more still missing some things are indexed in Google. the project site is: http://ospd.sf.net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OSPD
I'm sorry, what does it have to do with GIMP development? On Tue, Jun 28, 2011 at 7:27 PM, Fabio Gonzalez fabiojo...@gmail.comwrote: I have a free software project intention is to distribute free (GPL or LGPL) with much documented source code and pdfs a wiki where anyone with an account on sourceforge can contribute programs are free to develop and study the site already speaks of Java j2me sockets Irrlicht etc. expect more still missing some things are indexed in Google. the project site is: http://ospd.sf.net ___ 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
