Bug #1810569 “Symbol properties dialog - can't exit Fields grid ...” : Bugs : KiCad

Ben Gamari (bgamari) on 2019-01-04

description:

updated

Revision history for this message

Ben Gamari (bgamari) wrote on 2019-01-05:

#1

I've not yet verified this but it's possible that this has been fixed in master by c8b02674dcc80b19c7f8af94ddd5cd3027b17373.

Revision history for this message

Seth Hillbrand (sethh) wrote on 2019-01-05:

#2

Please add your KiCad version information

Changed in kicad:
status:	New → Incomplete

Revision history for this message

Ben Gamari (bgamari) wrote on 2019-01-05:

#3

Done.

description:	updated
Changed in kicad:
status:	Incomplete → New

Revision history for this message

Seth Hillbrand (sethh) wrote on 2019-01-07:

#4

We can use keyboard to move around the grid but can't exit the grid.

I think we should use arrow keys in the grid and tab between items. Otherwise we don't have a keyboard shortcut to move to the next item.

@Ben- Here is the version information we need to help work with the reports. You can get this from Help->About KiCad
Application: kicad
Version: (6.0.0-rc1-dev-1489-gcec97ebfa6-dirty), release build
Libraries:
    wxWidgets 3.0.4
Platform: Linux 4.18.0-3-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.67.0
    OpenCASCADE Community Edition: 6.9.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=OFF
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

Changed in kicad:
importance:	Undecided → Low
milestone:	none → 5.1.0
status:	New → Triaged
summary:	- Symbol properties dialog unusable with keyboard + Symbol properties dialog - can't exit Fields grid using keyboard

Revision history for this message

Ben Gamari (bgamari) wrote on 2019-01-07:

#5

Download full text (10.6 KiB)

> Thanks,
> Tamar
>
> On Thu, Dec 27, 2018 at 6:27 AM Ben Gamari <email address hidden> wrote:
>
>> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official
>> upstream GHC repository. Various introductory notes are
>> discussed. Let me know if you have any trouble.
>>
>> Also, please do verify the correctness of the email address
>> associated with your Trac account in the next few weeks. It will
>> be used to map users when we transition Trac tickets to GitLab.
>>
>>
>>
>> Hello everyone,
>>
>> I am happy to announce that CI on GHC's GitLab instance [1] is now
>> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be
>> considered the official upstream repository of GHC.
>>
>> The rest of this email is meant to serve as a brief introduction and
>> status update. It can also be viewed on the GitLab Wiki [2].
>>
>> [1] https://gitlab.haskell.org/
>> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome
>>
>>
>> # Getting started
>>
>> To get started on GitLab you will first want to either create a new account
>> [1] or login with your GitHub credentials [2].
>>
>> Once you have an account you should add an SSH key [3] so that you can push
>> to your repositories. If you currently have commit rights to GHC notify me
>> (Ben Gamari) of your user name so I can grant you similar rights in GitLab.
>>
>>
>> [1] https://gitlab.haskell.org/users/sign_in
>> [2] https://gitlab.haskell.org/users/auth/github
>> [3] https://gitlab.haskell.org/profile/keys
>>
>>
>> # Updating your development environment
>>
>> You can updated existing working directory (assuming the usual upstream
>> remote name of `origin`) for the new upstream repository location by
>> running the following:
>>
>> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git
>> git remote set-url --push origin <email address hidden>:ghc/ghc
>>
>> This is all that should be necessary; a quick `git pull origin master`
>> should verify that everything is working as expected.
>>
>>
>> # Continuous integration
>>
>> Continuous integration is now provided by GitLab's native continuous
>> integration infrastructure. We currently test a variety of
>> configurations, including many that neither Phabricator nor
>> CircleCI/Appveyor previously tested (see [1] for an example run):
>>
>> * With the make build system:
>> * x86_64/Linux on Fedora 27, Debian 8, and Debian 9
>> * i386/Linux on Debian 9
>> * aarch64/Linux on Debian 9 (currently broken due to a variety of
>> issues)
>> * x86_64/Windows
>> * x86_64/Darwin
>> * x86_64/Linux on Debian 9 in a few special configurations:
>> * unregisterised (still a bit fragile due to #16085)
>> * integer-simple
>> * building GHC with -fllvm
>> * With Hadrian:
>> * x86_64/Linux on Debian 9
>> * x86_64/Windows (currently broken due to #15950)
>>
>> We also run a slightly larger set of jobs on a nightly basis. Note that
>> binary distributions are saved from most builds and are available for
>> download for a few weeks (we may put in place a longer retention policy
>> for some builds in the future).
>>
>> There are admittedly a few ki...

> Thanks,
> Tamar
>
> On Thu, Dec 27, 2018 at 6:27 AM Ben Gamari <ben@well-typed.com> wrote:
>
>> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official
>>        upstream GHC repository. Various introductory notes are
>>        discussed. Let me know if you have any trouble.
>>
>>        Also, please do verify the correctness of the email address
>>        associated with your Trac account in the next few weeks. It will
>>        be used to map users when we transition Trac tickets to GitLab.
>>
>>
>>
>> Hello everyone,
>>
>> I am happy to announce that CI on GHC's GitLab instance [1] is now
>> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be
>> considered the official upstream repository of GHC.
>>
>> The rest of this email is meant to serve as a brief introduction and
>> status update. It can also be viewed on the GitLab Wiki [2].
>>
>> [1] https://gitlab.haskell.org/
>> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome
>>
>>
>> # Getting started
>>
>> To get started on GitLab you will first want to either create a new account
>> [1] or login with your GitHub credentials [2].
>>
>> Once you have an account you should add an SSH key [3] so that you can push
>> to your repositories. If you currently have commit rights to GHC notify me
>> (Ben Gamari) of your user name so I can grant you similar rights in GitLab.
>>
>>
>> [1] https://gitlab.haskell.org/users/sign_in
>> [2] https://gitlab.haskell.org/users/auth/github
>> [3] https://gitlab.haskell.org/profile/keys
>>
>>
>> # Updating your development environment
>>
>> You can updated existing working directory (assuming the usual upstream
>> remote name of `origin`) for the new upstream repository location by
>> running the following:
>>
>>     git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git
>>     git remote set-url --push origin git@gitlab.haskell.org:ghc/ghc
>>
>> This is all that should be necessary; a quick `git pull origin master`
>> should verify that everything is working as expected.
>>
>>
>> # Continuous integration
>>
>> Continuous integration is now provided by GitLab's native continuous
>> integration infrastructure. We currently test a variety of
>> configurations, including many that neither Phabricator nor
>> CircleCI/Appveyor previously tested (see [1] for an example run):
>>
>>  * With the make build system:
>>     * x86_64/Linux on Fedora 27, Debian 8, and Debian 9
>>     * i386/Linux on Debian 9
>>     * aarch64/Linux on Debian 9 (currently broken due to a variety of
>>       issues)
>>     * x86_64/Windows
>>     * x86_64/Darwin
>>     * x86_64/Linux on Debian 9 in a few special configurations:
>>         * unregisterised (still a bit fragile due to #16085)
>>         * integer-simple
>>         * building GHC with -fllvm
>>  * With Hadrian:
>>     * x86_64/Linux on Debian 9
>>     * x86_64/Windows (currently broken due to #15950)
>>
>> We also run a slightly larger set of jobs on a nightly basis. Note that
>> binary distributions are saved from most builds and are available for
>> download for a few weeks (we may put in place a longer retention policy
>> for some builds in the future).
>>
>> There are admittedly a few kinks that we are still working out,
>> particularly in the case of Windows (specifically the long build times
>> seen on Windows). If you suspect you are seeing spurious build failures
>> do let us know.
>>
>> To make the best use of our limited computational resources our CI
>> builds occur in three stages:
>>
>>  * lint: the style and correctness checkers which would previously be
>>    run by `arc lint` and `git push`
>>
>>  * build: Debian 9 Linux x86_64 built with make and Hadrian
>>
>>  * full-build: the remaining configurations
>>
>> If a build fails at an earlier phase no further phases will be run.
>>
>>
>> [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568
>>
>>
>> # Structuring your merge request
>>
>> With the transition to GitLab GHC is moving to a model similar to that
>> used by GitHub. If you have a Differential on Phabricator we will finish
>> review there. However, please post new patches as merge requests on
>> GitLab.
>>
>> Note that Phabricator and GitLab have quite different models for
>> handling patches. Under Phabricator a Differential is a single patch
>> with no further structure; larger changes can be composed of multiple
>> dependent Differentials.
>>
>> Under GitLab's model a merge request is a git branch consisting of
>> one or more patches. Larger changes can be handled in one of two ways:
>>
>>  a. a set of dependent merge requests, each of which to be squashed when
>>     merged.
>>
>>  b. a single branch with each atomic change made in a single, buildable
>>     commit
>>
>> Due to the difficulty of maintaining dependent merge requests, I would
>> recommend that contributors making larger changes use method (b).
>>
>>
>> # Submitting your merge request for review
>>
>> Depending upon whether you have push rights to the GHC repository there
>> are two ways to submit a merge request:
>>
>>  * if you have push access you can push a branch directly to
>>    git@gitlab.haskell.org:ghc/ghc.git and open merge request.
>>
>>    In this case please do follow the usual branch naming conventions:
>>
>>      * prefix all branch names with `wip/`
>>
>>      * if you are fixing a particular ticket consider using the name
>>        `wip/TNNNN`
>>
>>  * if not you can create a fork using the "Fork" button on the project
>>    page [1] and push your branch there
>>
>> In either case after you have pushed your branch open a merge request
>> against ghc/ghc [2].
>>
>> [1] https://gitlab.haskell.org/ghc/ghc/forks/new
>> [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new
>>
>>
>> # Reviewing and merging merge requests
>>
>> As always, all contributors are encouraged to help review proposed
>> changes. If you are unfamiliar with GitLab's review interface please see
>> GitLab's user documentation [1]. Here are a few quick highlights for
>> those who are familiar with GitHub but haven't yet used GitLab:
>>
>>  * As with GitHub, GitLab supports both inline and out-of-line comments.
>>
>>  * Comments that are actionable (known as "discussions") can be marked
>>    as resolved and collapsed.
>>
>>  * Comments can be left on both changed and unchanged lines
>>
>>  * Revisions of a merge request can be viewed and compared using the
>>    two drop-down menus at the top of the Changes tab
>>
>>  * Merge requests can require approvals from particular users before
>>    considered as mergable
>>
>>  * Merge requests can be placed in "merge when CI passes" state, which
>>    will cause merge requests to be merged as soon as they are green
>>
>> From this point onward all changes to GHC will be merged via
>> GitLab's merge requests facility and must pass CI before being merged.
>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's
>> "fast-forward without a merge commit" merge strategy. Consequently you
>> will be asked to rebase merge requests which are not fast-forward merges
>> before merging (a convenient "Rebase" button will appear if the rebase
>> can be carried out without conflicts.
>>
>> [1] https://gitlab.com/help/user/discussions/index.md#discussions
>>
>>
>> # Status of the Trac migration
>>
>> Tobias will be continuing work on the Trac ticket migration after a bit
>> of a holiday break. Hopefully by mid-January we will be able to move
>> forward on this part of the migration; I will share more details about
>> this as they develop.
>>
>> In the meantime, users of Trac should check and possibly update the
>> email address associated with their account [1].  This address will be
>> used to correlate Trac users with their GitLab equivalents so the
>> correctness of this address will be important in preserving attribution
>> information during the Trac import.
>>
>> [1] https://ghc.haskell.org/trac/ghc/prefs
>>
>>
>> # Next steps
>>
>> We are actively working on cleaning up a few remaining issues with CI:
>>
>>  * build times are still very long on Windows, despite the fact that we
>>    are only building the `quick` build flavour on that platform;
>>    consequently GitLab CI Windows builds do sometimes timeout
>>    when we are faced with long build queues.
>>
>>  * we at times run low on disk space on our Windows builder runners,
>>    resulting in occasional spurious build failures
>>
>>  * Appveyor builds (which are supposed to supplement the native GitLab
>>    builds) rarely seem to finish
>>
>> GitLab upstream has been incredibly supportive of our transition effort
>> and has expressed interest in assisting us with issues that we
>> encounter. Our current requests can be found on our migration effort's
>> tracking ticket [1]. If you find any additional bugs or workflows that
>> could be improved please do let me know and I can raise the matter with
>> GitLab.
>>
>> [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039
>>
>>
>> # Acknowledgments
>>
>> I would like to acknowledge several parties for their contributions to
>> this effort:
>>
>>  * Packet.net and Google X for their generous donation of hosting for
>>    continuous integration and web hosting
>>
>>  * GitLab and their Open Source program for many productive discussions,
>>    their generous support, and the GitLab Ultimate license used by
>>    gitlab.haskell.org.
>>
>>  * Davean Scies for his help procuring the hosting services that power
>>    our continuous integration.
>>
>>  * Tweag.io for their offer of help and advice
>>
>>  * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work
>>    in setting up the new instance, sorting out the details of the
>>    migration, and debugging problems when they arose
>>
>> Finally, thanks to GHC's contributors for their patience during this
>> transition; it has been a long process which has stolen a significant
>> amount of attention from other matters. My apologies we have been a bit
>> less responsive than usual in code review and ticket triage over the
>> past month or two. Regardless, I am hopeful that this wait will be
>> worthwhile.
>>
>>
>> # Final thoughts
>>
>> This is not only a milestone for the GitLab migration but also for GHC
>> itself. For the first time GHC has fully-automated testing, proposed
>> patch CI, and release generation across the full range of Tier 1
>> configurations it supports, with passing builds in all cases.
>>
>> We are very excited to begin this next chapter of GHC's development and
>> are looking forward to your feedback on how we can further improve our
>> new infrastructure. Onward and upwards!
>>
>> Cheers,
>>
>> - Ben
>> _______________________________________________
>> Ghc-devops-group mailing list
>> Ghc-devops-group@haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>>

Revision history for this message

Ben Gamari (bgamari) wrote on 2019-01-07:

#6

Sigh, my apologies. That was not what I intended to paste.

Below is the Kicad version information.

Application: kicad
Version: 5.0.0, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.62.0 OpenSSL/1.0.2p zlib/1.2.11 libssh2/1.8.0 nghttp2/1.32.0
Platform: Linux 4.19.12 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.62.0
    Compiler: GCC 7.3.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

Revision history for this message

Ben Gamari (bgamari) wrote on 2019-01-07:

#7

> We can use keyboard to move around the grid but can't exit the grid.

> I think we should use arrow keys in the grid and tab between items. Otherwise we don't have a keyboard shortcut to move to the next item.

Navigation with the tab key is nice however what we really need is a keyboard accelerator for each UI element.

For instance, consider the workflow to add a new field to a symbol. Currently (as of Kicad 5.0.1) this requires that one uses the mouse to click on the + button, then (again with the mouse) select the Field Name text box.

It should be possible to accomplish this without leaving the keyboard. I would think I should be able to press (for instance) Alt+A to activate the + button, then Alt+N to select the Field Name, then tab to move focus to Field Value. Or even better: pressing the + button could automatically give focus to the Field Name field.

Revision history for this message

Jeff Young (jeyjey) wrote on 2019-01-08:

#8

Ctrl-Tab exits the grid on Mac. Does this not work on other platforms?

It's true that we have no accelerator for Add, but once you do add the Field Name is selected automatically and a Tab will move to the Field Value. (Again, at least on Mac....)

Revision history for this message

Seth Hillbrand (sethh) wrote on 2019-01-08:

#9

Nope. I'm pretty sure that Ctrl-Tab cycles the visible application windows on MSW and it does nothing for linux.

Revision history for this message

Wayne Stambaugh (stambaughw) wrote on 2019-01-09:

#10

@Seth, I think you mean Alt-Tab. Ctrl-Tab does not exit the grid on windows. Ctrl+Enter is the same as clicking the default button so for most dialogs that would be the OK button.

John Beard (john-j-beard) on 2019-01-24

tags:

added: ui

Revision history for this message

Seth Hillbrand (sethh) wrote on 2019-01-31:

#11

This is not critical for v5.1

Changed in kicad:
milestone:	5.1.0 → 6.0.0-rc1

Revision history for this message

John Beard (john-j-beard) wrote on 2019-03-07:

#12

KiCad UI guidelines[1] recommend the GNOME HIG[2], which states:

> Ctrl+Tab and Shift+Ctrl+Tab:

> Moves keyboard focus out of the enclosing widget to the next/previous control, in those situations where Tab alone has another function

So, at least on Linux, Ctrl-Tab would be the "expected" key to exit a grid to move to the "next" field.

[1]: http://docs.kicad-pcb.org/doxygen/md_Documentation_development_ui-policy.html
[2]: https://developer.gnome.org/hig/stable/keyboard-input.html.en

Michael Kavanagh (michaelkavanagh) on 2019-05-04

tags:

added: eeschema

Revision history for this message

Jeff Young (jeyjey) wrote on 2019-06-24:

#13

I believe I've hooked up ctrl-tab to work in MSW and GTK. (I can't be 100% sure, as I can only test on OSX.)

Changed in kicad:
assignee:	nobody → Jeff Young (jeyjey)
status:	Triaged → In Progress

Revision history for this message

KiCad Janitor (kicad-janitor) wrote on 2019-06-25:

#14

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

Changed in kicad:
status:	In Progress → Fix Committed

KiCad

Symbol properties dialog - can't exit Fields grid using keyboard

Bug Description

Duplicates of this bug

Other bug subscribers

Remote bug watches