grid and layer toolbar comboboxes opened location

[eelik]

With Kubuntu/GTK the grid and layer comboboxes in the main toolbar open with annoying location and layout. See the screenshot. Via and Track comboboxes behave normally, they open so that the list upper border is on top of the combobox upper border. The grid and layer lists take as much space as their lists would need but the lists don't fill them at first, they must be scrolled.

[eelik (eelik)]

Application: kicad
Version: (6.0.0-rc1-dev-1388-g3e640030f), debug build
Libraries:
    wxWidgets 3.0.3
Platform: Linux 4.13.0-46-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    OpenCASCADE Community Edition: 6.8.0
    Compiler: GCC 7.2.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_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=OFF

[Seth Hillbrand (sethh)]

They need to be scrolled because the item you have currently selected is at the bottom of the list.

[eelik (eelik)]

No. As can be seen in the screenshot, there's plenty of room in the bottom of the list area. It's unnecessarily wasted space. It should be opened so that the whole area is filled. For example, attached is LibreOffice font size combobox list when it's opened. The selected value is highlighted and centered but the whole list area is in use. That's how comboboxes usually behave and look. KiCad's behavior is very annoying.

[eelik (eelik)]

Another example, from FreeCAD. The item which was selected before opening is highlighted and the last in the list.

[eelik (eelik)]

Probably this depends on GTK and so is out of bounds for KiCad development. I can accept that. But it's still bad usability. I'll change this to Opinion ("doesn't fit with the project") to satisfy myself.

[Seth Hillbrand (sethh)]

Thanks, those are good examples. I see that you want a combobox instead of a choicebox. That probably makes sense for this use case. And you are correct, the usability is better.

[KiCad Janitor (kicad-janitor)]

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

[Jeff Young (jeyjey)]

@Seth, this breaks them on OSX completely. I looked at adding conditional compilation, but it would affect a lot of places (including requiring some solution for .fbp files). Mind if we back it out and just live with it?

[Seth Hillbrand (sethh)]

Ugh. Sorry! Broken how?

[Jeff Young (jeyjey)]

Menus pop-up, but there's no highlighting in them and clicking on items does nothing (other than close the pop-up).

[Jeff Young (jeyjey)]

Oh, and the fix for drawing "---" as a separator line doesn't work (but we could probably move that if the other stuff worked).

[Seth Hillbrand (sethh)]

That sounds really bad. I haven't been able to test Mac builds in a while as the nightly server hasn't generated a new build in a week or so.

Do combo boxes just not work at all on Mac? For example, does the combo box in libedit for the part selector work correctly?

[Jeff Young (jeyjey)]

They're pretty dodgy on Mac. The libedit part selector works, but the items don't highlight as you hover over them, so it feels like it's not working.

The owner-drawn ones work (such as the layer selector, net selector, etc.).

[Seth Hillbrand (sethh)]

Well, shoot. I've been trying to get the kicad-mac-builder compile working again on my machine for a couple days without success. Some python compile error. I guess we should back out and live with it for 5.1 until I can spend some quality time petting the mac build. No point in holding 5.1 back for this.

[eelik (eelik)]

Sigh. I was so happy and thankful.

[Seth Hillbrand (sethh)]

@Jeff-

I think I see the issue. It looks like the click for the drop down combobox is not getting processed because the canvas gets it first. If you click just off the canvas, the click registers. Is it possible that this is a z-order issue? Or do we just need to .Skip() the clicks at the end of the canvas handler?

[Jeff Young (jeyjey)]

@Seth,

I can't reproduce that. If I scroll the menu so that an unselected item appears at the top, and click in the thin area that is still over the toolbar, I still don't get that item selected. Same for the track width menu if I click over an unselected item at the left edge (so the mouse is over the vertical toolbar).

Does the canvas also get the mouse-moved events? Is that what keeps the hover highlighting from working? (But again, it still doesn't work when over the vertical toolbar.)

The comboboxes also don't popup when you click over the text part -- you have to click over the arrow.

[Jeff Young (jeyjey)]

That last part is odd since clicking the text part of an owner-drawn popup /does/ work (for instance, the layer popup just above the problematic ones).

[jean-pierre charras (jp-charras)]

On OSX, issues with wxComboBox in auiToolbars are not recent.

See commit 1311f814 (2015 july 02)
Replace wxComboBoxes by wxChoice in auxiliary horizontal toolbar, to try to avoid issues on OSX.

[Jeff Young (jeyjey)]

@Seth, do you want me to back this change out, or are you still looking at it?

[Seth Hillbrand (sethh)]

Hi Jeff-. That would be great thanks. I have a few thoughts on the cause but they can wait for v6

[Seth Hillbrand (sethh)]

I just looked at the revert difficulty and realized there were multiple commits that touched this. Not fun, so I'll revert. I'm going to reset this item for addressing during v6 so I don't forget it.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1866