kicad-developers team mailing list archive

[José Eduardo S. C. Xavier <josescxavier@xxxxxxxxxxx>]

I thought it need to be on the main repo to get merged. I'll test it and
report.


2014-04-01 23:31 GMT+01:00 José Eduardo S. C. Xavier <
josescxavier@xxxxxxxxxxx>:

> Hi :)
> That is a really nice feature. Can you add it to the bzr repo?
>
>
> 2014-03-06 23:45 GMT+00:00 Henner Zeller <h.zeller@xxxxxxx>:
>
> On 3 March 2014 06:53, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> > On 3/2/2014 2:29 AM, Henner Zeller wrote:
>> >> Hi,
>> >> For small changes, or when I only have a touchpad available, I like to
>> >> use the keyboard for editing tasks, so I appreciate that the
>> >> cursor-keys control the cross-hair similar to the mouse.
>> >>
>> >> However to finish a move initiated with 'm' followed by cursor
>> >> movements, one still has to press the mouse-button, thus having to
>> >> leave the keyboard and probably mess up the precise placement. This
>> >> slows down editing and is inconsistent.
>> >>
>> >> This patch wires the 'Return' key as if the left mouse button was
>> >> pressed (in eeschema and pcbnew).
>> >>
>> >> Commit message:
>> >> Have the <RETURN>-key in editing tasks behave like a mouse-click at
>> >> the same position.
>> >>
>> >> View here
>> >>
>> https://github.com/hzeller/kicad/compare/master...enter-is-like-mouseclick
>> >>
>> >> Download here:
>> >>
>> https://github.com/hzeller/kicad/compare/master...enter-is-like-mouseclick.diff
>> >>
>> >> -h
>> >
>> > Hey Henner,
>> >
>> > You also need to add your change to the schematic component library
>> > editor and board footprint editor so they behave the same way.  The
>> > functions you are looking for are:
>> >
>> > FOOTPRINT_EDIT_FRAME::GeneralControle()
>> >
>> > and:
>> >
>> > LIB_EDIT_FRAME::GeneralControle()
>>
>> Alright, will have a look at these.
>>
>> >
>> > This way the the component and footprint editors will have the same
>> > behavior as the schematic and board editors.  Also, did you verify there
>> > are no other behavior issues with menus (both regular and context) with
>> > your patch.  Once a key is routed to the hotkey handler, it does not get
>> > passed on to the rest of the event handler chain so your patch may cause
>> > some odd behavior with other main frame controls.
>>
>> I didn't notice any oddities so far (I am using it locally). The menus
>> react normally w.r.t. cursor keys and return to select as they get the
>> event first.
>> Consuming the enter key here would mean that if someone defined a
>> hotkey for 'enter' wouldn't work (which should be very unlikely, but,
>> well, at least it is a possibility). Still I think the advantage is
>> more important than potential disadvantages.
>>
>> Alternatively, we could have a hotkey 'finish current action' or
>> similar, that by default is wired to 'Return' - and which does exactly
>> the finishing-mouseclick thing I now have hardwired in the
>> conrole-functions. That way, people are free to wire it to some other
>> key if desired.
>>
>>
>> -h
>>
>> >
>> > Thanks,
>> >
>> > Wayne
>> >
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>