OpenCPN
Settings windows of grib_pi is not resizable or scrollable
The settings window as shown cannot be pushed upwards to get the @ sign/button visible.
This can be seen on a Debian 12 with fluxbox (1.3.7) as the window manager.
Latest build (3d816b0c6504d5666e32624754e3d92da78fee90) by today.
Preliminary triage findings:
- This is reproducible also on Bookworm + Gnome
- Not being resizeable is not a bug for a modal dialog. However, not being able to scroll to access widgets if required due to missing vertical space is.
- The window ownership is a mess, dialogs are disconnected from the top level window and thus free floating making debugging hard. Hacked the problematic dialog to have MyFrame as top window to proceed.
- If the dialog is constrained by the (virtual) screen gtk does the right thing and adds scroolbars making everything accessible.
- OTOH, if the dialog is constrained by the opencpn top window gtk does not add any scrollbars.
FWIW, 4) and 5) makes me think that this is perhaps about some missing Fit(), Layout(), etc.
Running out of time, have a yacht to take care of. The ice is almost gone, tomorrow temperature is 24°.
This worked fine, with scroll bars, in O584. So some regression has occurred. Needs a (long) git bisect session.
Hm... Tested:
- official 5.8.4+dfsg-1~bpo12+1 bookworm package
- bookworm source build from the Release_5.8.4 tag.
- official 5.8.2+dfsg-3~bpo11+1 bullseye package.
- official 5.2.4+dfsg-1 bullseye package
For me the issue is still present basically unchanged in all four cases. Seems like a long standing issue.
EDIT: Added 5.2.4+dfsg-1
Hmm^2... Current master works correctly on Windows. Scroll bars shown, all items accessible. But not on linux. Anyone quick test Mac, please?
It is broken on Linux, 5.8.4 also. Depending on the window manager, if the settings window is too small, the scrollbars either are not shown at all or the scrolled window content size is not correct and scrolling is not possible anyway.. On macOS the scrolling is OK.
Looking at the object tree:
There is nothing like a wxScrolledWindow present here? Is it that gtk needs an explicit scrolled window, while Windows/Macos does not?
yes, of course. And that one has a scrolled window on top:
Question is then why it does not work as expected on gtk. Back to square one.
After much trial and error, a workable correction pushed to master. Not especially happy with the patched code. There is definitely some funny interaction between wx scrolled windows and GTK. But it works, subject to all-platform tests.
Works on my side as expected now. Thanks for the fast response/work! Ready for closure?
Rpi5-Bookworm - OK.
Windows10 175% scaled: When shifting between the three tabs, Data, Playback and GUI a msec glimpse of a small window with scroll bar is seen where after the normal sized window is shown. No scroll bar is needed there. I wouldn't say the glimpse is really disturbing. It's just an observation not seen on e.g. Rpi.
I have just done a Mac build and the window is fine but more to the fact of its size on a bigger screen. The window itself is not resizable so no scrolltesting could be done.
If you resize the main OpenCPN window, to something smaller than full screen, the Settings dialog will reduce in size also. This should prompt scroll bars if necessary.
It works but ...
I have encountered a different fault before as can be seen on the image. The scrollable pane is painting in front of its parent respectively pushing over at the top and bottom. I can see this behaviour even on other windows like the plugin list. I cannot exclude the possibility that my machine may be the cause. This bug may only be valid if others can confirm this.
This is broken wxWidgets, I have seen it too with some local builds, should not be present if you use the CI product from https://cloudsmith.io/~david-register/repos/opencpn-unstable/packages/
You are right. It is a local wx build - so disregard. Regarding the scrolling issue I can confirm it is working at least on Mac and Lin. Have not tried Win yet.