GrandOrgue / grandorgue

GrandOrgue software
Other
172 stars 43 forks source link

Stops window issues #1961

Closed willeke1234 closed 2 weeks ago

willeke1234 commented 3 months ago

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:

  1. Load a sample set and open the Stops window 1 Sample Set A
  2. Load another sample set and open the Stops window 2 Sample Set B Sample set 2 at minimum size: 3 Sample Set B minimum size Load sample set 1 again: 4 Sample set A again

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. Screenshot 2024-08-04 at 3 24 24 PM

GrandOrgue v3.14.3-0.26 macOS 14.3.1

larspalo commented 3 months 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.

oleg68 commented 3 months ago

@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?

willeke1234 commented 3 months ago

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.

oleg68 commented 2 weeks ago

@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 ?

willeke1234 commented 2 weeks ago

@oleg The issues are fixed, thanks! Is the new layout intentional?

oleg68 commented 2 weeks ago

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?

willeke1234 commented 2 weeks ago

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?

oleg68 commented 2 weeks ago

@willeke1234 Could you explain more the difference in the layouts? The only difference I know is the absence of the button bar.

oleg68 commented 2 weeks ago

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.

willeke1234 commented 2 weeks ago

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: Screenshot 2024-11-06 at 15 33 12

New: Screenshot 2024-11-06 at 15 34 23

oleg68 commented 2 weeks ago

@willeke1234 Is the new variant better?