Suggestions + Patch, Redo - Part 1
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
[long] Suggestions + Patch, Redo (please dont flame), Part 1
on IRC Sven said i really should put these changes to the list for discussion
I will try and make keep this simple but I have a few loosely related
changes all of which are against gimp/app/gui/image-menu.c
The patch is here
http://bugzilla.gnome.org/showattachment.cgi?attach_id=17739
Attached to this bug report
http://bugzilla.gnome.org/show_bug.cgi?id=92468
The patch itself is simple, but I expect it will be controversial.
Firstly (and most likely to be incredibly unpopular) I want to change
Redo Control+R to
Redo Control+Shift+Z
Reasons:
Ctrl+R is not unreasonable, as R is the first letter of Redo (in English at least) and it probably comes from something older than me that I am unaware of but very few other applictions use it, which makes it inconsistant and harder for most people to learn.
I will qualify what I mean when I say very few:
Microsoft Windows doesnt use Ctrl+R, usually it uses Ctrl+Y the twisted logic being that Y comes before Z and Z is used for Undo. (Mozilla uses Ctrl+Y for Redo as well).
Apple OS X uses AppleKey/"CommandKey" + Shift + Z, older versions may have used "CommandKey" + Y but I cannot remember clearly. The logic is to use a Shifted version of a keybinding for closely related actions across the whole desktop which makes it slightly easier to guess unknown keybindings (and means you can use Ctrl+Y for something else).
Gnome uses* Ctrl+Shift+Z for Redo.
[* most Gnome apps do already or will follow the Gnome Human Interface
Guidelines.
This guideline does makes sense, they are just following Apples logic]
KDE also uses Ctrl+Shift+Z http://developer.kde.org/documentation/standards/kde/style/menus/edit.html
(These are based on a google search:) Abode Photoshop also seems to use Ctrl+Shift+Z for Redo Jasc Paint Shop Pro is a bit strange and uses Ctrl+Alt+Z, because Ctrl+Shift+Z is already taken by Undo History (using Ctrl+Alt+Z for Undo in Gimp wouldn't be a terrible idea, but i know using Alt cause some minor problems in places).
So I have made it pretty clear that many many people would be more comfortable with having Ctrl+Shift+Z but I have not forgotten about those of you who have been using the Gimp for a very long time. One option is to reassig the keybinding manually. There also already exists a Menu Configuration File for Photoshop users, I propose a Menu Configuration for users who like the current menu configuration and dont want things changed (there was a bug report about being allowed to change and reset the menurc from the preferences dialog but i am not sure of its current state).
I also want Ctrl+R for a different keybinding.
This message is getting really long so I will explain the rest of the patch in other emails, please hold off critiquing the rest of the patch for a while so that I have a chance to _fully_ explain my reasoning.
I have put a lot of time and thought into this, but I am not an expert I just know what I like and have a reasonably good understanding of why so please consider your criticism carefully.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
PS Please leave my address in the CC line, I am subscribed to the list digest and it will take me a while to give carefully considered responses to any questions.
[long] Suggestions + Patch, Redo (please dont flame), Part 1
Hi,
Alan Horkan writes:
So I have made it pretty clear that many many people would be more comfortable with having Ctrl+Shift+Z but I have not forgotten about those of you who have been using the Gimp for a very long time. One option is to reassig the keybinding manually. There also already exists a Menu Configuration File for Photoshop users, I propose a Menu Configuration for users who like the current menu configuration and dont want things changed (there was a bug report about being allowed to change and reset the menurc from the preferences dialog but i am not sure of its current state).
I think we shouldn't do this change since I can not follow your arguments. Everyone seems to be using a different keybinding for Redo and we use Ctrl-R for quite some time now. Why should we change the default? Perhaps we need a hig-menurc...
Sven
[long] Suggestions + Patch, Redo (please dont flame), Part 1
Sven Neumann wrote:
Alan Horkan writes:
So I have made it pretty clear that many many people would be more comfortable with having Ctrl+Shift+Z but I have not forgotten about those of you who have been using the Gimp for a very long time. One option is to reassig the keybinding manually.
I think we shouldn't do this change since I can not follow your arguments. Everyone seems to be using a different keybinding for Redo and we use Ctrl-R for quite some time now. Why should we change the default? Perhaps we need a hig-menurc...
Well, the two big platforms where the GIMP will be used in the future are GNOME and KDE. Both of those follow the HIG guideline of Ctrl-Shift-Z. On windows, the main alternative app (photoshop) uses the same shortcut.
I think following the HIG by default is a good thing. People will get used to the new defaults. I'd have more of a problem with having those kinds of things as options, to be quite honest.
Cheers, Dave.
[long] Suggestions + Patch, Redo (please dont flame), Part 1
On Wed, Jun 25, 2003 at 05:06:00PM +0200, David Neary wrote:
Well, the two big platforms where the GIMP will be used in the future are GNOME and KDE. Both of those follow the HIG guideline of Ctrl-Shift-Z. On windows, the main alternative app (photoshop) uses the same shortcut.
While I totally agree to your agruments about following existing standards and/or practise, in Gimp we have the additional problem that ctrl-shift-z is not very ergonomical. Unlike word processors, undo-redo (repeatedly) is quite a normal and very common operation with gimp to compare operations or filters.
[long] Suggestions + Patch, Redo (please dont flame), Part 1
On Thu, Jun 26, 2003 at 03:21:03AM +0200, Marc A. Lehmann wrote:
Well, the two big platforms where the GIMP will be used in the future are GNOME and KDE. Both of those follow the HIG guideline of Ctrl-Shift-Z. On windows, the main alternative app (photoshop) uses the same shortcut.
While I totally agree to your agruments about following existing standards and/or practise, in Gimp we have the additional problem that ctrl-shift-z is not very ergonomical. Unlike word processors, undo-redo (repeatedly) is quite a normal and very common operation with gimp to compare operations or filters.
Why not simply (?) use both keystrokes?
Bye, Tino.
[long] Suggestions + Patch, Redo (please dont flame), Part 1
On Thu, 2003-06-26 at 03:21, pcg@goof.com wrote:
On Wed, Jun 25, 2003 at 05:06:00PM +0200, David Neary wrote:
Well, the two big platforms where the GIMP will be used in the future are GNOME and KDE. Both of those follow the HIG guideline of Ctrl-Shift-Z. On windows, the main alternative app (photoshop) uses the same shortcut.
While I totally agree to your agruments about following existing standards and/or practise, in Gimp we have the additional problem that ctrl-shift-z is not very ergonomical. Unlike word processors, undo-redo (repeatedly) is quite a normal and very common operation with gimp to compare operations or filters.
The unfortunate thing for GIMP is that Shift is not quite the 'invert' keybinding (undo/redo). In other applications this works extremely well because the shift key is the invert-keybinding, but for some reason we have Ctrl (dodge/burn, sharpen/blur, FG/BG fill, horizontal/vertical flip ...).
If we were to be consistent, this would have changed so that the shift key is again again the invertor. But this would mean a lot of replacing of Ctrl/Shift throughout the tools.
I, for one, would welcome some thought put into consistency.
[long] Suggestions + Patch, Redo (please dont flame), Part 1
Hi,
tino.schwarze@informatik.tu-chemnitz.de (Tino Schwarze) writes:
Why not simply (?) use both keystrokes?
Because IIRC, GTK+ simply does not support this. Apart from that, I think it would introduce clutter and confusion.
Sven
[long] Suggestions + Patch, Redo (please dont flame), Part 1
Jakub Steiner wrote:
If we were to be consistent, this would have changed so that the shift key is again again the invertor. But this would mean a lot of replacing of Ctrl/Shift throughout the tools.
I, for one, would welcome some thought put into consistency.
As would I. I would like to get some usability people to have a look at the current CVS gimp and give us ideas as to what we can do to make the interface more consistent, and more user-friendly.
In the meantime, there are some basics - keystrokes which are so common elsewhere that the fact that we use something else is an aberration, and has just stayed like that for ages, rather than a policy decision.
The HIG is a good start, as are the OpenDesktop reccommendations/standards (which we've been following for the most part). It would be nice to consistentise the interface between now and GIMP:TNG.
Cheers, Dave.
Suggestions + Patch, Redo - Part 1
pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:
On Wed, Jun 25, 2003 at 05:06:00PM +0200, David Neary wrote:
Well, the two big platforms where the GIMP will be used in the future are GNOME and KDE. Both of those follow the HIG guideline of Ctrl-Shift-Z. On windows, the main alternative app (photoshop) uses the same shortcut.
While I totally agree to your agruments about following existing standards and/or practise, in Gimp we have the additional problem that ctrl-shift-z is not very ergonomical. Unlike word processors, undo-redo (repeatedly) is quite a normal and very common operation with gimp to compare operations or filters.
BTW, an area in which GIMP just TOTALLY SMASHES OUT Corel Photo Paint 9 - the stuff I had to use before managing to swtch at work. In that crappy program, the Undo history is erasen after a couple of seconds of idle activity, sometimes randomly. Which means one can never be SHURE if the changes of a filter will possibly be undoable.
Also, that crappy program will erase the undo history after File Save actions. That turns very difficult to save a version of an image with a filter applied, and them go back to working on the image without that filter.
Anyway, I will have no say on what Key I'd prefer for the GIMP Undo at this time. Both CTRL + R and Shift + Ctrl + Z have good arguments. Just please, do keep Ctrl + Alt + Z out of question, it is hard to reach and ALT do indeed have some issues in the KDE enviromment. And, anyway, one of the first things I teach to one who is learning the GIMP is the dinamic shortcut allocation.
Regards,
JS ->
Suggestions + Patch, Redo - Part 1
On Thu, Jun 26, 2003 at 09:07:30AM -0300, "Joao S. O. Bueno" wrote:
of the first things I teach to one who is learning the GIMP is the dinamic shortcut allocation.
Which has gone out of 1.3 (yes, you can enable it in the preferences, but people telling me that it probably doesn't work because it collides with gtk2 isn't encouraging).
That's actually my only usability problem with 1.3 now... If dynamic shortcuts don't work reliably, they should be taken out and not be offered. The better option would be to "fix" gtk2 if it needs fixing, or just plain disbaling that part, since I can't say I found anything int he new UI that would let pay me the price of not having dynamic shortcuts.
Really, dynamic key bindings is *the* killer feature. Disabling it in 1.3 is a major drawback.
Suggestions + Patch, Redo - Part 1
pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:
On Thu, Jun 26, 2003 at 09:07:30AM -0300, "Joao S. O. Bueno" wrote:
of the first things I teach to one who is learning the GIMP is the dinamic shortcut allocation.
Which has gone out of 1.3 (yes, you can enable it in the preferences, but people telling me that it probably doesn't work because it collides with gtk2 isn't encouraging).
That's actually my only usability problem with 1.3 now... If dynamic shortcuts don't work reliably, they should be taken out and not be offered. The better option would be to "fix" gtk2 if it needs fixing, or just plain disbaling that part, since I can't say I found anything int he new UI that would let pay me the price of not having dynamic shortcuts.
Really, dynamic key bindings is *the* killer feature. Disabling it in 1.3 is a major drawback.
Agreeded.
I don't know how much it's dictated by gtk2, but it seens weird that the GIMP usability gets hurt for changes on The Gimp Toolkit.
Suggestions + Patch, Redo - Part 1
Hi,
writes:
of the first things I teach to one who is learning the GIMP is the dinamic shortcut allocation.
Which has gone out of 1.3 (yes, you can enable it in the preferences, but people telling me that it probably doesn't work because it collides with gtk2 isn't encouraging).
That's actually my only usability problem with 1.3 now... If dynamic shortcuts don't work reliably, they should be taken out and not be offered. The better option would be to "fix" gtk2 if it needs fixing, or just plain disbaling that part, since I can't say I found anything int he new UI that would let pay me the price of not having dynamic shortcuts.
Really, dynamic key bindings is *the* killer feature. Disabling it in 1.3 is a major drawback.
You obviously did not understand the reasoning behind this change. There is no problem with Dynamic Shortcuts not working reliably and there's no need for any fixing in gtk2. The only problem is that since shortcuts can be easily changed, they are easily changed by accident. With the use of mnemonics in 1.3 the chance to make such a mistake has increased. That's why it is disabled by default.
Reassigning shortcuts should be done with care and thought. People are supposed to go to the Prefs, enable Dynamic Shortcuts, change the keyboard shortcuts, then disable Dynamic Shortcuts again. That way the configured shortcuts are safe from accidental changes. IMO this is an improvement over 1.2.
Sven
Suggestions + Patch, Redo - Part 1
On Thu, 2003-06-26 at 15:21, Sven Neumann wrote:
Reassigning shortcuts should be done with care and thought. People are supposed to go to the Prefs, enable Dynamic Shortcuts, change the keyboard shortcuts, then disable Dynamic Shortcuts again. That way the configured shortcuts are safe from accidental changes. IMO this is an improvement over 1.2.
It is a elegant solution and the feature is definitely not lost.
Suggestions + Patch, Redo - Part 1
On Thu, Jun 26, 2003 at 10:02:41AM -0300, "Joao S. O. Bueno" wrote:
I don't know how much it's dictated by gtk2, but it seens weird that the GIMP usability gets hurt for changes on The Gimp Toolkit.
Woaw, that sounding like a great argument, but I still think that gtk+ deserves it's life on it's own, and although it *is* the gimp toolkit it is also the toolkit for many other programs, which is why it is a seperate library nowadays.
Suggestions + Patch, Redo - Part 1
On Thu, Jun 26, 2003 at 03:21:10PM +0200, Sven Neumann wrote:
You obviously did not understand the reasoning behind this change.
Obviusly not, since only you explained it so far, saying that it clashes with gtk+.
With the use of mnemonics in 1.3 the chance to make such a mistake has increased. That's why it is disabled by default.
So it's basically a beginners mode of menus. That's fine to me, for course. From what you said I took it was dangerous to enable it, which it clearly isn't.
keyboard shortcuts, then disable Dynamic Shortcuts again. That way the configured shortcuts are safe from accidental changes. IMO this is an improvement over 1.2.
I strongly disagree, since dynamic shortcuts is *the* outstandiong feature that makes gimp usable form the keyboard. You actually suppose that users are incapable of using a keyboard. I don't think that this is an improvement.
However, there is no need to change this at all, I was just under the wrong impression that it was dangerous to enable them *at all*, and not "dangerous to enable them because I often bump my head on the caps at the wrong time" :)
Thanks for clarifying this and giving me back the great feeling I have when reassigning shortcuts to filters I often use.
Suggestions + Patch, Redo - Part 1
Hi,
writes:
However, there is no need to change this at all, I was just under the wrong impression that it was dangerous to enable them *at all*, and not "dangerous to enable them because I often bump my head on the caps at the wrong time" :)
Well, we plan to add more mnemonics to the menus (mnemonics are those underlined characters that improve keyboard navigation). As soon as you start using them, you will find yourself accidentally reassigning keyboard shortcuts quite frequently.
Sven
Suggestions + Patch, Redo - Part 1
On Fri, Jun 27, 2003 at 04:07:29PM +0200, Sven Neumann wrote:
However, there is no need to change this at all, I was just under the wrong impression that it was dangerous to enable them *at all*, and not "dangerous to enable them because I often bump my head on the caps at the wrong time" :)
Well, we plan to add more mnemonics to the menus (mnemonics are those underlined characters that improve keyboard navigation). As soon as you start using them, you will find yourself accidentally reassigning keyboard shortcuts quite frequently.
When I understand you correctly this means that I will see underlined entries that will not work as the corresponding keys are assigned by me to sth. else.
Then this looks like a serious issue, since this feature is probably not used often by advanced users, but often by beginners, while the dynamic shortcuts are used as quick-assign-keys by advanced users.
While I am all for making gimp more usable, I think making it more useful to advanced users would be better than to make life harder for them (correct me if i am wrong, but do you know anybody who is seriously using gimp without extensively using dynamic shortcuts? I don't).
What you describe clearly is also a bug, since either the mnemonics shouldn't be there if they clash with my own keybindings (just as reassigning a keybinding will remove the old assigment), or the reassignment shouldn't happen when it clashes (less preferable).
Also, wouldn't it make sense to use only one mechanism to handle both dynamic assigments as well mnemonics? If menmonics can't do that this might be a shortcoming in gtk2.
Lastly, telling me I don't understand something because it works fine and then telling me that the feature doesn't work fine sounds like there might still be a problem lurking in this area... :)
Suggestions + Patch, Redo - Part 1
Agreed.
While I am all for making gimp more usable, I think making it more useful to advanced users would be better than to make life harder for them (correct me if i am wrong, but do you know anybody who is seriously using gimp without extensively using dynamic shortcuts? I don't).
What you describe clearly is also a bug, since either the mnemonics shouldn't be there if they clash with my own keybindings (just as reassigning a keybinding will remove the old assigment), or the reassignment shouldn't happen when it clashes (less preferable).
Suggestions + Patch, Redo - Part 1
On Sat, 2003-06-28 at 01:13, pcg@goof.com wrote:
Then this looks like a serious issue, since this feature is probably not used often by advanced users, but often by beginners, while the dynamic shortcuts are used as quick-assign-keys by advanced users.
The feature will be quite often used by very advanced users who run out available shortcuts and will start using mnemomics for common functions (there can be a lot more mnemonics than shortcuts - they are multi-dimensional; gaussian blur could be accessed with a sequence alt+f,b,g for example).
While I am all for making gimp more usable, I think making it more useful to advanced users would be better than to make life harder for them (correct me if i am wrong, but do you know anybody who is seriously using gimp without extensively using dynamic shortcuts? I don't).
The feature is not going away. You can toggle it on. I consider myself an advanced GIMP user and I rarely want to keep reassigning shortcuts in every GIMP session. The feature rocks, but I usually assign the shortcuts and save the session. Done.
What you describe clearly is also a bug, since either the mnemonics shouldn't be there if they clash with my own keybindings (just as reassigning a keybinding will remove the old assigment), or the reassignment shouldn't happen when it clashes (less preferable).
The solution to the bug was the preference toggle. These two things just don't work together. I find them both very useful.
Lastly, telling me I don't understand something because it works fine and then telling me that the feature doesn't work fine sounds like there might still be a problem lurking in this area... :)
The only other 'solution' to this problem I can think of is not using a
single letter shortcuts, so that they would only work for mnemonics. I
find this worse than the preference toggle, because the basic tools
really need to be accessible with a fast shortcut.
cheers
Suggestions + Patch, Redo - Part 1
On Sat, 2003-06-28 at 01:13, pcg@goof.com wrote:
Then this looks like a serious issue, since this feature is probably not used often by advanced users, but often by beginners, while the dynamic shortcuts are used as quick-assign-keys by advanced users. While I am all for making gimp more usable, I think making it more useful to advanced users would be better than to make life harder for them (correct me if i am wrong, but do you know anybody who is seriously using gimp without extensively using dynamic shortcuts? I don't).
What you describe clearly is also a bug, since either the mnemonics shouldn't be there if they clash with my own keybindings (just as reassigning a keybinding will remove the old assigment), or the reassignment shouldn't happen when it clashes (less preferable).
Also, wouldn't it make sense to use only one mechanism to handle both dynamic assigments as well mnemonics? If menmonics can't do that this might be a shortcoming in gtk2.
Lastly, telling me I don't understand something because it works fine and then telling me that the feature doesn't work fine sounds like there might still be a problem lurking in this area... :)
I consider myself an advanced user and I find both the mnemonics and the dynamic shortcuts useful. You can quickly run out of shortcuts, but because they are multilevel, mnemonics can still be used to quickly access a feature (alt+f,b,g sequence to access gaussian blur for example).
I find the preference toggle to be a best solution to the two clashing features. I do not want access keys/mnemonics to go away because of dynamic shortcuts. Another solution would be to not use single key shortcuts, so that those work for all the mnemonics, but I find that more limiting than the preference toggle, since I usually set up shortcuts once and then work with the session.
cheers
P.S.: if my previous mail actually made it, accept my apology for double posting.
Suggestions + Patch, Redo - Part 1
On Sat, Jun 28, 2003 at 12:20:26PM +0200, Jakub Steiner wrote:
reassigning a keybinding will remove the old assigment), or the reassignment shouldn't happen when it clashes (less preferable).
The solution to the bug was the preference toggle. These two things just
Since the preferences toggle doesn't solve it at all, why do you call it a solution? Toggling it on does not work, as Sven said, as then mnemonics and dynamic shortcuts will clash.
The preferences option is more like a hack so people can temporarily enable it, but that cannot be a solution, just a workaround to limit the damage.
The only other 'solution' to this problem I can think of is not using a single letter shortcuts, so that they would only work for mnemonics. I find this worse than the preference toggle, because the basic tools really need to be accessible with a fast shortcut.
But why do menmonics and dynamic shortcuts clash at all? Either a key is bound to a menmonic or it is bound to a dynamic shortcut, but never both. And if I really want to reassign a key used currently by a mnemonic, it should either work or not work, but assigning it to both mnemonic and a shortcut doesn'T sound like a "solution" to me.
Suggestions + Patch, Redo - Part 1
On Sat, Jun 28, 2003 at 12:20:26PM +0200, Jakub Steiner wrote:
On Sat, 2003-06-28 at 01:13, pcg@goof.com wrote:
Then this looks like a serious issue, since this feature is probably not used often by advanced users, but often by beginners, while the dynamic shortcuts are used as quick-assign-keys by advanced users.
The feature will be quite often used by very advanced users who run out available shortcuts and will start using mnemomics for common functions (there can be a lot more mnemonics than shortcuts - they are multi-dimensional; gaussian blur could be accessed with a sequence alt+f,b,g for example).
Wouldn't it be nice if you could do:
-x ^h
to popup a window of available combinations. Or
-x gauss-blur
and of course
-x -p
to rerun the last plug-in.
Beginner users would probably not use these combinations, but for power users emacs is the sky. ;-)
Regards, Dov
[rest of email deleted]
Suggestions + Patch, Redo - Part 1
On Sat, 2003-06-28 at 18:34, pcg@goof.com wrote:
But why do menmonics and dynamic shortcuts clash at all? Either a key is bound to a menmonic or it is bound to a dynamic shortcut, but never both. And if I really want to reassign a key used currently by a mnemonic, it should either work or not work, but assigning it to both mnemonic and a shortcut doesn'T sound like a "solution" to me.
The problem is that once you enter a submenu an item is selected. Mnemonics make it possible to access a particular item in the submenu with an underlined letter. But with dynamic shortcuts on, you can assign a shortcut to the active item. And it can be a single letter/key shortcut.
It may be possible to have no items selected when entering a subdirectory, but I'd have to leave that discussion to gtk+ aware hackers. Also the parent menu item might be ready to accept the shortcut combo at this time, so maybe it doesn't solve the problem either.
If you think of the 'dynamic shortcuts' preference as an alternative to shortcut editor you will probably see it's not much of a workaround. You activate it and are working in shortcut learning mode. You turn it off once you're done with assigning shortcuts.
cheers
Suggestions + Patch, Redo - Part 1
On Sun, Jun 29, 2003 at 11:29:30AM +0200, Jakub Steiner wrote:
If you think of the 'dynamic shortcuts' preference as an alternative to shortcut editor you will probably see it's not much of a workaround. You activate it and are working in shortcut learning mode. You turn it off once you're done with assigning shortcuts.
Unfortunately, many people (like me) actually use them for dynamic shortcuts, and having to enable/disable it everytime you reassign keybindings makes the feature useless. Essentially the "dynamic" part of the feature got severly limited.
Sure, "if" you think that way it's fine... but not everybody thinks in statically assigned keybindings, I often reassign keys dynamically in vi or use macros, the same is true for gimp. Of course, I am not such a power user that gimp should be specifically re-written for my (possibly exceptional) taste.
While I don't understand *exactly* the issues, I am not arguing from the point of "the design is broken" but from a point of "a very useful feature now became rather limited". It might be possible that there is no current solution since mnemonics and dynamic shortcuts simply cannot be made to harmonize. I just wanted to say that it's a useful feature, and it *should* be supported. If it is dangerous to use or if it cannot be supported in the 1.2 way, so be it...
Suggestions + Patch, Redo - Part 1
On Mon, Jun 30, 2003 at 12:25:40AM +0200, Marc A. Lehmann wrote:
On Sun, Jun 29, 2003 at 11:29:30AM +0200, Jakub Steiner wrote:
If you think of the 'dynamic shortcuts' preference as an alternative to shortcut editor you will probably see it's not much of a workaround. You activate it and are working in shortcut learning mode. You turn it off once you're done with assigning shortcuts.
Unfortunately, many people (like me) actually use them for dynamic shortcuts, and having to enable/disable it everytime you reassign keybindings makes the feature useless. Essentially the "dynamic" part of the feature got severly limited.
Sure, "if" you think that way it's fine... but not everybody thinks in statically assigned keybindings, I often reassign keys dynamically in vi or use macros, the same is true for gimp. Of course, I am not such a power user that gimp should be specifically re-written for my (possibly exceptional) taste.
While I don't understand *exactly* the issues, I am not arguing from the point of "the design is broken" but from a point of "a very useful feature now became rather limited". It might be possible that there is no current solution since mnemonics and dynamic shortcuts simply cannot be made to harmonize. I just wanted to say that it's a useful feature, and it *should* be supported. If it is dangerous to use or if it cannot be supported in the 1.2 way, so be it...
So simply turn on the preference and leave it enabled all the time. It's back to the 1.2 behavior, modulo the mnemonics clashing. Perhaps there should be a pref for disabling the mnemonics, but the defaults should stay as is.
-Yosh
Suggestions + Patch, Redo - Part 1
Hi,
writes:
Since the preferences toggle doesn't solve it at all, why do you call it a solution? Toggling it on does not work, as Sven said, as then mnemonics and dynamic shortcuts will clash.
Sorry, but I don't think that they clash. What makes you think they do? Of course you can construct a usage case where there are clashes but in general they don't clash. Sorry, I don't see your problem.
Sven
Suggestions + Patch, Redo - Part 1
On Mon, Jun 30, 2003 at 02:12:49PM +0200, Sven Neumann wrote:
Since the preferences toggle doesn't solve it at all, why do you call it a solution? Toggling it on does not work, as Sven said, as then mnemonics and dynamic shortcuts will clash.
Sorry, but I don't think that they clash. What makes you think they do?
Well, you made me think that by writing:
"Because [the dynamic shortcut feature] interferes badly with mnemonics, especially if these are used in the menus and we only just started to add them all over the place. This is also the reason why they are disabled by default in all GTK2 apps."
Of course you can construct a usage case where there are clashes but in general they don't clash. Sorry, I don't see your problem.
I have no problem, it's just that you said they are currently disabled because they "interfere badly". Sorry, I translated that as "clash", but still I don't understands why you first say it interferes badly and then say there is no problem...
As a user in this case, I am just confused. If you last say is that it works just fine then I have no problem at all, and this thread is immediately dead because I misundertsood you.... I am just confused at what you wrote about that feature two weeks ago.
Suggestions + Patch, Redo - Part 1
Hi,
writes:
Well, you made me think that by writing:
"Because [the dynamic shortcut feature] interferes badly with mnemonics, especially if these are used in the menus and we only just started to add them all over the place. This is also the reason why they are disabled by default in all GTK2 apps."
Of course you can construct a usage case where there are clashes but in general they don't clash. Sorry, I don't see your problem.
I have no problem, it's just that you said they are currently disabled because they "interfere badly". Sorry, I translated that as "clash", but still I don't understands why you first say it interferes badly and then say there is no problem...
I think I explained that the only problem is that you will most likely rebind your keybindings accidentally if you use mnemonics while Dynamic Keyboard Shortcuts are enabled.
As a user in this case, I am just confused. If you last say is that it works just fine then I have no problem at all, and this thread is immediately dead because I misundertsood you.... I am just confused at what you wrote about that feature two weeks ago.
You misunderstood me and it would certainly have helped if you had simply started 1.3, enabled Dynamic Keyboard Shortcuts and tried to use mnemonics to navigate the menus. I have the impression you didn't do that or you would have discovered what I was talking about.
It's not that we did this change without a lot of thought and discussion. We even had the dynamic keybindings enabled for quite some time although GTK2 disables it by default. It just turned out that it is too dangerous to have it enabled all the time.
Sven