Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-09-18 Thread Wayne Stambaugh 
Ian,

I merged your patch into master.

Thanks,

Wayne

On 9/18/19 1:04 PM, Jeff Young wrote:
> +1
> 
> 
>> On 18 Sep 2019, at 14:25, Wayne Stambaugh > > wrote:
>>
>> I think we should merge it.  I tested it on a new config and my crufty
>> old config and it seems to work as expected.  There may be some issues
>> for users with multiple actions defined to the same key but that should
>> be a simple matter of having them reset their key assignment to the
>> default.  If there are no objections, I have this queued up and ready to
>> merge.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 9/18/19 4:13 AM, Ian McInerney wrote:
>>> What do we want to do with this patch?
>>>
>>> -Ian
>>>
>>> On Fri, Sep 6, 2019 at 1:23 AM Seth Hillbrand >> 
>>> > wrote:
>>>
>>>    Wow, this bug has been a real annoyance for some time.  Thank you for
>>>    tracking down the origin.
>>>
>>>    I've tested Ian's patch and it works correctly.  Allows the 'P' hotkey
>>>    to correctly trigger the Place Power action in eeschema and the Create
>>>    Pin action in LibEdit.  Tested with individual applications as well as
>>>    with both applications running at the same time.
>>>
>>>    Note, however, that when we edit the hotkeys in preferences, no such
>>>    testing of whether a hotkey is handled takes place and we simply
>>> show a
>>>    warning that the 'P' hotkey is bound to two separate actions.  I'm not
>>>    sure what the course of action here could be other than to separate
>>>    testing of the hotkey overlap between applications.
>>>
>>>    -Seth
>>>
>>>    On 2019-09-05 17:21, Ian McInerney wrote:
 This somehow got lost in my email, but I have now found a case where
 this
 is needed in the "wild" (the master branch). For bug
 https://bugs.launchpad.net/kicad/+bug/1834547, it appears that on
>>>    Linux
 the
 hotkey architecture is trying to run the action for place symbol pin
 instead of the place power action. These two actions are never active
 on
 the same editing session, so it is a valid configuration. Applying
>>>    this
 patch fixes the behavior, and the place power symbol action is
>>>    actually
 called.

 -Ian

 On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh
>>>    >>  >
 wrote:

> What is the status of this patch?
>
> Cheers,
>
> Wayne
>
> On 8/8/19 7:16 PM, Ian McInerney wrote:
>> In the current framework, if more than one global actions share
>>>    the same
>> hotkey (even if they are not all active in the current tool
>>>    manager),
>> the dispatcher will only choose the final action (in what seems
>>>    to be
>> alphabetical order) to run. I think that the correct behavior
>>>    should
>> instead be to loop through all global actions that have the
>>>    hotkey until
>> one handles it.
>>
>> The attached patch implements this change.
>>
>> -Ian
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@lists.launchpad.net
>> 
>>>    
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
>>>    
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to     : kicad-developers@lists.launchpad.net
 
>>>    
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-09-18 Thread Jeff Young 
+1


