[Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
FYI (multiple keybindings per menu action in GTK+). As I see it will be implemented in GTK+ 2.4 I vote for leaving the current redo keybinding as is and wait for GTK+ 2.4 with the change. Tom Mraz Original Message Subject: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries http://bugzilla.gnome.org/show_bug.cgi?id=123647 Changed by [EMAIL PROTECTED] --- shadow/123647 Wed Oct 1 13:49:47 2003 +++ shadow/123647.tmp.32485 Wed Oct 1 17:09:22 2003 @@ -1,13 +1,13 @@ Bug#: 123647 Product: gtk+ Version: 2.2.x OS: Linux OS Details: -Status: NEW -Resolution: +Status: RESOLVED +Resolution: FIXED Severity: enhancement Priority: Normal Component: gtk AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] TargetMilestone: --- @@ -16,6 +16,10 @@ It should be possible to attach additional (hidden) keybindings (accelerators) to menu entries. It would be a very useful functionality for backward (or another app) compatibility. + +--- Additional Comments From [EMAIL PROTECTED] 2003-10-01 17:09 --- +This will be possible in 2.4 using accelerator elements with the new +GtkUIManager. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Redo shortcut
Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2003-09-26 at 1933.11 +): I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible). Grouped undo, or call undo history, ie. Hardcoding would be more problem than help, btw. I meant to hardcode it in such a way, that it could be reassigned by user keybinding preference to other function. Not that I think it's probable that anyone would reassign it to anything. Tom Mraz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut
I believe we could hard-code two keybindings to work as the default, couldn't we? Technically possible, but extremely horrible, since the user has to be educated about it. And since the only argument in favour of the less ergonomic C-S-Z is easier to learn, that sounds even worse than leaving it at C-R. I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. Then if you move from photoshop or HIGified Gnome apps, it will work for you. But the (IMHO) much more ergonomic C-R stays as the default for newbies. As it was said earlier the ergonomics of Redo operation in for example text editor is less important as you don't use it so often and you don't switch between Undo and Redo very fast and frequently. Tom Mraz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
4.) The old eraser should be replaced with an 'Erase' - mode for the paint tools (Brush, Pen, Airbrush, Ink, Text, Fill), to be able to use e.g. the Airbrush as Eraser, this would make the interface less cluttered and also improves the flexibility. Same goes for the 'Smudge', 'Blur', 'Paint using Patterns' 'Sharpen' tools; Ok, here is how Deluxe Paint would deal with this: painting with right mouse button instead of the left would use the Background color, instead of foreground. In the GIMP, while it is not possible to make such a ssue to the right mouse button, there could, and IMO should, be a fast keystroke (mnemonic?) to swap BG and FG. It is great for a couple of fancy effects to be able to quicly switch between fg/bg without moving the cursor. That's not what I meant, I meant the eraser, not the bg color. But you are right on the keystroke, this would be a great addition. As for the eraser tool, it is currently the only of the paint tools that paints to transparency without the need to paint on the mask. Besides, the behavior of the ctrl key in it comes close, if one is paiting on the background, of the color swapping feature. And this is exactly the problem, only the eraser tool paints to transparency. And it should be possible to use ANY paint tool to do this. It could be as simple as reversing the alpha value for this tool... Alpha/ erase != bg color (at least if you use more than one layer). Have you entered this issue as a enhancement bug to Gimp bugzilla? If not would you do it or I could do it, because IMHO it would be a really good thing to have. I think it's pretty orthogonal to having alpha value in color picker and selector, because it could simply paint to full transparency (based on the properties of the brush and kind of a paint tool). In case of images without alpha channel it would simply paint to background color. Tom Mraz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint Shop Pro 8
Sven Neumann wrote: The imagemap plug-in creates a TOPLEVEL window while most other GIMP dialogs are of type DIALOG and I think this is correct. Any WM that thinks that dialog windows shouldn't have minimise and maximize buttons is probably on crack. I've always thought the same about metacity which is one of these. Please file it against metacity. But don't hope for fix because Havoc won't allow to change this *#$! behaviour. Tom Mraz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
It is probably this checkin: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=contextwhitespace_mode=showfile=gifload.cbranch=root=/cvs/gnomesubdir=/gimp/plug-ins/commoncommand=DIFF_FRAMESETrev1=1.30rev2=1.31 The guchar - gchar change without correcting the code using the buf isn't probably good idea? Tom ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Adam D. Moss wrote: Tom Mraz wrote: The guchar - gchar change without correcting the code using the buf isn't probably good idea? I think you're right. That bogus change totally sneaked under my radar... (heads will roll! :D :D :D ) If someone who sees the problem can test this fix: http://icculus.org/~aspirin/gifload.c that'd be good. I've tested it and it fixes the bug. Tom Mraz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
