Re: [Gimp-developer] Improved brush editing interface mock-up
Nelson A. de Oliveira wrote: > This is something that I, as an user, would like to have. > It also seems to save some screen space when editing on a notebook > that can do only 1024x768 too :-) This is a smaller version I made which shows that at 1024x768 (and possibly at even lower resolutions) there's still much usable screen space: http://i29.tinypic.com/se3hg5.png -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] keybindings
I got back from vacation in the UK (yay no mosquitoes) and tried git head gimp today. First, a BIG thank you to Peter and others: the new menu item "overwrite" is much clearer. I do still have a problem in several gnomish scenarios, but things are indeed getting better. If I use the file manager and drag a file to gimp, or if I use the image thumbnail browser (e.g. gthumb, but others do this too) and say, "open in gimp", then gimp now imports my original jpeg file (say). And a keystroke that I use literally hundreds of times in any one day, will silently, without any warning, overwrite that file -- control-E and control-shift-E (fit window to image, fit window to image, respectively). It's not that there's a keystroke to save the file with lossy compression: control-S has always done that. It's that the new keystroke was previously used for a frequent and non-destructive operation, and there's no prompting. In some workflows I can make copies of files first, so possibly an option to entirely disable drag and drop, and the gimp-remote stuff, would help, but that's more draconian than I'd like! So how about (1) no default keybinding for "overwrite precious file" at all. (2) if we can't revert the window bindings (^e and ^E), at least make show/hide rulers (^R) work again, and (2b) do NOT have a keyboard shortcut that silently overwrites a file other than the one you are editing. (3) there should be a big warning when you use this "export to" thing. (4) if you use save-as, the default export (not "overwrite, I don't care about that menu item right now,but export...) filenme doesn't change, and it obviously should. This is just a bug. Right now it's just about impossible to move between gimp 2.6 and 2.7 without losing work, and the migration path is *really* scary. But it's improving, I have good hope ;-) Thanks, Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] making tool re-arrangements cancellable in the preferences dialog
I am looking for some advice on how to make tool re-arrangements
cancelable in the preferences dialog.
(for http://bugzilla.gnome.org/show_bug.cgi?id=500930)
the current code that resets the preferences looks like this (in
prefs-dialog):
if (gimp_dialog_run (GIMP_DIALOG (confirm)) == GTK_RESPONSE_OK)
{
GimpConfig *config_copy;
config_copy = g_object_get_data (G_OBJECT (dialog), "config-copy");
gimp_config_reset (config_copy);
}
Can anyone point me to an example of how to attach(?) a GimpContainer
(or something similar) to gimpconfig in order to reset order/visibility?
regards,
Stephen Griffiths.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scrollwheel actions by default?
The defaults are ok and match other graphic packages like Inkscape. I wouldn't touch them. Maybe you're coming from another software like Corel Draw and you got used to the scrolling with the mouse wheel, but that is not the same for everyone. CTRL + Scroll wheel does the same. The only difference between the default and your proposal is pressing a single common key. Your suggestion is only matter of personal preferences more than how it should be. For instance: Photoshop uses CTRL++ and CTRL+- to zoom in and out. We have just + and -. Should we change it because there is people used to photoshop and finds hard to get used to the diferent keystrokes? We have configurable keys, even we have a dynamic shortcuts configuration function for that. You found that by yourself and you changed the actions according your preferences, so the option is there, and people used to different defaults can customize their key shortcuts. We should change defaults only if there are better options. And in this case is proposed to change one existing and working shortcut to another, without much more reasons than "because I like it better" :-) Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scrollwheel actions by default?
Jernej Simončič writes: > I'm all for it - in my experience, the wheel is useless for scrolling > the images (partially because it's limited to single direction only), > but works very nicely for zooming in and out (and if you combine this I use the mousewheel for scrolling quite often, especially when I'm making a selection with polygonal select or quickmask so I'm zoomed way in to see pixel details. I find the - and +/= keys convenient for zooming in and out (and 1 for going to fullsize), so I've never needed mousewheel zooming. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
Sven Neumann wrote: > Hi, > > On Fri, 2009-07-24 at 11:48 +0200, gg wrote: > >> I added a comment to a png image and pressed Save. I was averted to the >> fact it failed by the fact it was too quick (a fairly large file). >> >> On repeating the save to see what happened I caught a glimpse of a >> subliminally fast message at the bottom off the screen. I repeated again >> to have time to read it. >> >> Basically it told me it was not saving because there were no changes. > > That's simply a bug then. Changing an image parasite should mark it as > dirty. Please file a bug-report for this. As gg was trying to point out, I think there is a more fundamental problem here with how GIMP reports feedback. A message that is "subliminally fast" is no message at all. At the very least, a message to the user should be visible for at least long enough for it to be read in its entirety (or the user should be able to go somewhere to read the message in its entirety). I just discovered that when I import an image from a Nikon raw file, the "Export to" menu item shows up as "Export to 300_1234.NEF". Of course, this is bogus, because GIMP doesn't have a NEF export plugin. Even worse, though, is that when I click the menu item, _there is no feedback_. As gg mentioned, the real problem here is not that GIMP does not do what you tell it to, but rather that it ignores your command and _doesn't tell you that it did_. More specifically, once I hit Ctrl+E and see the status message not saying anything about exporting, I expect the file to have been saved. If GIMP thinks there were no changes, it should say "no changes to save" in a way that is visible, easy to notice, and easy to read. If GIMP failed to save because there's no actual export plugin for the default export filename, it should say that too. Just playing the silent game is not an option. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] http post or ftp post
On Saturday 25 July 2009, Nico wrote: > Hi > > Is it possible to send data (http and/or ftp) in a script-fu plugin ? > Some examples ? > Wich way ? > > Nico The Scheme intrpreter used in script-fu it is there because an scheme interpreter is tiny enough to fit inside the source tree. (And for historical reasons as well, of course.) There are no libraries or moduyle to provide the tiny-fu scheme with much outside the GIMP API and some basic file I/O. So, while with unixish systems it is possible to provide a pipe/socket setup to make tiny-fu scripts answer network requests, that is not the way to do it. For doing larger applications, you should use plug-ins in a language that can make full use of libraries and modules manintained outside of the GIMP project. The oficial high level language supported for GIMP plug-ins is Python, and it is easy to make data available via vairous network protocols using Python's standard libraries. There re also gimp bindings for perl (although I think this is currently unmaintained) and ruby should you prefer these languages. js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FW: Improved brush editing interface mock-up
Luis Diego Alpizar Alpizar wrote: > I agree with this idea, but this would be implemented as a optional > interface? We will be able to use both(Dockables or Non-dockables)? > When i use Inkscape, i work very fast as their UI is very well done, > with the colours palette down. But other users might find usefull the > dockables As for the dockable windows, with this UI they will still be there, but they would be only dockable to the right side of the screen, as the current left toolbar would become a simple, standard toolbar. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scrollwheel actions by default?
On Saturday 25 July 2009, Jeremy Morton wrote: > 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. Hello Jeremy, as far as I see, it's configured to scroll up/down and left/right (when scrolling up/down and left right) by default. Plus Ctrl+scroll up/down is configured to zoom in/out. Maybe that's already enough to do what you had in mind without changing any defaults? Regards, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FW: Improved brush editing interface mock-up
On 07/25/2009 06:05 PM, Luis Diego Alpizar Alpizar wrote: > > This is the annotated version I sent to the GIMP UI brainstorm blog. It > > doesn't add much more than what has been already wrote in this thread > > though: > > > > http://img268.imageshack.us/img268/8928/sdigimp.png > > I agree with this idea, but this would be implemented as a optional > interface? We will be able to use both(Dockables or Non-dockables)? > When i use Inkscape, i work very fast as their UI is very well done, > with the colours palette down. But other users might find usefull the > dockables The current plan is add capabilities to allow toggling between the current multi-window interface and a new single-window interface to GIMP 2.10. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scrollwheel actions by default?
On Saturday, July 25, 2009, 17:57:39, peter sikking wrote: > if people like you find it smashing to zoom with the scroll-wheel, > then we should make that an easy preference, but not by default. I'm all for it - in my experience, the wheel is useless for scrolling the images (partially because it's limited to single direction only), but works very nicely for zooming in and out (and if you combine this with zooming not being centred around the mouse pointer, you get a nice way to scroll around the image in all directions very quickly by scrolling the wheel up and down). -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] FW: Improved brush editing interface mock-up
> This is the annotated version I sent to the GIMP UI brainstorm blog. It > doesn't add much more than what has been already wrote in this thread > though: > > http://img268.imageshack.us/img268/8928/sdigimp.png I agree with this idea, but this would be implemented as a optional interface? We will be able to use both(Dockables or Non-dockables)? When i use Inkscape, i work very fast as their UI is very well done, with the colours palette down. But other users might find usefull the dockables _ Prueba los mejores juegos online en MSN http://juegos.latam.msn.com/___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scrollwheel actions by default?
Jeremy wrote, > 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. ho ho, not so fast. the primary function of a scroll wheel is to scroll. do not forget that 2-dimensional scrolling thingies, like trackballs (as also seen on mice) are part of the same family and principle. if people like you find it smashing to zoom with the scroll-wheel, then we should make that an easy preference, but not by default. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : 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] The Export spec should be augmented to handle an important usecase
On Sat, 2009-07-25 at 15:22 +0200, peter sikking wrote: [...] > but it is impossible/the hack of the month to put widgets in > a gtk file dialog I was told. and I do not think it is worth it, > the hack of the month. It's only software... gtk+ could be changed, no? -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Nelson A. de Oliveira wrote: > This is something that I, as an user, would like to have. > It also seems to save some screen space when editing on a notebook > that can do only 1024x768 too :-) This is the annotated version I sent to the GIMP UI brainstorm blog. It doesn't add much more than what has been already wrote in this thread though: http://img268.imageshack.us/img268/8928/sdigimp.png -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] nodockables
Martin Nordholts wrote: > On 07/24/2009 11:55 AM, gg wrote: >> Hi, >> >> using gimp 2.6.6 I pulled the tool options dlg off the toolbox. Now it >> won't dock back in. >> >> the space says "you can drop dockable dialogs here" but nothing happens >> when I do. I remain with two independant windows. >> >> I was explaining to someone over the phone , theirs went back , mine >> didn't. I'm wondering if this is a WM issue. I'm using xfce4 >> > > This isn't really gimp-developer material, but gimp-user material. > Well I posted it here because I thought it was a bug relating to my using xfce. Now I know how it works, I would suggest it is discussed here to see if there is a way to make it more obvious, or to find another mechanism. Dragging the word "paintbrush" which is a heading and in no way looks like an active element is very obscure. Also if I select "lock tab to dock" when the window is free it prevents the docking action. One may think this is something to do with helping to dock it and in fact it prevents it. It seems it is locked into an undocked state. > Anway, you are not dragging the WM window title bar, right? You should > be dragging the dockable title itself (which is within the window). Yes > I know, this sucks, but that's what we have right now. > > / Martin > > Thanks for your reply. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Hi! On Sat, Jul 25, 2009 at 8:19 AM, SHIRAKAWA Akira wrote: > New interface and improvements mock-up link: > http://i31.tinypic.com/2qjd55k.png This is something that I, as an user, would like to have. It also seems to save some screen space when editing on a notebook that can do only 1024x768 too :-) Best regards, Nelson ___ 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
Re: [Gimp-developer] The Export spec should be augmented to handle an important usecase
Omari Stephens wrote: > UI powers that be: any ideas/status on this? having thought about it quite a bit, here are some jots: as Omari pointed out himself, it is a tug of war of different use cases and it depends on what just happens to be worked on, what the right default is for any given user. what is right may change a couple of times per hour of use. any solution can only be in the Export file-dialog, I agree on that with Tobias and other people who discussed this on irc. I would like to have had some widgets in the file dialog that not only navigated to alternative destination folders (of imported file when there is one at all, of saved xcf if there is one at all, does not need to be the case, right?) but also set that as the 'default destination policy override'. but it is impossible/the hack of the month to put widgets in a gtk file dialog I was told. and I do not think it is worth it, the hack of the month. so the next best thing is for GIMP to populate the Places column (also used in the 'Save in folder' pop-up), with: dir of of the imported file that started this file (when there is one); dir of last saved xcf of this file (when there is one) last 5 dirs exported to (hell why not) now I would like to know how these (dynamically) added Places turn out in the dialog. then we can talk about 5 last dirs for Save... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] http post or ftp post
Hi Is it possible to send data (http and/or ftp) in a script-fu plugin ? Some examples ? Wich way ? Nico ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
SHIRAKAWA Akira wrote: > Hello, I tried putting together my ideas I wrote about in this thread, in a single image. The result is an Inkscape-like SDI GIMP I know that in the medium term one of the main goal will be an SDI interface, and that would work very well with the improvements I have in mind. New interface and improvements mock-up link: http://i31.tinypic.com/2qjd55k.png Work in progress (the images needs annotations), of course, and open to changes and suggestions. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
SHIRAKAWA Akira wrote: > Yes, my proposition is to unify all of those. And this is a mock-up of my idea of how the toolbar would end up looking like by merging many tools into one: http://i25.tinypic.com/2ihxyd5.png -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
