Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[C R]

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 (caj...@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
>
> --
>   si...@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
>
___
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

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[Simon Budig]

C R (caj...@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

-- 
  si...@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

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[C R]

> 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
> --
>   si...@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
___
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

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[Simon Budig]

C R (caj...@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
-- 
  si...@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

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[C R]

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 

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[Jehan Pagès]

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

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[C R]

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
>> 

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[Jehan Pagès]

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

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[C R]

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
>
___
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:   

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[Jehan Pagès]

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
___
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

Re: [Gimp-developer] Plans to resolve hotkey conflicts?

[Alexandre Prokoudine]

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