Re: [Gimp-developer] Tab in Single Window-Mode
Speaking of tab in single-window mode, does Ctrl-Tab work for switching tab yet? If not, is this planned? -- Best regards, Jeremy Morton (Jez) On 15/08/2011 18:15, Martin Nordholts wrote: 2011/8/13 Robert Hildebrandtroberts_k...@gmx.de: Hello Guys, I love using Gimp with the new SingleWindow-Mode but I've got a little issue: I like using Tab to maximize and minimize the working area, which works very fine -- except one of those widgets outside gets the focus, so using Tab just changes the Widget with Focus. I haven't found a way to change the shortcut from Tab to something different (a way to search for the used keys in the shortcut Dialog could be also nice). Hi, The 'Tab' key is a bit special because GTK+ doesn't allow 'Tab' as a keyboard shortcut, right now it's hardcoded. It can be changed though to something normal with the Keyboard Shortcuts dialog. 'Tab' must at least mean switch focus between widgets, we must not change that. So for now, I would recommend you to simply change the shortcut to something else. I doubt it would be worth to spend time adding code in special places just to get Tab for dock visibility to work. It is quite an odd choice of keyboard shortcut in the first place, and imho we should look into another default key for this. / 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 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?
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?
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 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?
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?
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
[Gimp-developer] Isn't this behaviour unintuative?
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? -- 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?
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?
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?
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?
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?
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?
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] Fwd: Re: Isn't this behaviour unintuative?
On 26/06/2011 16:23, Jason Simanek wrote: On 06/26/2011 09:31 AM, SorinN wrote: 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. I have to admit, I'm constantly getting tripped-up by that. Is there any reason that the FIRST time you hit Ctrl + E couldn't do the same thing as Ctrl + Shift + E rather than _nothing_? Or at least bring up a dialog asking the user if that is what they'd like to do? Or... export the file back to its imported location and filetype? -- 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] Fwd: Re: Isn't this behaviour unintuative?
Sure, but that's why you'd have a popup the first time you were going to overwrite. If you didn't want to save the JPEG, you'd cancel and save it somewhere else using the 'export as' dialog. -- Best regards, Jeremy Morton (Jez) On 26/06/2011 16:53, Liam R E Quin wrote: On Sun, 2011-06-26 at 16:45 +0100, Jeremy Morton wrote: Or... export the file back to its imported location and filetype? For a jpeg photograph that would of course be a disaster - jpeg saving is lossy, so you could easily damage or lose your original file beyond repair. Liam ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Modify alpha transparency of selected pixels?
On 25/06/2011 18:41, Fabio Gonzalez wrote: 2011/6/25 Jeremy Morton ad...@game-point.net mailto:ad...@game-point.net Hi all, Several times now it has occurred to me that it would be useful to be able to modify alpha transparency of pixels selected. I can already modify their colour in numerous ways (brightness/contrast, colorize, invert, etc.) so why not alpha transparency? Right now, the way you have to do it is clunky. You select the pixels, 'cut' them, paste them onto a new layer, modify that layer's transparency, and merge it down into the original layer again. Why not add some functions to increase selected pixels' opacity, reduce it, or set them to a given value (0-255)? -- Best regards, Jeremy Morton (Jez) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU mailto:Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer you can use masks on selected pixels I don't see how that lets you actually set the pixel's alpha value, though. You have to mess around with the mask getting its pixels just the right value to make the pixel's alpha value right, which is probably harder than using the cut/paste/merge method I mentioned previously. What I really want to be able to do is enter a number and set the selected pixels' alpha transparency to that number. -- 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] Modify alpha transparency of selected pixels?
Ah thanks... that works quite nicely. -- Best regards, Jeremy Morton (Jez) On 25/06/2011 18:49, Mikael Magnusson wrote: On 25 June 2011 19:13, Jeremy Mortonad...@game-point.net wrote: Hi all, Several times now it has occurred to me that it would be useful to be able to modify alpha transparency of pixels selected. I can already modify their colour in numerous ways (brightness/contrast, colorize, invert, etc.) so why not alpha transparency? Right now, the way you have to do it is clunky. You select the pixels, 'cut' them, paste them onto a new layer, modify that layer's transparency, and merge it down into the original layer again. Why not add some functions to increase selected pixels' opacity, reduce it, or set them to a given value (0-255)? Add Layer Mask - transfer alpha channel ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Scrollwheel actions by default?
Hello all, Just a small thing. I noticed that by default, scrolling up and down with the mouse scrollwheel isn't configured to do anything at all. Especially as it wouldn't even be replacing something else, I propose that the scroll-up and scroll-down actions be configured, by default, to zoom in and zoom out. I just did this manually and it works great. I don't think scrolling vertically and horizontally with the scroll wheel is as intuitive, and you can do this anyway by holding down the middle button and moving the mouse. Best regards, Jeremy Morton (Jez) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
