RSS/Atom feed Twitter
Site is read-only, email is disabled

Plans to resolve hotkey conflicts?

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.

13 of 14 messages available
Toggle history

Please log in to manage your subscriptions.

Plans to resolve hotkey conflicts? C R 14 Dec 08:46
  Plans to resolve hotkey conflicts? Alexandre Prokoudine 14 Dec 09:14
   Plans to resolve hotkey conflicts? C R 14 Dec 10:10
    Plans to resolve hotkey conflicts? Jehan Pagès 17 Dec 04:37
     Plans to resolve hotkey conflicts? C R 17 Dec 11:30
      Plans to resolve hotkey conflicts? Jehan Pagès 17 Dec 11:53
       CABdJpS755N0742e27bc4eRfWjB... 17 Dec 12:42
        Plans to resolve hotkey conflicts? C R 17 Dec 12:42
         Plans to resolve hotkey conflicts? Simon Budig 18 Dec 16:11
          Plans to resolve hotkey conflicts? C R 18 Dec 17:43
           Plans to resolve hotkey conflicts? Simon Budig 18 Dec 17:59
            Plans to resolve hotkey conflicts? C R 18 Dec 18:16
      Plans to resolve hotkey conflicts? Jehan Pagès 17 Dec 13:26
       Plans to resolve hotkey conflicts? C R 17 Dec 13:49
C R
2016-12-14 08:46:35 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

If help is needed picking the best versions to keep, let me know. I'm happy to help in any way that I can. I assume the non-gegl based actions are going away soonish?

Thanks!

-C

Alexandre Prokoudine
2016-12-14 09:14:46 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

On Wed, Dec 14, 2016 at 11:46 AM, C R wrote:

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

Done three weeks ago:

https://git.gnome.org/browse/gimp/commit/?id=2a232398c4ad5a3108b5ad75be7bc8ef5d98e6fb

Alex

C R
2016-12-14 10:10:29 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

Thanks Alex.

And I'm still getting overlaping hotkeys with:

s - Hue/Saturation, Colourise e - Desaturate, Color Temperature
x - Exposure, Retinex

I'm running the gimp-edge repo. The current one is:
gimp 2.9.5~58-0y0~ppa~9f15ad6

It also seems there is a bug that forces the user to press the over arrow to access the hotkeys for sub-menus. For example, the key combination alt+c > e > d should call up the desaturate dialog, but the user must use this combination instead: alt+c > e > right arrow > d.

Is this possibly a GTK bug?

All the styling on the new menus looks great btw.

Thanks. -C

On Wed, Dec 14, 2016 at 9:14 AM, Alexandre Prokoudine wrote:

On Wed, Dec 14, 2016 at 11:46 AM, C R wrote:

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

Done three weeks ago:

https://git.gnome.org/browse/gimp/commit/?id=2a232398c4ad5a3108b5ad75be7bc8ef5d98e6fb

Alex _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

Jehan Pagès
2016-12-17 04:37:58 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

Hi,

On Wed, Dec 14, 2016 at 11:10 AM, C R wrote:

Thanks Alex.

And I'm still getting overlaping hotkeys with:

Ok so it seems you are talking of something different from what Alexandre linked. This commit was about duplicate shortcuts. You are talking about what GTK+ calls "mnemonics", which is this underlined character on menu items or buttons. This commit did indeed nothing related to mnemonics.

I don't really know what is the deal with mnemonics because that's a real mess by design. Indeed having duplicated mnemonics is hard to check since a same action can be used in various contexts (different menus, dialogs…). In one case, it may be fine, but in others, it won't.

I think I read someone saying that maybe GTK+ would be getting away from mnemonics in the long run but I can't find any actual reference to this (apart from the fact that it is not possible to see them by default in GTK+3 apparently, without pressing Alt). So I don't know.

s - Hue/Saturation, Colourise

That's another case which shows the problem with mnemonics: by default, the label is "Colori_ze" (with a mnemonic on 'z'), but the translator changed it to 's' (obviously you are using UK English). So there is no conflicts in US English, but there is one in UK English. This is too much of a burden on translators to be able to change mnemonics (so should they be expected to check every place where they are used, as well as developers?).

