I think instead of fidgeting around with OS dependent stuff to align frames side by side, I would take another approach (inspired by other applications):
1. per default the application is just a big window with multiple sections divided with panels, splits, tabs, etc. 2. some of those areas might be useful as sepparate frames for some users, add a button "undock" 3. clicking that button creates a frame and reparents the panel into the newly created frame 4. button changes to "dock" 5. clicking it reparents the panel back to where it was originally and deletes the frame There might be some coding needed to save and restore state about what has been undocked and the last positions of the windows, so that can be restored when the application is restarted. (although some OS's may restore window positions themselves if they have unique titles??) What I like about that approach is that it gives the user choice and can be ignored if its not needed. gneuner2 schrieb am Donnerstag, 12. August 2021 um 15:17:34 UTC+2: > > On 8/11/2021 10:44 PM, Don Green wrote: > > > > When I specify 2 frames to be side-by-side using racket/gui, I believe > > I would have no problem if all my prospective client platform did not > > have a vertical Operating System taskbars. > > Since I do have such a taskbar I must use code that takes the width of > > the taskbar into account. > > Since I intend to distribute to others who may have: > > a) no vertical taskbar; or > > b) a wider vertical taskbar; or > > c) multiple vertical taskbars > > no single offset can be used and it is outside the scope of the > > racket/gui to know what the offset would need to be. > > I am currently of the belief that I should refrain from using > > side-by-side frames. > > The upshot is that I can then no longer use menus either because menus > > can only exist in frames and I would need more that the single > > top-level frame. > > Any suggestions? > > I am currently thinking I should use the panel-tab with a couple of > > panels each containing an editor-canvas and place buttons on these > > panels instead of using menus. -- > > I don't quite understand the problem - a frame can have another frame as > its parent (supporting Windows "multiple document interface"). If you > need side-by-side frames with menus, then why not do that inside an > enclosing top-level frame? > > Also pop-up menus have no parent and can be used anywhere. > > And if you really are ambitious, you could make the menubar% class work > within panels as well as frames. This has been mentioned occasionally > over the years, but AFAIK nobody ever has bothered to look into it. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/e7bcc139-ebbb-4842-a7e7-65e6f2967b24n%40googlegroups.com.
