Closed willeke1234 closed 2 weeks ago
@oleg68 It might be a shot in the dark and not at all helpful in this case, but I've noticed that the macOS port is a bit sensitive with the dialogs. They tend to behave better if a wxPanel is placed on them as top level child.
The scrollbar issue might be because no size event is fired at creation, but something seems to be a bit off with the initial layout when it's too large anyway.
Please ignore the comments if not applicable in this case.
@willeke1234
The Stops menu item doesn't bring the Stops window to the front if it's already open and behind a panel but it is resized and moved to the previous position. The Stops window isn't in the macOS Window menu. The other windows in the Audio/Midi menu behave the same.
Do you have the same behavior with the Organ Settings window?
As mentioned here, the initial position and size of the Stops window may be wrong. If the position/size of the Stops window isn't saved then the position/size should be the default position/size instead of the last used position/size of the previous sample set.
What happens if you resize the stops window and do File->Save
, then load another organ, resize the window differently and load the previous organ again? Are the saved size and position applied?
Do you have the same behavior with the Organ Settings window?
Yes, and the MIDI Objects window. My guess: GOView::ShowView
does m_wnd->Raise()
, GODialogCloser::ShowAdvanced
doesn't.
What happens if you resize the stops window and do File->Save, then load another organ, resize the window differently and load the previous organ again? Are the saved size and position applied?
The saved size and position are sometimes applied and it might be the position where the Stops window was closed, not where is was saved. Steps to reproduce: open Stops window, move, close, open, move, save, reload.
@willeke1234 I tried to fix all the Stop Window issues you mentioned.
Unfortunally I don't have capability to test it in macOs with a small screen. Could you test the build https://github.com/oleg68/GrandOrgue-official/actions/runs/11669830166 ?
@oleg The issues are fixed, thanks! Is the new layout intentional?
I had to reimplement the stops window based on wxFrame instead of wxDialog for fixing the issues. It caused the layout change.
@willeke1234 what layout do you find better: the old or the new?
I prefer the old layout, it's more compact and it looks a bit more organized. The new layout doesn't work very well with VoiceOver. Did you reimplement because of the position/size or the scroll bars?
@willeke1234 Could you explain more the difference in the layouts? The only difference I know is the absence of the button bar.
Did you reimplement because of the position/size or the scroll bars?
The main reason is lack of support of the main windows menu in dialogs.
Could you explain more the difference in the layouts?
The Width of the columns was as small as possible, now they are all the same size, including the empty columns. The checkboxes were at the top, now they are vertically stretched. When I use the left or right arrow key with VoiceOver, it is unpredictable which column is selected. If one column is too tall to fit on the screen, the other columns will be stretched so that they don't fit either.
Old:
New:
@willeke1234 Is the new variant better?
The Stops menu item doesn't bring the Stops window to the front if it's already open and behind a panel but it is resized and moved to the previous position. The Stops window isn't in the macOS Window menu. The other windows in the Audio/Midi menu behave the same.
As mentioned here, the initial position and size of the Stops window may be wrong. If the position/size of the Stops window isn't saved then the position/size should be the default position/size instead of the last used position/size of the previous sample set. Steps to reproduce:
If the contents of the Stops window doesn't fit on the screen then the scroll bars are missing. They appear when the window is resized.
GrandOrgue v3.14.3-0.26 macOS 14.3.1