placing a text: finishing dialog with keyboard not possible any more

[Karl Zeilhofer]

When placing a text in eeschema or pcbnew, i was used to enter the text, hit the tabulator-key to advance to the size-input-field, and then hit enter to finish and close the dialog.
Now the text-input field accepts the tabulator-key as text-input.

So I'm missing the feature to finish and close the dialog with the keyboard only.

Perhaps a solution would be, that a shift-enter inserts a line-break into the text-field, and enter allone finishes the dialog.
perhaps many people are used to that from other GUIs, e.g. facebook comments, excel, ...

kind regards,
Karl

Application: kicad
Version: 0.201501280107+5391~20~ubuntu14.10.1-product Release build
wxWidgets: Version 3.0.1 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.9.1,wx containers,compatible with 2.8)
Platform: Linux 3.16.0-29-generic x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.54.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON
         KICAD_USE_WEBKIT=ON

[firewalker (firew4lker)]

Hit Alt+Tab.

[Karl Zeilhofer (zeilhofer)]

I don't know what OS you are using, but on Kubuntu and on Windows Alt+Tab switches between aplication windows...
I found out, that ALt+O works to click the OK button with the keyboard.
I'm not used to that, but that's just a matter of time.

[firewalker (firew4lker)]

You are right. I meant to write Ctrl+Tab. I am using ArchLinux.

[jean-pierre charras (jp-charras)]

Looks like an issue due to wxWidgets on Linux.
wxWidgets on Windows does not exhibit this problem.
Kicad dialogs are already set to use tab key to select the next widget.
Therefore it is unlikely we can fix this issue.

[Hildo Guillardi Júnior (hildogjr)]

The most of EDA software (even Internet applications) use <Shift>+<Return/Enter> to expand this function.
On Internet <Shift>+<Enter> is <Enter> and <Enter> is Send.
In the EDA that I used before KiCad, <Shift>+<Enter> was the OK in the dialog.
(Just think in some standardization).

[Jeff Young (jeyjey)]

A tab is rendered as a '?' on the canvas anyway, so there's absolutely no reason to allow it into the textbox instead of tabbing to the next control.

<Shift>+<Enter> to OK the dialog would also be nice.

[Jeff Young (jeyjey)]

Patch attached. Also fixes the same issue in pcbnew text editing.

[Wayne Stambaugh (stambaughw)]

Event handlers should not be defined in dialog derived objects. They
should be implemented in the base class using wxFormbuilder and then
overridden in the derived class. I also noticed that you have placed
Doxygen comments in the source (.cpp) file. This is a coding policy
violation. Doxygen comments belong in the header file. I understand
that the previous developer did this and you just repeated the error but
it is incorrect.

On 12/28/2017 02:35 PM, Jeff Young wrote:
> Patch attached. Also fixes the same issue in pcbnew text editing.
>
> ** Patch added: "0004-Enable-tab-navigation-and-shift-return-for-OK-in-mul.patch"
> https://bugs.launchpad.net/kicad/+bug/1420916/+attachment/5028521/+files/0004-Enable-tab-navigation-and-shift-return-for-OK-in-mul.patch
>
> ** Changed in: kicad
> Assignee: Jeff Young (jeyjey) => (unassigned)
>

[Jeff Young (jeyjey)]

The trouble is that wxFormbuilder doesn’t handle the wxEVT_CHAR_HOOK event. (Well, I don’t think it does. It’s not one of the events that appears in the fbp files.) Is there a way to handle that?

[Jeff Young (jeyjey)]

@Wayne, this is about the only thing I could find on adding event handlers to wxFormBuilder:

Yes, apparently it is the way to only declare the new event handler in
the derived class (the one that wxFormBuilder creates when you do
Tools->Generate Inherited Class), and connect/disconnect it to whatever
control you want it to be linked to in the respective
constructor/destructor.

I think the primary reason for the superclass/subclass split is to have one file wxFormBuilder can auto-regenerate, and one file that is only generated once (and can after that be edited by the coder). From that perspective, I think the attached patch is correct.

[Jeff Young (jeyjey)]

Hmmm... let's try that again:

@Wayne, this is about the only thing I could find on adding event handlers to wxFormBuilder:

--- begin quote from stack exchange[1] ---
Yes, apparently it is the way to only declare the new event handler in
the derived class (the one that wxFormBuilder creates when you do
Tools->Generate Inherited Class), and connect/disconnect it to whatever
control you want it to be linked to in the respective
constructor/destructor.
--- end quote ---

I think the primary reason for the superclass/subclass split is to have one file wxFormBuilder can auto-regenerate, and one file that is only generated once (and can after that be edited by the coder). From that perspective, I think the attached patch is correct.

[1] https://stackoverflow.com/questions/8255753/how-to-add-personal-code-into-wxformbuilder-generated-class

[Wayne Stambaugh (stambaughw)]

@Jeff, we reserve high and critical bug severity levels for data
corruption/loss and/or segfault bugs. This bug does not fit either
category. At best the severity should be medium. Given that it's
annoying bug does not prevent users from completing the task, I would
set it to low.

On 12/30/2017 05:52 PM, Jeff Young wrote:
> ** Changed in: kicad
> Status: New => Triaged
>
> ** Changed in: kicad
> Importance: Undecided => High
>

[Jeff Young (jeyjey)]

@Wayne, I mostly set it to high because the tag line on high says "Scheduled to be fixed soon", and there's already a patch.

But I'm OK with medium too.

Did you have any further thoughts on the location of the code?

[Wayne Stambaugh (stambaughw)]

No problem about the bug severity level. I need to document this
somewhere so new (and some old) bug squad members know how the project
sets bug severity levels.

I took a look at wxFormbuilder and you are correct. There is no way to
create a wxEVT_CHAR_HOOK event handler so you patch appears to be the
best solution. I will test an merge it as soon as get a chance.

On 12/31/2017 07:47 AM, Jeff Young wrote:
> @Wayne, I mostly set it to high because the tag line on high says
> "Scheduled to be fixed soon", and there's already a patch.
>
> But I'm OK with medium too.
>
> Did you have any further thoughts on the location of the code?
>
> ** Changed in: kicad
> Importance: High => Medium
>

[KiCad Janitor (kicad-janitor)]

Fixed in revision fb597f429874467eb92b31fb5aae7956b98ea0cc
https://git.launchpad.net/kicad/patch/?id=fb597f429874467eb92b31fb5aae7956b98ea0cc

[Wayne Stambaugh (stambaughw)]

@Jeff, I merged your patch. Thanks!