Anyway I don't really have good answers for you. You can try and open bug reports for the conflicts you find and we'll try to fix them. But we likely won't be 100% sure that we won't create new mnemonics conflicts somewhere else by fixing them in this specific menu. And the ones on translated strings will be even more annoying. Maybe we should ask translators to not change mnemonics even when the translation does not have the letter? (they would add a "(z)" at the end of the string. That's what they do in languages with indirect input like Japanese, though it could feel like a stepback for a lang such as UK English)

Jehan

e - Desaturate, Color Temperature x - Exposure, Retinex

I'm running the gimp-edge repo. The current one is:
gimp 2.9.5~58-0y0~ppa~9f15ad6

It also seems there is a bug that forces the user to press the over arrow to access the hotkeys for sub-menus. For example, the key combination alt+c > e > d should call up the desaturate dialog, but the user must use this combination instead: alt+c > e > right arrow > d.

Is this possibly a GTK bug? All the styling on the new menus looks great btw.

Thanks. -C

On Wed, Dec 14, 2016 at 9:14 AM, Alexandre Prokoudine wrote:

On Wed, Dec 14, 2016 at 11:46 AM, C R wrote:

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

Done three weeks ago:

https://git.gnome.org/browse/gimp/commit/?id=2a232398c4ad5a3108b5ad75be7bc8ef5d98e6fb

Alex _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
C R
2016-12-17 11:30:06 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

Thanks for the explanation. I don't imagine it's possible to avoid them all, however could you fix the ones I've highlighted? I guess a workaround would be to change to the American English version? Seems not a good solution.

Another fix would be to leave the mnemonics as they are, and just make it possible to hit the same letter twice to get to the next one. - This works the first time, but it switches which entry is highlighted each time the combination is used. If it were simply consistent each time I'd consider it a non-issue.

Can this behaviour be fixed?

Thanks. -C

On 17 Dec 2016 4:38 am, "Jehan Pagès" wrote:

Hi,

On Wed, Dec 14, 2016 at 11:10 AM, C R wrote:

Thanks Alex.

And I'm still getting overlaping hotkeys with:

Ok so it seems you are talking of something different from what Alexandre linked. This commit was about duplicate shortcuts. You are talking about what GTK+ calls "mnemonics", which is this underlined character on menu items or buttons. This commit did indeed nothing related to mnemonics.

I don't really know what is the deal with mnemonics because that's a real mess by design. Indeed having duplicated mnemonics is hard to check since a same action can be used in various contexts (different menus, dialogs…). In one case, it may be fine, but in others, it won't.

I think I read someone saying that maybe GTK+ would be getting away from mnemonics in the long run but I can't find any actual reference to this (apart from the fact that it is not possible to see them by default in GTK+3 apparently, without pressing Alt). So I don't know.

s - Hue/Saturation, Colourise

That's another case which shows the problem with mnemonics: by default, the label is "Colori_ze" (with a mnemonic on 'z'), but the translator changed it to 's' (obviously you are using UK English). So there is no conflicts in US English, but there is one in UK English. This is too much of a burden on translators to be able to change mnemonics (so should they be expected to check every place where they are used, as well as developers?).

Anyway I don't really have good answers for you. You can try and open bug reports for the conflicts you find and we'll try to fix them. But we likely won't be 100% sure that we won't create new mnemonics conflicts somewhere else by fixing them in this specific menu. And the ones on translated strings will be even more annoying. Maybe we should ask translators to not change mnemonics even when the translation does not have the letter? (they would add a "(z)" at the end of the string. That's what they do in languages with indirect input like Japanese, though it could feel like a stepback for a lang such as UK English)

Jehan

e - Desaturate, Color Temperature x - Exposure, Retinex

I'm running the gimp-edge repo. The current one is:
gimp 2.9.5~58-0y0~ppa~9f15ad6

It also seems there is a bug that forces the user to press the over arrow to access the hotkeys for sub-menus. For example, the key combination alt+c > e > d should call up the desaturate dialog, but the user must use this combination instead: alt+c > e > right arrow > d.

Is this possibly a GTK bug? All the styling on the new menus looks great btw.

Thanks. -C

On Wed, Dec 14, 2016 at 9:14 AM, Alexandre Prokoudine wrote:

On Wed, Dec 14, 2016 at 11:46 AM, C R wrote:

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

Done three weeks ago:

https://git.gnome.org/browse/gimp/commit/?id=

2a232398c4ad5a3108b5ad75be7bc8ef5d98e6fb

Alex
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-

developer-list

List archives: https://mail.gnome.org/archives/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-

developer-list

List archives: https://mail.gnome.org/archives/gimp-developer-list

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot

Jehan Pagès
2016-12-17 11:53:40 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

Hi,

On Sat, Dec 17, 2016 at 12:30 PM, C R wrote:

Thanks for the explanation. I don't imagine it's possible to avoid them all, however could you fix the ones I've highlighted? I guess a workaround would be to change to the American English version? Seems not a good solution.

Another fix would be to leave the mnemonics as they are, and just make it possible to hit the same letter twice to get to the next one. - This works the first time, but it switches which entry is highlighted each time the combination is used. If it were simply consistent each time I'd consider it a non-issue.

I think this would be the better fix. But then what of this case: - 'a' is mnemonic for 'submenu 1'
- 'a' is mnemonic for 'item 1' under 'submenu 1' - 'a' is mnemonic for 'item 2' (same level as submenu 1)

Hitting 'a' highlight 'submenu 1'. Should hitting again 'a' highlight 'item 2' on the same level or enter inside 'submenu 1' and highlight 'item 1'?
Of course, if hitting right arrow is mandatory to go inside the submenu, that's not a problem, but since you felt it was a problem earlier, I just wanted to raise the issue.

Second issue is that you usually want to have an item be directly run (and not just highlighted) when it is a finale item. Otherwise should we also hit Enter to activate?

Can this behaviour be fixed?

Everything can be done, but since that's in GTK+:

- GTK+ devs must agree with the change of behavior. - This cannot be for GIMP 2.10 because GTK+ is stable and don't accept new features/change of behavior. Also GTK+3 itself just went stable so that means it probably won't be doable for GIMP 3 even.

Jehan

Thanks.
-C

On 17 Dec 2016 4:38 am, "Jehan Pagès" wrote:

Hi,

On Wed, Dec 14, 2016 at 11:10 AM, C R wrote:

Thanks Alex.

And I'm still getting overlaping hotkeys with:

Ok so it seems you are talking of something different from what Alexandre linked. This commit was about duplicate shortcuts. You are talking about what GTK+ calls "mnemonics", which is this underlined character on menu items or buttons. This commit did indeed nothing related to mnemonics.

I don't really know what is the deal with mnemonics because that's a real mess by design. Indeed having duplicated mnemonics is hard to check since a same action can be used in various contexts (different menus, dialogs…). In one case, it may be fine, but in others, it won't.

I think I read someone saying that maybe GTK+ would be getting away from mnemonics in the long run but I can't find any actual reference to this (apart from the fact that it is not possible to see them by default in GTK+3 apparently, without pressing Alt). So I don't know.

s - Hue/Saturation, Colourise

That's another case which shows the problem with mnemonics: by default, the label is "Colori_ze" (with a mnemonic on 'z'), but the translator changed it to 's' (obviously you are using UK English). So there is no conflicts in US English, but there is one in UK English. This is too much of a burden on translators to be able to change mnemonics (so should they be expected to check every place where they are used, as well as developers?).

Anyway I don't really have good answers for you. You can try and open bug reports for the conflicts you find and we'll try to fix them. But we likely won't be 100% sure that we won't create new mnemonics conflicts somewhere else by fixing them in this specific menu. And the ones on translated strings will be even more annoying. Maybe we should ask translators to not change mnemonics even when the translation does not have the letter? (they would add a "(z)" at the end of the string. That's what they do in languages with indirect input like Japanese, though it could feel like a stepback for a lang such as UK English)

Jehan

e - Desaturate, Color Temperature x - Exposure, Retinex

I'm running the gimp-edge repo. The current one is:
gimp 2.9.5~58-0y0~ppa~9f15ad6

It also seems there is a bug that forces the user to press the over arrow to access the hotkeys for sub-menus. For example, the key combination alt+c > e > d should call up the desaturate dialog, but the user must use this combination instead: alt+c > e > right arrow > d.

Is this possibly a GTK bug? All the styling on the new menus looks great btw.

Thanks. -C

On Wed, Dec 14, 2016 at 9:14 AM, Alexandre Prokoudine wrote:

On Wed, Dec 14, 2016 at 11:46 AM, C R wrote:

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

Done three weeks ago:

https://git.gnome.org/browse/gimp/commit/?id=2a232398c4ad5a3108b5ad75be7bc8ef5d98e6fb

Alex _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot

ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
C R
2016-12-17 12:42:42 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

I mean, I really don't care as long as it's consistent, and it never has been in the past, for as long as I have used GIMP.

I should be able to hit a sequence of hotkeys to get to sub menu items, and doing it again should get me to the same function each and every time I perform them.

Reducing the number of hotkeys necessary to do each action would be nice, but I'll take consistency over less keys any day because it takes longer to see and figure out which overlaping mnemonic gtk decided to randomly choose this time. It may seem like a small thing but it's really crippling to workflow.

Thanks for your help. -C

I think this would be the better fix. But then what of this case: - 'a' is mnemonic for 'submenu 1'
- 'a' is mnemonic for 'item 1' under 'submenu 1' - 'a' is mnemonic for 'item 2' (same level as submenu 1)

Hitting 'a' highlight 'submenu 1'. Should hitting again 'a' highlight 'item 2' on the same level or enter inside 'submenu 1' and highlight 'item 1'?
Of course, if hitting right arrow is mandatory to go inside the submenu, that's not a problem, but since you felt it was a problem earlier, I just wanted to raise the issue.

Second issue is that you usually want to have an item be directly run (and not just highlighted) when it is a finale item. Otherwise should we also hit Enter to activate?

Can this behaviour be fixed?

Everything can be done, but since that's in GTK+:

- GTK+ devs must agree with the change of behavior. - This cannot be for GIMP 2.10 because GTK+ is stable and don't accept new features/change of behavior. Also GTK+3 itself just went stable so that means it probably won't be doable for GIMP 3 even.

Jehan

Thanks.
-C

On 17 Dec 2016 4:38 am, "Jehan Pagès" wrote:

Hi,

On Wed, Dec 14, 2016 at 11:10 AM, C R wrote:

Thanks Alex.

And I'm still getting overlaping hotkeys with:

Ok so it seems you are talking of something different from what Alexandre linked. This commit was about duplicate shortcuts. You are talking about what GTK+ calls "mnemonics", which is this underlined character on menu items or buttons. This commit did indeed nothing related to mnemonics.

I don't really know what is the deal with mnemonics because that's a real mess by design. Indeed having duplicated mnemonics is hard to check since a same action can be used in various contexts (different menus, dialogs…). In one case, it may be fine, but in others, it won't.

I think I read someone saying that maybe GTK+ would be getting away from mnemonics in the long run but I can't find any actual reference to this (apart from the fact that it is not possible to see them by default in GTK+3 apparently, without pressing Alt). So I don't know.

s - Hue/Saturation, Colourise

That's another case which shows the problem with mnemonics: by default, the label is "Colori_ze" (with a mnemonic on 'z'), but the translator changed it to 's' (obviously you are using UK English). So there is no conflicts in US English, but there is one in UK English. This is too much of a burden on translators to be able to change mnemonics (so should they be expected to check every place where they are used, as well as developers?).

Anyway I don't really have good answers for you. You can try and open bug reports for the conflicts you find and we'll try to fix them. But we likely won't be 100% sure that we won't create new mnemonics conflicts somewhere else by fixing them in this specific menu. And the ones on translated strings will be even more annoying. Maybe we should ask translators to not change mnemonics even when the translation does not have the letter? (they would add a "(z)" at the end of the string. That's what they do in languages with indirect input like Japanese, though it could feel like a stepback for a lang such as UK English)

Jehan

e - Desaturate, Color Temperature x - Exposure, Retinex

I'm running the gimp-edge repo. The current one is:
gimp 2.9.5~58-0y0~ppa~9f15ad6

It also seems there is a bug that forces the user to press the over arrow to access the hotkeys for sub-menus. For example, the key combination alt+c > e > d should call up the desaturate dialog, but the user must use this combination instead: alt+c > e > right arrow > d.

Is this possibly a GTK bug? All the styling on the new menus looks great btw.

Thanks. -C

On Wed, Dec 14, 2016 at 9:14 AM, Alexandre Prokoudine wrote:

On Wed, Dec 14, 2016 at 11:46 AM, C R wrote:

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

Done three weeks ago:

https://git.gnome.org/browse/gimp/commit/?id=

2a232398c4ad5a3108b5ad75be7bc8ef5d98e6fb

Alex
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot

Jehan Pagès
2016-12-17 13:26:46 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

By the way,

On Sat, Dec 17, 2016 at 12:30 PM, C R wrote:

however could you fix the ones I've highlighted?

You should open bug reports. I don't have time (or the will) to do this just now, and I will have forgotten about this in a few hours (and in a few days, this email will be lost in the bottom of my mailbox).
If you want bugs to leave a trace and not be forgotten, you should open bug reports. They can then also be dealt by other developers (not only me) later on so you improve chances of seeing this being taken care of.

Thanks.

Jehan

Thanks.
-C

On 17 Dec 2016 4:38 am, "Jehan Pagès" wrote:

Hi,

On Wed, Dec 14, 2016 at 11:10 AM, C R wrote:

Thanks Alex.

And I'm still getting overlaping hotkeys with:

Ok so it seems you are talking of something different from what Alexandre linked. This commit was about duplicate shortcuts. You are talking about what GTK+ calls "mnemonics", which is this underlined character on menu items or buttons. This commit did indeed nothing related to mnemonics.

I don't really know what is the deal with mnemonics because that's a real mess by design. Indeed having duplicated mnemonics is hard to check since a same action can be used in various contexts (different menus, dialogs…). In one case, it may be fine, but in others, it won't.

I think I read someone saying that maybe GTK+ would be getting away from mnemonics in the long run but I can't find any actual reference to this (apart from the fact that it is not possible to see them by default in GTK+3 apparently, without pressing Alt). So I don't know.

s - Hue/Saturation, Colourise

That's another case which shows the problem with mnemonics: by default, the label is "Colori_ze" (with a mnemonic on 'z'), but the translator changed it to 's' (obviously you are using UK English). So there is no conflicts in US English, but there is one in UK English. This is too much of a burden on translators to be able to change mnemonics (so should they be expected to check every place where they are used, as well as developers?).

Anyway I don't really have good answers for you. You can try and open bug reports for the conflicts you find and we'll try to fix them. But we likely won't be 100% sure that we won't create new mnemonics conflicts somewhere else by fixing them in this specific menu. And the ones on translated strings will be even more annoying. Maybe we should ask translators to not change mnemonics even when the translation does not have the letter? (they would add a "(z)" at the end of the string. That's what they do in languages with indirect input like Japanese, though it could feel like a stepback for a lang such as UK English)

Jehan

e - Desaturate, Color Temperature x - Exposure, Retinex

I'm running the gimp-edge repo. The current one is:
gimp 2.9.5~58-0y0~ppa~9f15ad6

It also seems there is a bug that forces the user to press the over arrow to access the hotkeys for sub-menus. For example, the key combination alt+c > e > d should call up the desaturate dialog, but the user must use this combination instead: alt+c > e > right arrow > d.

Is this possibly a GTK bug? All the styling on the new menus looks great btw.

Thanks. -C

On Wed, Dec 14, 2016 at 9:14 AM, Alexandre Prokoudine wrote:

On Wed, Dec 14, 2016 at 11:46 AM, C R wrote:

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

Done three weeks ago:

https://git.gnome.org/browse/gimp/commit/?id=2a232398c4ad5a3108b5ad75be7bc8ef5d98e6fb

Alex _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot

ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
C R
2016-12-17 13:49:35 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

I will, I was just hoping it might be a quick fix. Thanks.
-C

On 17 Dec 2016 1:27 pm, "Jehan Pagès" wrote:

By the way,

On Sat, Dec 17, 2016 at 12:30 PM, C R wrote:

however could you fix the ones I've highlighted?

You should open bug reports. I don't have time (or the will) to do this just now, and I will have forgotten about this in a few hours (and in a few days, this email will be lost in the bottom of my mailbox).
If you want bugs to leave a trace and not be forgotten, you should open bug reports. They can then also be dealt by other developers (not only me) later on so you improve chances of seeing this being taken care of.

Thanks.

Jehan

Thanks.
-C

On 17 Dec 2016 4:38 am, "Jehan Pagès"

wrote:

Hi,

On Wed, Dec 14, 2016 at 11:10 AM, C R wrote:

Thanks Alex.

And I'm still getting overlaping hotkeys with:

Ok so it seems you are talking of something different from what Alexandre linked. This commit was about duplicate shortcuts. You are talking about what GTK+ calls "mnemonics", which is this underlined character on menu items or buttons. This commit did indeed nothing related to mnemonics.

I don't really know what is the deal with mnemonics because that's a real mess by design. Indeed having duplicated mnemonics is hard to check since a same action can be used in various contexts (different menus, dialogs…). In one case, it may be fine, but in others, it won't.

I think I read someone saying that maybe GTK+ would be getting away from mnemonics in the long run but I can't find any actual reference to this (apart from the fact that it is not possible to see them by default in GTK+3 apparently, without pressing Alt). So I don't know.

s - Hue/Saturation, Colourise

That's another case which shows the problem with mnemonics: by default, the label is "Colori_ze" (with a mnemonic on 'z'), but the translator changed it to 's' (obviously you are using UK English). So there is no conflicts in US English, but there is one in UK English. This is too much of a burden on translators to be able to change mnemonics (so should they be expected to check every place where they are used, as well as developers?).

Anyway I don't really have good answers for you. You can try and open bug reports for the conflicts you find and we'll try to fix them. But we likely won't be 100% sure that we won't create new mnemonics conflicts somewhere else by fixing them in this specific menu. And the ones on translated strings will be even more annoying. Maybe we should ask translators to not change mnemonics even when the translation does not have the letter? (they would add a "(z)" at the end of the string. That's what they do in languages with indirect input like Japanese, though it could feel like a stepback for a lang such as UK English)

Jehan

e - Desaturate, Color Temperature x - Exposure, Retinex

I'm running the gimp-edge repo. The current one is:
gimp 2.9.5~58-0y0~ppa~9f15ad6

It also seems there is a bug that forces the user to press the over arrow to access the hotkeys for sub-menus. For example, the key combination alt+c > e > d should call up the desaturate dialog, but the user must use this combination instead: alt+c > e > right arrow > d.

Is this possibly a GTK bug? All the styling on the new menus looks great btw.

Thanks. -C

On Wed, Dec 14, 2016 at 9:14 AM, Alexandre Prokoudine wrote:

On Wed, Dec 14, 2016 at 11:46 AM, C R wrote:

The Colour menu has again become a mess of conflicting hotkeys. Can someone reassign/resolve them?

Probably a good idea to get rid of some of the duplicate functions like "drop shadow" and the proliferation of duplicate desaturate actions. :)

Done three weeks ago:

https://git.gnome.org/browse/gimp/commit/?id=

2a232398c4ad5a3108b5ad75be7bc8ef5d98e6fb

Alex
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot

Simon Budig
2016-12-18 16:11:09 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

C R (cajhne@gmail.com) wrote:

I should be able to hit a sequence of hotkeys to get to sub menu items, and doing it again should get me to the same function each and every time I perform them.

Uh. In what way isn't that the case currently?

GTK+ cycles through all the "conflicting" mnemonics. So (for british english) ALT-C, s, s consistently brings you to "Colouri_se".

I usually don't use the mnemonic-based menu navigation, so I might be missing something...

Bye,
Simon

simon@budig.de              http://simon.budig.de/
C R
2016-12-18 17:43:00 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

Uh. In what way isn't that the case currently?

Try Alt-C, s for hue/saturation
Then try it again after you complete the hue saturation action On the second run alt-C, s skips to Colourise

Thanks. -C

GTK+ cycles through all the "conflicting" mnemonics. So (for british english) ALT-C, s, s consistently brings you to "Colouri_se".

I usually don't use the mnemonic-based menu navigation, so I might be missing something...

Bye,
Simon
--
simon@budig.de http://simon.budig.de/ _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

Simon Budig
2016-12-18 17:59:42 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

C R (cajhne@gmail.com) wrote:

Uh. In what way isn't that the case currently?

Try Alt-C, s for hue/saturation
Then try it again after you complete the hue saturation action On the second run alt-C, s skips to Colourise

Oh, indeed. That feels stupid.

Bye, Simon

simon@budig.de              http://simon.budig.de/
C R
2016-12-18 18:16:21 UTC (almost 8 years ago)

Plans to resolve hotkey conflicts?

It's been like that for ages. I'll go ahead and file a bug report, if no one wants to fix it, or can't quickly.

Thanks. -C

On 18 Dec 2016 6:12 pm, "Simon Budig" wrote:

C R (cajhne@gmail.com) wrote:

Uh. In what way isn't that the case currently?

Try Alt-C, s for hue/saturation
Then try it again after you complete the hue saturation action On the second run alt-C, s skips to Colourise

Oh, indeed. That feels stupid.

Bye, Simon

--
simon@budig.de http://simon.budig.de/ _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp- developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list