> On 18 Sep 2019, at 14:25, Wayne Stambaugh  wrote:
> 
> I think we should merge it.  I tested it on a new config and my crufty
> old config and it seems to work as expected.  There may be some issues
> for users with multiple actions defined to the same key but that should
> be a simple matter of having them reset their key assignment to the
> default.  If there are no objections, I have this queued up and ready to
> merge.
> 
> Cheers,
> 
> Wayne
> 
> On 9/18/19 4:13 AM, Ian McInerney wrote:
>> What do we want to do with this patch?
>> 
>> -Ian
>> 
>> On Fri, Sep 6, 2019 at 1:23 AM Seth Hillbrand > 
>> >> wrote:
>> 
>>Wow, this bug has been a real annoyance for some time.  Thank you for
>>tracking down the origin.
>> 
>>I've tested Ian's patch and it works correctly.  Allows the 'P' hotkey
>>to correctly trigger the Place Power action in eeschema and the Create
>>Pin action in LibEdit.  Tested with individual applications as well as
>>with both applications running at the same time.
>> 
>>Note, however, that when we edit the hotkeys in preferences, no such
>>testing of whether a hotkey is handled takes place and we simply show a
>>warning that the 'P' hotkey is bound to two separate actions.  I'm not
>>sure what the course of action here could be other than to separate
>>testing of the hotkey overlap between applications.
>> 
>>-Seth
>> 
>>On 2019-09-05 17:21, Ian McInerney wrote:
>>> This somehow got lost in my email, but I have now found a case where
>>> this
>>> is needed in the "wild" (the master branch). For bug
>>> https://bugs.launchpad.net/kicad/+bug/1834547 
>>> , it appears that on
>>Linux
>>> the
>>> hotkey architecture is trying to run the action for place symbol pin
>>> instead of the place power action. These two actions are never active
>>> on
>>> the same editing session, so it is a valid configuration. Applying
>>this
>>> patch fixes the behavior, and the place power symbol action is
>>actually
>>> called.
>>> 
>>> -Ian
>>> 
>>> On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh
>>mailto:stambau...@gmail.com> 
>> >>
>>> wrote:
>>> 
 What is the status of this patch?
 
 Cheers,
 
 Wayne
 
 On 8/8/19 7:16 PM, Ian McInerney wrote:
> In the current framework, if more than one global actions share
>>the same
> hotkey (even if they are not all active in the current tool
>>manager),
> the dispatcher will only choose the final action (in what seems
>>to be
> alphabetical order) to run. I think that the correct behavior
>>should
> instead be to loop through all global actions that have the
>>hotkey until
> one handles it.
> 
> The attached patch implements this change.
> 
> -Ian
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
>>> >
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 
 Post to : kicad-developers@lists.launchpad.net 
 
>>> >
 Unsubscribe : https://launchpad.net/~kicad-developers 
 
 More help   : https://help.launchpad.net/ListHelp 
 
 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> 
>>> Post to : kicad-developers@lists.launchpad.net 
>>> 
>>> >
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://la

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-09-18 Thread Wayne Stambaugh 
I think we should merge it.  I tested it on a new config and my crufty
old config and it seems to work as expected.  There may be some issues
for users with multiple actions defined to the same key but that should
be a simple matter of having them reset their key assignment to the
default.  If there are no objections, I have this queued up and ready to
merge.

Cheers,

Wayne

On 9/18/19 4:13 AM, Ian McInerney wrote:
> What do we want to do with this patch?
> 
> -Ian
> 
> On Fri, Sep 6, 2019 at 1:23 AM Seth Hillbrand  > wrote:
> 
> Wow, this bug has been a real annoyance for some time.  Thank you for
> tracking down the origin.
> 
> I've tested Ian's patch and it works correctly.  Allows the 'P' hotkey
> to correctly trigger the Place Power action in eeschema and the Create
> Pin action in LibEdit.  Tested with individual applications as well as
> with both applications running at the same time.
> 
> Note, however, that when we edit the hotkeys in preferences, no such
> testing of whether a hotkey is handled takes place and we simply show a
> warning that the 'P' hotkey is bound to two separate actions.  I'm not
> sure what the course of action here could be other than to separate
> testing of the hotkey overlap between applications.
> 
> -Seth
> 
> On 2019-09-05 17:21, Ian McInerney wrote:
> > This somehow got lost in my email, but I have now found a case where
> > this
> > is needed in the "wild" (the master branch). For bug
> > https://bugs.launchpad.net/kicad/+bug/1834547, it appears that on
> Linux
> > the
> > hotkey architecture is trying to run the action for place symbol pin
> > instead of the place power action. These two actions are never active
> > on
> > the same editing session, so it is a valid configuration. Applying
> this
> > patch fixes the behavior, and the place power symbol action is
> actually
> > called.
> >
> > -Ian
> >
> > On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>>
> > wrote:
> >
> >> What is the status of this patch?
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 8/8/19 7:16 PM, Ian McInerney wrote:
> >> > In the current framework, if more than one global actions share
> the same
> >> > hotkey (even if they are not all active in the current tool
> manager),
> >> > the dispatcher will only choose the final action (in what seems
> to be
> >> > alphabetical order) to run. I think that the correct behavior
> should
> >> > instead be to loop through all global actions that have the
> hotkey until
> >> > one handles it.
> >> >
> >> > The attached patch implements this change.
> >> >
> >> > -Ian
> >> >
> >> > ___
> >> > Mailing list: https://launchpad.net/~kicad-developers
> >> > Post to     : kicad-developers@lists.launchpad.net
> 
> >> > Unsubscribe : https://launchpad.net/~kicad-developers
> >> > More help   : https://help.launchpad.net/ListHelp
> >> >
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@lists.launchpad.net
> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-09-18 Thread Ian McInerney 
What do we want to do with this patch?

