Re: [Gimp-gui] Scrolling past the canvas
Am Mittwoch, 23. Oktober 2019, 09:40:43 CEST schrieb Jehan: > Hi! [...] > > What has always bugged me in GIMP (at least on Windows, don't know > > about Linux) is that you can only scroll the image window as far as > > the canvas goes. This is an issue, because some tools require us to > > click outside canvas, e.g. to paint with the edge of the Brush on the > > very edge of the canvas, or to make selections more easily. A > > workaround is to zoom out and zoom in, but it's rather annoying to do > > it that way and not always feasible. > > There is an other way to scroll out of canvas: with the middle-click > panning. I.e. you hold middle-click button on the canvas and move the > mouse. Such panning is not locked within the canvas limit and is very > often the favorite way of most people to move over the canvas. That however doesn't work for people that use middle button + mouse movement to emulate scroll wheel, which is quite standard for ThinkPad users. [...] > Jehan > > > Thank you, > > Adam Tobias signature.asc Description: This is a digitally signed message part. ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: [Gimp-gui] [Gimp-developer] Using GIMP in the textile industry
Am Dienstag, 4. Juni 2019, 15:13:01 CEST schrieb Jehan: > On 2019-06-04 14:31, Tobias Ellinghaus wrote: > > Am Dienstag, 28. Mai 2019, 13:30:08 CEST schrieb Simon Budig: > > > > [...] > > > >> One thing which came up though (and which we already have discussed in > >> the past IIRC) is the need for a better support for multiple documents > >> in single window mode. The software they're using currently is using a > >> classic Windows Multiple Documents Interface (MDI) and they do in fact > >> make use of it. I tried to explain why I personally consider GIMPs > >> multiple window interface as quite good, but the not-so-great support > >> for multiple desktops in windows (and the bad window management) made > >> this a tough point to sell... :) > >> > >> I see two options here and I think we've been discussing these in the > >> past. > >> > >> a) create multiple side-by-side image views within the single window > >> > >> mode. We could allow for tiling the image area into multiple > >> notebooks, each containing its own set of images, allowing for > >> Drag'n'Drop between them etc. ppp. My gut feeling is that this > >> should be quite doable. It might be a bit tricky to control the > >> keyboard focus there and to make it clear to the user, which of > >> > >> the > >> > >> images will be affected by the next keystroke. > >> > >> b) (not necessary XOR) it might be feasible to allow for a kind of > >> > >> hybrid single/multiple window mode, where one can drag out > >> > >> notebook-tabs into their own image view that then is managed by the > >> window > >> > >> manager. So we would have one dedicated main window containing > >> > >> the > >> > >> toolbox and the notebook-area with image views as well as > >> > >> separate > >> > >> windows containing image views (or a notebook of image views?). > > > > What about this: > > > > The tabs in single image mode are not just for one image each but > > contain > > "workspaces". By default an image is opened in a new workspace > > containing a > > single image, so it's the same we currently have. It would however be > > possible > > to split the image area to show more than one image or view. I somewhat > > like > > the quick and easy way that's done in blender, however, one would need > > to > > think about what to do when the last view of an image is closed. That > > way each > > tab could contain a arbitrarily complex setup of image views with the > > toolboxen staying the same for all of them. Having rip-off windows > > might be > > nice, but I personally don't feel the need, and having both a single > > image > > window mixed with some floating windows might be confusing. > > How we handle images in single window mode is anyway a real pain to me. > Splitting a single tab to show several views of the same image or even > different images is indeed a great idea. > But also we should be able to detach image tabs (which is what you call > rip-off windows, I guess?) Yes. > into their own windows (same as we can detach > dockables even when in single window mode). I personally don't believe > this to be confusing. I mean detaching tabs is a common feature in many > software (like web browsers!), and it allows to do much more than being > limited by what the program will allow you. First of all, if you have > several screens, you can leave some images on one screen (say your > reference images) and others on another screen (the image(s) you are > working on for instance). And more usage (you are then only limited by > your window manager). Good point, I didn't think about the multiple monitor use case. > In other words, we should stop with the whole single vs multi window > mode nonsense. We should simply have a single mode allowing all > possibilities (attaching or detaching images, dockables, toolbox, etc.). Word. > This is something which have been on my TODO-list for years, and I am > never able to make the time to do this. I would support anyone wishing > to work in such directions. :-) I don't think I'll have the time needed for that. :-( > > I'm also CC'ing the gui list as that seems to be a better place for > > this part > > of the discussion. > > By the way, maybe you want to subscribe to the gui list. I had to > manually approve this email. :-) Actually I am, just with a different address it seems. :-/ > Jehan Tobias signature.asc Description: This is a digitally signed message part. ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: [Gimp-gui] [Gimp-developer] Using GIMP in the textile industry
Am Dienstag, 28. Mai 2019, 13:30:08 CEST schrieb Simon Budig: [...] > One thing which came up though (and which we already have discussed in > the past IIRC) is the need for a better support for multiple documents > in single window mode. The software they're using currently is using a > classic Windows Multiple Documents Interface (MDI) and they do in fact > make use of it. I tried to explain why I personally consider GIMPs > multiple window interface as quite good, but the not-so-great support > for multiple desktops in windows (and the bad window management) made > this a tough point to sell... :) > > I see two options here and I think we've been discussing these in the > past. > a) create multiple side-by-side image views within the single window > mode. We could allow for tiling the image area into multiple > notebooks, each containing its own set of images, allowing for > Drag'n'Drop between them etc. ppp. My gut feeling is that this > should be quite doable. It might be a bit tricky to control the > keyboard focus there and to make it clear to the user, which of the > images will be affected by the next keystroke. > > b) (not necessary XOR) it might be feasible to allow for a kind of > hybrid single/multiple window mode, where one can drag out > notebook-tabs into their own image view that then is managed by the window > manager. So we would have one dedicated main window containing the > toolbox and the notebook-area with image views as well as separate > windows containing image views (or a notebook of image views?). What about this: The tabs in single image mode are not just for one image each but contain "workspaces". By default an image is opened in a new workspace containing a single image, so it's the same we currently have. It would however be possible to split the image area to show more than one image or view. I somewhat like the quick and easy way that's done in blender, however, one would need to think about what to do when the last view of an image is closed. That way each tab could contain a arbitrarily complex setup of image views with the toolboxen staying the same for all of them. Having rip-off windows might be nice, but I personally don't feel the need, and having both a single image window mixed with some floating windows might be confusing. I'm also CC'ing the gui list as that seems to be a better place for this part of the discussion. [...] > Bye, > Simon Tobias signature.asc Description: This is a digitally signed message part. ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: [Gimp-gui] Problème tout import Sony *arw files with GIMP 2.10
Am Dienstag, 1. Mai 2018, 10:13:22 CEST schrieb jean-bernard Mangar: > Hello, > Darktable open raw files *arw, but GIMP 2.10 don't and GIMP 2.9.9 do it . > I tried to install darktable another Time, but nothing news. > Is it me or you have other message about it ? First thing to check: Do you have the darktable raw loader selected in GIMP's preferences? Version 2.10 doesn't copy over the settings from 2.9, so you might miss something there. If that didn't solve it try setting the environment variable DARKTABLE_DEBUG and try again. It should show some debug messages. > Thanks for the request. > Jean-Bernard. Tobias [...] signature.asc Description: This is a digitally signed message part. ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: [Gimp-gui] Problème tout import Sony *arw files with GIMP 2.10
Am Montag, 30. April 2018, 23:43:09 CEST schrieb jean-bernard Mangar: > Hello, > Special thanks To développ and improve GIMP. > I have a problem to import Sony raw file with GIMP 2.10, I install > darktable 2.4.3, but GIMP doesn't open raw with darktable. > Can you help me to do that. Can darktable itself open those files? And what is the file extension of them? ARW? SRF? SR2? Something else? > Thank you > Jean-Bernard Tobias signature.asc Description: This is a digitally signed message part. ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: [Gimp-gui] Possible places to save vertical space in Single (and Multiple) Window Mode
Am Freitag, 29. Dezember 2017, 16:32:49 CET schrieb Elle Stone: > Hi All, Hi! > After years of using GIMP in Multiple Window Mode, I'm thinking about > switching to Single Window Mode - the "sticking point" is not enough > vertical space in Single Window Mode. > > Here's a screenshot showing several possible places for saving vertical > space in Single Window Mode: > > https://ninedegreesbelow.com/files/possible-places-to-save-vertical-space-in > -single-window-mode.png [...] > 3. I think the extra space around the Tool Options sliders is currently > determined by the system font size. So choosing a larger font > automatically increased the "padding". I really need a largish font to > be able to read the slider text. But the extra padding means wasted > vertical space. > If the padding could be independent of the font, and possibly be > user-settable, that would be very helpful. It would also be helpful to > have the option to set the font size. It seems right now the only way to > set the font size is by modifying the user's (hidden) .gtkrc-2.0 file, > which of course affects many more programs than just GIMP. > > 4. Same as above: The opacity slider has too much vertical padding. It would be nice if sliders could be made smaller indeed. [...] > 6. This is the biggie, literally. It would be nice to have the option to > not have the image window tabs at all. But if having these tabs is a > requirement, at least make the tab height and tab icons as small as > possible. Is there a place in Preferences that controls this icon size? > It's huge! Where in the code is the tab/icon size set? This one annoys me most. When only having a single image open the tabs should probably not shown at all. Or is a single tab good for anything that is not obvious? [...] > Actually, except for "6", all these "vertical space saving > possibilities" also apply to Multiple Window Mode. Especially when using > the Paint tools, the Tool options dialog is very "tall" and every bit of > vertical space that can be saved helps avoid the dreaded scrollbar. Besides 3./4. and 6. I don't mind the extra space, it helps separate things and is less clutter than horizontal lines. > Elle Tobias signature.asc Description: This is a digitally signed message part. ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: [Gimp-gui] Suggestion about the loading window
Am Samstag, 23. September 2017, 14:04:58 CEST schrieb gregory grey: > Some stuff in https://www.gimp.org/about/splash/ is just atrocious. > Pretending you don't see that yourself is just insulting. You do realize > that "fun" and "7 years old level of aesthetics" is not the same? One of > the things I dig about Darktable is that I can show it to PS/LR users > without being laughed at. Unless it's April 1st. [...] Tobias signature.asc Description: This is a digitally signed message part. ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: [Gimp-gui] GIMPs text dialog font search box can become completely empty
Am Montag, 22. August 2016, 14:55:33 CEST schrieb Jehan: [...] > no? What I could imagine is showing the currently selected font (or some > descriptive text: "Select font" for instance) as some shadow grey text > (i.e. the "placeholder" attribute on input fields in html5), but I have > no idea if GTK+2 (or even GTK+3) can do this by default. https://developer.gnome.org/gtk3/stable/GtkEntry.html#gtk-entry-set-placeholder-text [...] signature.asc Description: This is a digitally signed message part. ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
