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 harm, btw. Just to clarify what I meant when I said hard-coding a value - since it seems to have caught on as a phrase. The default value is hard-coded for any given menu item. When registering the menu item, there is a C function call that basically does this... register menu item (name, menu placement, default shortcut); A registered menu item corresponds to a function being called. I seem to recall that it was possible to say register menu item (name, menu placement, default shortcut 1); register menu item (name, menu placement, default shortcut 2); and have 2 shortcuts to the same menu item. This is not possible in gtk+ 2 (the second shortcut over-writes the first one), so talking about hardcoding several shortcuts is probably useless :) Note also that the hard-coded shortcut is the default shortcut... it seems that there was some confusion about this above. There may be hacky ways around this, such as creating phantom menu items with one shortcut which are nothing but wrappers around another menu item, but that way leads madness when you throw dynamic shortcuts into the mix. They did not have any problem about changing button order from the most used one (important button on left side, for LTR languages) to the easier to use one (imporant on right side), OTOH, so logic behind when to change and when not is fuzzy for me. The button order is used elsewhere (Mac). It should be used in conjunction with better dialogs (action verbs such as Save, Revert, Don't save rather than Yes, No, Cancel). And the logic behind it is simply that humans using LTR languages read dialogs from the top left to the bottom right, so the default action should be on the bottom right. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Redo shortcut
[EMAIL PROTECTED] (2003-10-01 at 0852.29 +0200): They did not have any problem about changing button order from the most used one (important button on left side, for LTR languages) to the easier to use one (imporant on right side), OTOH, so logic behind when to change and when not is fuzzy for me. The button order is used elsewhere (Mac). It should be used in conjunction with better dialogs (action verbs such as Save, Revert, Don't save rather than Yes, No, Cancel). And the logic behind it is simply that humans using LTR languages read dialogs from the top left to the bottom right, so the default action should be on the bottom right. Fine, I know about the order and the verbs, so I can not understand why there seems to be a blind reasoning about shortcuts: not every app requires the same functions nor the same usage pattern, so settings lots of shortcuts that only seem to match text editors and browser seems unreasonable. Gimp has collisions with other keys, you just changed one, but there are more, if you want to comply, your work is half done... and I will change back in my own config to make things nice for a Gimp user instead than for a HIG writer. HIG is not set in stone, and even then, it can be wrong. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] When will we branch CVS gimp-2-0?
According to the roadmap proposed a few weeks ago, we should be in feature freeze and we should have released 2.0rc1 by now. Also, the old web site was supposed to be replaced by the new one in order to be prepared to support the new release. None of this has happened: new features are still being implemented (e.g., the nice tool presets added yesterday), we are planning for 1.3.21 soon (not ready for 2.0rc1 yet) and the web site hasn't been moved. This is not a real problem because this is usual in Free Software projects and there are be good reasons for these delays: a 1.3.21 release would be really useful to test the latest bug fixes. But if we still want to keep the goal of releasing 2.0 before next year, then it would be useful to revive the idea of the feature freeze. One way to do that would be to create a branch for 2.0 (like what was done for gimp-1-2) and say that only bug fixes can be done on that branch. Being forced to move away from CVS HEAD would probably change the way we consider the code for 2.0, and discourage the addition of new features which may be very nice and useful, but go against the feature freeze. I suggest to create that branch immediately after the 1.3.21 release. What do you think? -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Redo shortcut
On Wed, 1 Oct 2003 17:32:39 +0200, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] wrote: Fine, I know about the order and the verbs, so I can not understand why there seems to be a blind reasoning about shortcuts: not every app requires the same functions nor the same usage pattern, so settings lots of shortcuts that only seem to match text editors and browser seems unreasonable. It does not only seem to match text editors and browsers. The first examples of shortcuts that were posted at the beginning of this discussion (previous thread) mentioned the shortcuts used in Photoshop and Paint Shop Pro on Mac and Windows. Gimp has collisions with other keys, you just changed one, but there are more, if you want to comply, your work is half done... and I will change back in my own config to make things nice for a Gimp user instead than for a HIG writer. HIG is not set in stone, and even then, it can be wrong. Yes, but on the other hand we should not invent or keep old shortcuts that are not used by any other applications if it would be possible to use some well-known shortcuts without significant drawbacks. Using the same shortcuts as some other applications would be a great help for the new users. So from my point of view, the list of choices for the Redo shortcut contains only two alternatives: Ctrl-Shift-Z or Ctrl-Y. We should pick one of these, but not the old shortcut. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] When will we branch CVS gimp-2-0?
Hi, Raphal Quinet [EMAIL PROTECTED] writes: I suggest to create that branch immediately after the 1.3.21 release. What do you think? We create a branch immidiately after 2.0 is released. We don't have the resources to handle more branches. If you branch now (or after 1.3.21), we will never get a 2.0 release out. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Redo shortcut
Hi, Raphal Quinet [EMAIL PROTECTED] writes: It does not only seem to match text editors and browsers. The first examples of shortcuts that were posted at the beginning of this discussion (previous thread) mentioned the shortcuts used in Photoshop and Paint Shop Pro on Mac and Windows. The Photoshop Undo feature is completely different from GIMP's way of handling Undo. The PhotoShop shortcut thus doesn't have much weight in this discussion. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: When will we branch CVS gimp-2-0?
On Wed, Oct 01, 2003 at 07:39:58PM +0200, Sven Neumann wrote:
Hi,
Raphaël Quinet [EMAIL PROTECTED] writes:
I suggest to create that branch immediately after the 1.3.21 release.
What do you think?
We create a branch immidiately after 2.0 is released. We don't have
the resources to handle more branches. If you branch now (or after
1.3.21), we will never get a 2.0 release out.
I second this. If we create a 2.0 branch too soo, I'm afraid people
will think ok, this branch is for bugfixes only, let's play with HEAD
instead. This way coders will be much more interested in adding new
features in HEAD than in finding bugs into the 2.0 branch. So please
delay the 2.0 branch until 2.0 is out.
Regards,
DindinX
--
[EMAIL PROTECTED]
float l,I,Q,_,o;int E;main(){I=1.125;while(I=-1.225){for(l=
-2;l=1;l+=3/79.0){Q=_=0;for(E=127;Q*Q+_*_4.0--E32;){o=Q
;Q=Q*Q-_*_+l;_=2*o*_+I;}putchar(E);}putchar(10);I-=9/88.0;}}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Usability] Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
Calum Benson wrote: Whimsical muse: since there are almost no other gtk/GNOME apps that use Redo (and the only one I can think of doesn't use Ctrl-Shift-Z either), it's not beyond the bounds of possibility that we might end up changing the HIG to whatever you decide anyway :) Well, thanks for clearing that up for us, Calum :) Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[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] When will we branch CVS gimp-2-0?
Hi, Sven Neumann wrote: Raphaël Quinet [EMAIL PROTECTED] writes: I suggest to create that branch immediately after the 1.3.21 release. We create a branch immidiately after 2.0 is released. We don't have the resources to handle more branches. If you branch now (or after 1.3.21), we will never get a 2.0 release out. Agreed. Pre-release branches might work on other projects with more developer resources. The reality is we want everyone who has time to work on bug-fixes to have a 2.0 before Christmas (that's still the goal, and we're still on target for that). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, Tom Mraz [EMAIL PROTECTED] writes: 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. The new menu API in GTK+-2.4 will solve quite a few of our problems. I am really looking forward to have the GIMP HEAD branch depend on 2.4 after the GIMP-2.0 release is out. Then we can finally clean up this menu mess. The new GTK+ menu API really looks very promising. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