-Ian

On Fri, Sep 6, 2019 at 1:23 AM Seth Hillbrand  wrote:

> Wow, this bug has been a real annoyance for some time.  Thank you for
> tracking down the origin.
>
> I've tested Ian's patch and it works correctly.  Allows the 'P' hotkey
> to correctly trigger the Place Power action in eeschema and the Create
> Pin action in LibEdit.  Tested with individual applications as well as
> with both applications running at the same time.
>
> Note, however, that when we edit the hotkeys in preferences, no such
> testing of whether a hotkey is handled takes place and we simply show a
> warning that the 'P' hotkey is bound to two separate actions.  I'm not
> sure what the course of action here could be other than to separate
> testing of the hotkey overlap between applications.
>
> -Seth
>
> On 2019-09-05 17:21, Ian McInerney wrote:
> > This somehow got lost in my email, but I have now found a case where
> > this
> > is needed in the "wild" (the master branch). For bug
> > https://bugs.launchpad.net/kicad/+bug/1834547, it appears that on Linux
> > the
> > hotkey architecture is trying to run the action for place symbol pin
> > instead of the place power action. These two actions are never active
> > on
> > the same editing session, so it is a valid configuration. Applying this
> > patch fixes the behavior, and the place power symbol action is actually
> > called.
> >
> > -Ian
> >
> > On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh 
> > wrote:
> >
> >> What is the status of this patch?
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 8/8/19 7:16 PM, Ian McInerney wrote:
> >> > In the current framework, if more than one global actions share the
> same
> >> > hotkey (even if they are not all active in the current tool manager),
> >> > the dispatcher will only choose the final action (in what seems to be
> >> > alphabetical order) to run. I think that the correct behavior should
> >> > instead be to loop through all global actions that have the hotkey
> until
> >> > one handles it.
> >> >
> >> > The attached patch implements this change.
> >> >
> >> > -Ian
> >> >
> >> > ___
> >> > Mailing list: https://launchpad.net/~kicad-developers
> >> > Post to : kicad-developers@lists.launchpad.net
> >> > Unsubscribe : https://launchpad.net/~kicad-developers
> >> > More help   : https://help.launchpad.net/ListHelp
> >> >
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-09-05 Thread Seth Hillbrand 
Wow, this bug has been a real annoyance for some time.  Thank you for 
tracking down the origin.


I've tested Ian's patch and it works correctly.  Allows the 'P' hotkey 
to correctly trigger the Place Power action in eeschema and the Create 
Pin action in LibEdit.  Tested with individual applications as well as 
with both applications running at the same time.


Note, however, that when we edit the hotkeys in preferences, no such 
testing of whether a hotkey is handled takes place and we simply show a 
warning that the 'P' hotkey is bound to two separate actions.  I'm not 
sure what the course of action here could be other than to separate 
testing of the hotkey overlap between applications.


-Seth

On 2019-09-05 17:21, Ian McInerney wrote:
This somehow got lost in my email, but I have now found a case where 
this

is needed in the "wild" (the master branch). For bug
https://bugs.launchpad.net/kicad/+bug/1834547, it appears that on Linux 
the

hotkey architecture is trying to run the action for place symbol pin
instead of the place power action. These two actions are never active 
on

the same editing session, so it is a valid configuration. Applying this
patch fixes the behavior, and the place power symbol action is actually
called.

-Ian

On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh 
wrote:


What is the status of this patch?

Cheers,

Wayne

