Closed tikiss closed 8 months ago
Very strange behavior. Unfortunately, I do not own anything that can run macOS (I will see if I can set up a VM when I find time for it). Are the steps you mentioned to reproduce it all necessary? What I mean is, does the problem also show up if you skip the calibration? This could give me a hint where to look for it. Can you still make selections in the dropdown menus? Your markers seem to show valid data of only one trace (no overlap on the data). Are you able to switch a marker to a different trace?
No, the calibration is not needed, I have just tried now, switched on, started the GUI, and placed a marker in the list, and the same effect, trace, and type are not readable, but they are working, the marker shows the value which is selected, and if I open the dropdown I see which is selected because there is a tick next to it. Just some additional notes, I tried resize the window, it has no effect, also undocked the marker window also resized it, no effect, also resized the columns, has no effect neither.
I can confirm this is still present on 1.5.0, and that you don't need to calibrate. It looks like there's a text label on top of the drop down. It's odd. I'm curious whether the extra UI element is there on other platforms, but that it's aligned with the text below it? None of the other drop-downs seem to do it. In this screenshot there are several drop-downs, but only the marker table exhibits this behavior.
It looks like there's a text label on top of the drop down.
Good hunch, this is actually what is going on here. The marker list is a QTreeView Widget with an attached QAbstractItemModel to show the markers. This usually just displays stuff but I am opening persistent editors (the drop-down menus, implemented as a QComboBox) in two columns. I still have the code for showing the same data (which will show up as a label) in the normal QTreeView (would show up if the editors ever got closed but my code keeps them open all the time). This works on Windows and Linux but maybe the macOS implementation is slightly different? I have removed the unnecessary label now (on Linux, this doesn't change anything in the behavior of the marker widget). Can you please try with 67ce671 and report back if this fixed the issue on macOS?
Yep, that fixes it for me!
This can be closed. The MR that was just merged also included your commit that you thought might fix it, and it did.
Thanks for confirming!
LibreVNA Version
LibreVNA Version (64 bit): 1.4.0-7f6b78992 OS: macOS 13.5 CPU Arch: x86_64
Steps to reproduce
The trace and type dropdown is overlayed with all available option![CleanShot 2023-10-31 at 22 22 05](https://github.com/jankae/LibreVNA/assets/20037825/8e90aa24-922c-4ed0-8761-e09eeabbce0b)
Expected behavior
The type and trace for the markers are clearly visible which is selected.
Extra information & Setup and Calibration files
LibreVNA.zip