Eeshema - Tools - Component Table View enters edited content on the wrong row

Bug #1737361 reported by Oivind Toien on 2017-12-09
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
KiCad
Undecided
Jeff Young

Bug Description

1. In an existing schematic go into Tools - Component Table View. The information appears to be correctly displayed and sorted.
2. Click on a field and click it again to enter new information or edit the content of the field.
3. After changing or typing new information, the apply changes button is still grayed out, so the only way to continue is to click another field. If a field on the same row is clicked the changed information is entered into the correct filed and now appears in bold Italics. ** However if a field on a different row is clicked instead the just edited information will be entered into that row **, which is clearly incorrect.

Some related side notes:
a) The pre-selection of the field to edit before the final click to edit it highlights the whole row, which makes it a bit uncertain which of the fields have been selected. For instance if one field of the same row is first edited and then the next filed is then clicked to select that, there is no apparent visible change to confirm the selection. When I first learned that I could edit these fields, I tried to double click these field due to that lack of the visual feedback, but the double-click was often too fast to be accepted as the required two separate clicks. If there had been visual feedback on the first click, I would have understood that the selection was not to happen with a double click. So my suggestion is to only highlight the selected field.
b) The description fields do not appear to be editable; is that by design or a bug?

Application: kicad
Version: (2017-12-08 revision d205366da)-makepkg, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    Curl: 7.54.1
    Compiler: GCC 7.1.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=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

Kliment Yanev (kliment-) wrote :

Cannot replicate here. Can you attach the project where this happens?

Application: kicad
Version: (2017-12-09 revision cb422e2)-master, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-98-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

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_SPICE=ON

I also noticed that.
It could be OS dependent.

Oivind Toien (otoien) wrote :