On 8/8/19 7:16 PM, Ian McInerney wrote:
> In the current framework, if more than one global actions share the same
> hotkey (even if they are not all active in the current tool manager),
> the dispatcher will only choose the final action (in what seems to be
> alphabetical order) to run. I think that the correct behavior should
> instead be to loop through all global actions that have the hotkey until
> one handles it.
>
> The attached patch implements this change.
>
> -Ian
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-09-05 Thread Ian McInerney 
This somehow got lost in my email, but I have now found a case where this
is needed in the "wild" (the master branch). For bug
https://bugs.launchpad.net/kicad/+bug/1834547, it appears that on Linux the
hotkey architecture is trying to run the action for place symbol pin
instead of the place power action. These two actions are never active on
the same editing session, so it is a valid configuration. Applying this
patch fixes the behavior, and the place power symbol action is actually
called.

-Ian

On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh 
wrote:

> What is the status of this patch?
>
> Cheers,
>
> Wayne
>
> On 8/8/19 7:16 PM, Ian McInerney wrote:
> > In the current framework, if more than one global actions share the same
> > hotkey (even if they are not all active in the current tool manager),
> > the dispatcher will only choose the final action (in what seems to be
> > alphabetical order) to run. I think that the correct behavior should
> > instead be to loop through all global actions that have the hotkey until
> > one handles it.
> >
> > The attached patch implements this change.
> >
> > -Ian
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-08-12 Thread Wayne Stambaugh 
What is the status of this patch?

Cheers,

Wayne

On 8/8/19 7:16 PM, Ian McInerney wrote:
> In the current framework, if more than one global actions share the same
> hotkey (even if they are not all active in the current tool manager),
> the dispatcher will only choose the final action (in what seems to be
> alphabetical order) to run. I think that the correct behavior should
> instead be to loop through all global actions that have the hotkey until
> one handles it.
> 
> The attached patch implements this change.
> 
> -Ian
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-08-09 Thread Wayne Stambaugh 
I might be more useful to trigger an assertion when there are
conflicting actions for the same hotkey.  Maybe I'm wrong but I would
think this could cause some serious issues and should be flagged as a
developer error rather than try to work around the issue.

On 8/9/19 11:24 AM, Ian McInerney wrote:
> Orson,
> 
> An invalid configuration should be when there are two active global
> actions that share the same hotkey, or if there are two actions in the
> same context that share the same hotkey.
> 
> The issue that I was having when I made this patch was that in my cvpcb
> actions rework, I not only was getting the cvpcb-specific actions I
> wanted, but was also getting the pcbnew actions. I did track that down
> to the fact that the pcb_actions.cpp file was being included in the
> cvpcb kiface, and I was able to remove that since it is no longer used
> by the footprint display frame. So this patch isn't critical to my needs
> anymore.
> 
> However, I think it may still be useful to make this change in the
> processing.
> 
> -Ian
> 
> On Fri, Aug 9, 2019 at 12:33 PM Maciej Suminski  > wrote:
> 
> Hi Ian,
> 
> I have nothing against your patch, but is it a valid configuration where
> one has multiple global actions bound to the same hot key?
> 
> Cheers,
> Orson
> 
> On 8/9/19 1:16 AM, Ian McInerney wrote:
> > In the current framework, if more than one global actions share
> the same
> > hotkey (even if they are not all active in the current tool manager),
> > the dispatcher will only choose the final action (in what seems to be
> > alphabetical order) to run. I think that the correct behavior should
> > instead be to loop through all global actions that have the hotkey
> until
> > one handles it.
> >
> > The attached patch implements this change.
> >
> > -Ian
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-08-09 Thread Ian McInerney 
Orson,

An invalid configuration should be when there are two active global actions
that share the same hotkey, or if there are two actions in the same context
that share the same hotkey.

The issue that I was having when I made this patch was that in my cvpcb
actions rework, I not only was getting the cvpcb-specific actions I wanted,
but was also getting the pcbnew actions. I did track that down to the fact
that the pcb_actions.cpp file was being included in the cvpcb kiface, and I
was able to remove that since it is no longer used by the footprint display
frame. So this patch isn't critical to my needs anymore.

However, I think it may still be useful to make this change in the
processing.

-Ian

On Fri, Aug 9, 2019 at 12:33 PM Maciej Suminski 
wrote:

> Hi Ian,
>
> I have nothing against your patch, but is it a valid configuration where
> one has multiple global actions bound to the same hot key?
>
> Cheers,
> Orson
>
> On 8/9/19 1:16 AM, Ian McInerney wrote:
> > In the current framework, if more than one global actions share the same
> > hotkey (even if they are not all active in the current tool manager),
> > the dispatcher will only choose the final action (in what seems to be
> > alphabetical order) to run. I think that the correct behavior should
> > instead be to loop through all global actions that have the hotkey until
> > one handles it.
> >
> > The attached patch implements this change.
> >
> > -Ian
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Another hotkey processing fix

2019-08-09 Thread Maciej Suminski 
Hi Ian,

I have nothing against your patch, but is it a valid configuration where
one has multiple global actions bound to the same hot key?

Cheers,
Orson

On 8/9/19 1:16 AM, Ian McInerney wrote:
> In the current framework, if more than one global actions share the same
> hotkey (even if they are not all active in the current tool manager),
> the dispatcher will only choose the final action (in what seems to be
> alphabetical order) to run. I think that the correct behavior should
> instead be to loop through all global actions that have the hotkey until
> one handles it.
> 
> The attached patch implements this change.
> 
> -Ian
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [Patch] Another hotkey processing fix

2019-08-08 Thread Ian McInerney 
In the current framework, if more than one global actions share the same
hotkey (even if they are not all active in the current tool manager), the
dispatcher will only choose the final action (in what seems to be
alphabetical order) to run. I think that the correct behavior should
instead be to loop through all global actions that have the hotkey until
one handles it.

The attached patch implements this change.

-Ian
From 70ee483a8184814d5be0f2be9bb7bf01b8977fc6 Mon Sep 17 00:00:00 2001
From: Ian McInerney 
Date: Fri, 9 Aug 2019 01:10:31 +0200
Subject: [PATCH] Run all matching global actions for a hotkey

---
 common/tool/action_manager.cpp | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/common/tool/action_manager.cpp b/common/tool/action_manager.cpp
index 96e1eabd0..a529c1dc1 100644
--- a/common/tool/action_manager.cpp
+++ b/common/tool/action_manager.cpp
@@ -118,15 +118,16 @@ bool ACTION_MANAGER::RunHotKey( int aHotKey ) const
 // Choose the action that has the highest priority on the active tools stack
 // If there is none, run the global action associated with the hot key
 int highestPriority = -1, priority = -1;
-const TOOL_ACTION* context = NULL;  // pointer to context action of the highest priority tool
-const TOOL_ACTION* global = NULL;   // pointer to global action, if there is no context action
+const TOOL_ACTION* context = NULL;  // pointer to context action of the highest priority tool
+std::vector global; // pointers to global actions
+// if there is no context action
 
 for( const TOOL_ACTION* action : actions )
 {
 if( action->GetScope() == AS_GLOBAL )
 {
 // Store the global action in case there are no context actions to run
-global = action;
+global.emplace_back( action );
 continue;
 }
 
@@ -154,13 +155,17 @@ bool ACTION_MANAGER::RunHotKey( int aHotKey ) const
 
 return m_toolMgr->RunAction( *context, true );
 }
-else if( global )
+else if( !global.empty() )
 {
-wxLogTrace( kicadTraceToolStack,
-"ACTION_MANAGER::RunHotKey Running action: %s for hotkey %s", global->GetName(),
-KeyNameFromKeyCode( aHotKey ) );
+for( auto act : global )
+{
+wxLogTrace( kicadTraceToolStack,
+"ACTION_MANAGER::RunHotKey Running action: %s for hotkey %s", act->GetName(),
+KeyNameFromKeyCode( aHotKey ) );
 
-return m_toolMgr->RunAction( *global, true );
+if( m_toolMgr->RunAction( *act, true ) )
+return true;
+}
 }
 
 wxLogTrace( kicadTraceToolStack, "ACTION_MANAGER::RunHotKey No action found for key %s",
-- 
2.21.0

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp