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

2016-12-17 Thread 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:   https://mail.gnome.org/archives/gimp-developer-list


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

2016-12-17 Thread 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
>> >>> actions. :)
>> >>
>> >> Done three weeks ago:
>> >>
>> >>
>> >> https://git.gnome.org/brow

[Gimp-developer] Unsuscribe

2016-12-17 Thread Will Gmail
Hello,
Could you unsuscribe me from this list please ?
Thx
___
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?

2016-12-17 Thread 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
>> >>> actions. :)
>> >>
>> >> Done three weeks ago:
>> >>
>> >>
>> >> https://gi

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

2016-12-17 Thread 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
___
gimp-developer-list mailing list
List address:gimp-develope

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

2016-12-17 Thread 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 archives:   https://mail.gnome.org/archives/gimp-developer-list
> >>
> >>
> >>
> >> --
> >> ZeMarmot open animation film
> >> ht

Re: [Gimp-developer] Unsuscribe

2016-12-17 Thread Shlomi Fish
Hi Will!

On Sat, 17 Dec 2016 12:07:33 +
Will Gmail  wrote:

> Hello,
> Could you unsuscribe me from this list please ?
> Thx

Please see https://mail.gnome.org/mailman/listinfo/gimp-developer-list - it's
in the footer of every post to the 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



-- 
-
Shlomi Fish   http://www.shlomifish.org/
http://shlomifishswiki.branchable.com/Self-Sufficiency/

Because you can't just make shit up and expect the computer to magically know
what you mean, Retardo!
— Mark Jason Dominus, http://perl.plover.com/Questions4.html

Please reply to list if it's a mailing list post - http://shlom.in/reply .
___
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