Thanks for confirming Jean-Pierre, OS dependency sounds plausible. I am providing a minimal zipped "nonsense" project created with the just downloaded unsigned Windows nightly with some "molecular" parts. Symbols are contained in the local 00-project library. [The project also demonstrated that the fix for Bug #1737014 works].

Application: kicad
Version: (2017-12-09 revision 48388695a)-makepkg, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    Curl: 7.54.1
    Compiler: GCC 7.1.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=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

Oliver (schrodingersgat) wrote :

I can verify this problem exists on Windows 10:

Here's a screengrab, it demonstrates the problem a bit more clearly.

http://recordit.co/nPhAdqra4D

It feels like a wx issue, perhaps?

Jeff Young (jeyjey) on 2018-02-28
Changed in kicad:
status: New → In Progress
KiCad Janitor (kicad-janitor) wrote :

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

Changed in kicad:
status: In Progress → Fix Committed
Oivind Toien (otoien) wrote :

Thanks, I can confirm that the new symbol table fixes the problem.

Comment to the new table: The number of available fields seems limited to the most essential ones compared to the previous dialog (for instance missing the potentially very long description info), but there is probably some reason for it, perhaps because description is not defined as a field. One could perhaps wish for the user defined custom fields (manufacturer etc.) to also be available?

Nitpicking is that of the headings in the left column only "Field" is re-sizable, for the two others width is frozen (and only a few letters are shown, "Sh...", "Grou...") in spite of showing resize marks when hovering mouse over the boundaries.

Jeff Young (jeyjey) wrote :

User defined custom fields will (or at least should) appear. Only the description was removed, because it caused more confusion (due to being read-only) than benefit.

Odd that Windows doesn't respect the Show and Group By column widths. I'll look into it....

Oivind Toien (otoien) wrote :

Somehow I now see all those user defined fields. I am still on version 5.0.0-rc2-dev-451-g0294e41cb and do not think I updated since last post. Not sure what caused it other than perhaps a restart or two of the computer in the mean time.

I further just updated to latest nightly (5.0.0-rc2-dev-493-gd776eaca8) and it still looks fine there, other than the minor nitpick. (Also I can confirm that Bug #1765443 is fixed in this version.)

Jeff Young (jeyjey) wrote :

@Oivind, could you attach a screen shot of the truncated column headings? Windows seems to be a bit different from Mac here....

Oivind Toien (otoien) wrote :

@Jeff, I have attached the screen shot. With respect to truncation it has actually improved in the last version, the remaining knit pick is about the inability to resize the width of the Show and Group headings in spite of that the mouse cursor indicates that that is possible. At the moment the screen shot was made the mouse was between those two column headings, but the screen shot does not show the mouse cursor's double horizontal arrow. If all that is intended to be displayed is "Show" and "Group", it is not really a problem, as the headings are showing (with the reservation that I do not know what other display resolutions will do - I am on 125% font scaling). If anything one could perhaps convince the mouse cursor not to change when between those two headings and to the right of the group heading. The resize of the Field column is OK, before the screen shot was made I successfully tested resize that column.

Jeff Young (jeyjey) wrote :

Ahh, it's probably the 125% fonts that are causing the issue. I need to be smarter about how the widths are calculated.

The column sizing should be turned off for all of the columns; you can use the slider between the list view and the table view to adjust how wide the fields column is.

KiCad Janitor (kicad-janitor) wrote :

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

Changed in kicad:
assignee: nobody → Jeff Young (jeyjey)
Jeff Young (jeyjey) wrote :

OK, I just pushed a better solution for this which calculates the column widths based on the text.

@Oivind, could you give it a test when you get a chance? (It should fix both niggle issues.)

Jeff Young (jeyjey) wrote :

@Devs, since this got wonky on Linux after the last fix, could someone do a quick test to make sure the column widths don't fritz out when dragging the splitter? Thanks.

Oivind Toien (otoien) wrote :

@ Jeff, I just checked the last nightly (5.0.0-rc2-dev-501-g50588dcd1), but it looked and responded identical to my last test, so I am not sure an update with the changes has appeared yet. I will try again tomorrow night.

Seth Hillbrand (sethh) wrote :

@jeyjey - This is still pretty wonky on Debian. Can't select or change field widths as they are all crowded at the right (see attached image)

Well, rats. There doesn’t appear to be any way to make GTK and MSW happy with the same code. I’ll have to #ifdef it.

Jeff Young (jeyjey) wrote :

@Seth, latest commit is in. Hopefully this will make both platforms happy....

Seth Hillbrand (sethh) wrote :

@jeyjey - Sorry to be the bearer of bad news but it doesn't seem to be fixed yet. Now, I have a scrollbar at the bottom of the window but the first field automatically takes the full width. Regardless of the size of the text fields. And I can't re-size the columns.

Oivind Toien (otoien) wrote :

@jeyjey, I am lagging a bit behind here, but I just found that the Windows nightly now had updated (5.0.0-rc2-dev-570-gbfc70c820), April 24, and tested. As shown in the attached image, the headings now look fine on my screen showing both the "Show" and "Group by" heading, so there is no incentive to try resize them (although it still pretends it can do so). Everything else also looks normal in this version. I am not sure when it updated (it seems the schedule for build has changed; it used to be shortly after midnight local time Alaska, but daylight savings time might have a play). This test would likely not reflect the last commit - I will test again once it updates again.

Jeff Young (jeyjey) wrote :
Download full text (3.7 KiB)

Thanks for checking, @Oivind.

The final version /should/ be the same for you as it only has different code for Linux. I know, famous last words….

> On 25 Apr 2018, at 01:56, Oivind Toien <email address hidden> wrote:
>
> @jeyjey, I am lagging a bit behind here, but I just found that the
> Windows nightly now had updated (5.0.0-rc2-dev-570-gbfc70c820), April
> 24, and tested. As shown in the attached image, the headings now look
> fine on my screen showing both the "Show" and "Group by" heading, so
> there is no incentive to try resize them (although it still pretends it
> can do so). Everything else also looks normal in this version. I am not
> sure when it updated (it seems the schedule for build has changed; it
> used to be shortly after midnight local time Alaska, but daylight
> savings time might have a play). This test would likely not reflect the
> last commit - I will test again once it updates again.
>
> ** Attachment added: "Choose-Symbols-002.jpg"
> https://bugs.launchpad.net/kicad/+bug/1737361/+attachment/5126796/+files/Choose-Symbols-002.jpg
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1737361
>
> Title:
> Eeshema - Tools - Component Table View enters edited content on the
> wrong row
>
> Status in KiCad:
> Fix Committed
>
> Bug description:
> 1. In an existing schematic go into Tools - Component Table View. The information appears to be correctly displayed and sorted.
> 2. Click on a field and click it again to enter new information or edit the content of the field.
> 3. After changing or typing new information, the apply changes button is still grayed out, so the only way to continue is to click another field. If a field on the same row is clicked the changed information is entered into the correct filed and now appears in bold Italics. ** However if a field on a different row is clicked instead the just edited information will be entered into that row **, which is clearly incorrect.
>
>
> Some related side notes:
> a) The pre-selection of the field to edit before the final click to edit it highlights the whole row, which makes it a bit uncertain which of the fields have been selected. For instance if one field of the same row is first edited and then the next filed is then clicked to select that, there is no apparent visible change to confirm the selection. When I first learned that I could edit these fields, I tried to double click these field due to that lack of the visual feedback, but the double-click was often too fast to be accepted as the required two separate clicks. If there had been visual feedback on the first click, I would have understood that the selection was not to happen with a double click. So my suggestion is to only highlight the selected field.
> b) The description fields do not appear to be editable; is that by design or a bug?
>
>
> Application: kicad
> Version: (2017-12-08 revision d205366da)-makepkg, release build
> Libraries:
> wxWidgets 3.0.3
> libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
> Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 b...

Read more...

Seth Hillbrand (sethh) wrote :

@Jeff- Thanks for fighting with this. Looks good here.

Oivind Toien (otoien) wrote :

In the just downloaded Windows nightly (5.0.0-rc2-dev-581-g09a6bada0), the width of the "Field" column has become narrower (attached image, still at 125% font scaling) and while the width of the left part of the dialog can be resized and with it the width of the "Field" column, these settings are not remembered, so one would have to resize it every time the dialog is opened to see the full text. Is it possible to make it remember it's size, or automatically adjust to the width of the text, including the custom fields? If not I would say the wider default column width of the "Field" column in the last version was better. Having it wider by default will make it less likely that it needs to be resized.

Otherwise I also checked the width of the "Show" and "Group By" columns of the same nightly in a VM with 100% font scaling and I can confirm that they also looked OK at this font scaling.

Jeff Young (jeyjey) wrote :

JP also gave me the secret sauce for calculating the header widths, so I can get rid of the conditional compilation as well.

Jeff Young (jeyjey) wrote :

@JP, @Seth, @Oivind, I hate to make everyone keep checking this, but I'd like to get it uniformly right. So, once more into the breach....

Fast test on W7:
CHECKBOX_COLUMN_MARGIN is too small: the same value as GTK (15) works fine.
Otherwise the title is truncated.

Jeff Young (jeyjey) wrote :

Cool; so Mac is the outlier rather than GTK.

Jeff Young (jeyjey) wrote :

The janitor seems to have dropped the previous commit as well:

https://git.launchpad.net/kicad/patch/?id=dcf02f5f673cdd8671de10cb46366a80f5db50e7

Seth Hillbrand (sethh) wrote :

GTK test shows the Field column truncated (see attached image)

BTW, Jeff I think we need a wxWidgets campaign shoulder patch for you. :)

Wayne Stambaugh (stambaughw) wrote :

On 4/26/2018 11:33 AM, Seth Hillbrand wrote:
> GTK test shows the Field column truncated (see attached image)
>
> BTW, Jeff I think we need a wxWidgets campaign shoulder patch for you.
> :)

+1

>
> ** Attachment added: "SymbolFields3.png"
> https://bugs.launchpad.net/kicad/+bug/1737361/+attachment/5127717/+files/SymbolFields3.png
>

KiCad Janitor (kicad-janitor) wrote :

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

Jeff Young (jeyjey) wrote :

@Seth, could you try the latest out? (I'm not sure it will fix it as it doesn't reproduce on Mac, but it's a similar fix as to the column headers.)

Oivind Toien (otoien) wrote :

Thanks for the efforts Jeff. The just downloaded Windows nightly looks perfect. Version: (5.0.0-rc2-dev-586-g888c43477) , release build. I am not sure if the build updated late enough to include the very last changes.

Oivind Toien (otoien) wrote :

Still good this morning in the updated Windows nightly. Version: (5.0.0-rc2-dev-596-gcfd2f1d00), release build. I also notice that the Field column adapts its width nicely if my custom fields are not present. Thanks again for making this right.

Jeff Young (jeyjey) wrote :

I might get lonely now with this bug to keep me company. ;)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers