problem of gui layout using side-by-side frames

[Don Green]

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.

[Andrew Beyer]

On Wed, Aug 11, 2021 at 7:44 PM Don Green <infodeve...@gmail.com> wrote:
> I am currently of the belief that I should refrain from using side-by-side frames.

Maybe? Almost all desktop systems provide some way for users to easily
arrange common setups like this... do you need to manage this from
within your application at all or can you just punt it out to the
windowing system? (This has the added benefit of letting users make
other choices that might make more sense in unusual setups like tall
vertical monitors, multiple monitors that aren't the same resolution,
aren't aligned, etc... where strict side-by-side may not work or be
desirable.)

> 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.

My racket/gui experience is limited and rusty, so I'm not going to
comment on specifics. What I will say though, is that it seems to me
like you've been XY-ing this problem the last few threads and might
benefit from taking a step back. You may be more likely to get better
input if you could give a description of what you're ultimately trying
to achieve rather than suggesting solutions and problem solving the
little details out of context.

[George Neuner]

> 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.

[kamist...@gmail.com]

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.

[George Neuner]

On 8/12/2021 1:39 PM, kamist...@gmail.com wrote:
> 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.

If I understand correctly, Don seems to want menus in his side-by-side
"panels".

Currently a menubar must be a child of a frame - so, to have menus,
Don's "panels" must be frames.  But that is ok, because a frame can be a
child of another frame.

Allowing (un)docking is a good idea (if applicable), but switching
between panels and frames is unnecessarily complicated ... a frame can
be drawn floating or docked, resizeable or not, with or without borders,
system menu, captions, toolbar, menubar, etc. - so visually it can be
made to /appear/ as if a panel when docked, and as if a window when
undocked.  It's a lot easier to just redraw the frame(s) with different
settings than to try to maintain multiple different object hierarchies
or to try to reassign parentage on the fly (which is mistake prone if
many functions are handled by the parent).

YMMV,
George

[Jens Axel Søgaard]

Den tor. 12. aug. 2021 kl. 20.44 skrev George Neuner <gneu...@comcast.net>:

If I understand correctly, Don seems to want menus in his side-by-side
"panels".

Are we talking menu bar menus or contextual menus?

On macOS the menu bar menu belongs to the application and not a window.

https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-anatomy/

/Jens Axel

[George Neuner]

Don will have to answer that definitively.

But quoting from one of his previous posts:

"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."

"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 than the single top-level frame."

That tells me zip about what platform he is targeting, because MacOS, Windows, and several of the Linux display managers all support some notion of a vertical taskbar.

However it does suggest that he wants menubar menus.  I don't use (or have available to check) MacOS, so I'm don't know what limitations may be on 'root menubars, or whether a child frame can have its own internal menubar (which is possible on Windows and Linux).

George

[James Platt]

On Aug 12, 2021, at 2:52 PM, Jens Axel Søgaard wrote:

> Are we talking menu bar menus or contextual menus?
>
> On macOS the menu bar menu belongs to the application and not a window.

The macOS menu bar is also contextual. It changes depending on what is selected in the application. IIRC, according to Apple's HIG, all items which appear in contextual menus are supposed to also appear as contextual items in the application's menu bar. According to Apple, contextual (right-click) menus are supposed to only be shortcuts and not something which your application depends on. All functions of a program are supposed to be discoverable by looking through the menu bar. Contextual items in the menu bar get grayed out, rather than disappear, so that you know the function exists even if nothing appropriate is selected at the time.

[James Platt]

On Aug 12, 2021, at 3:47 PM, George Neuner wrote:

> However it does suggest that he wants menubar menus. I don't use (or have available to check) MacOS, so I'm don't know what limitations may be on 'root menubars, or whether a child frame can have its own internal menubar (which is possible on Windows and Linux).

I think Apple's position on this is that you don't need separate menus for separate windows because the application menu bar is contextual. Instead, you have it modify itself to fit the context of whatever window has focus. Having said that, you can certainly put menu widgets on any frame you want and, probably, with some work, put them together to look like a menu bar.

[kamist...@gmail.com]

Allowing (un)docking is a good idea (if applicable), but switching
between panels and frames is unnecessarily complicated ... a frame can
be drawn floating or docked, resizeable or not, with or without borders,
system menu, captions, toolbar, menubar, etc. - so visually it can be
made to /appear/ as if a panel when docked, and as if a window when
undocked.  It's a lot easier to just redraw the frame(s) with different
settings than to try to maintain multiple different object hierarchies
or to try to reassign parentage on the fly (which is mistake prone if
many functions are handled by the parent).

From my (limited but some) experience of working with rackets gui, I definitively would prefer reparenting (or maybe even dynamic reconstruction) over,

trying to syncronize window movements with other floating windows. Maybe create some kind of mixin for un-/dockable panels or just a single class that you can use multiple times,

but haven't worked out the details just a bit similar to old stuff I did.

What you describe makes me think that maybe you describe this from a perspective of using windows apis directly?
Where that may be easier?

Anyways in the end pick an approach run with it make it work, in general this thread seems to vague / there isn't a clear objective and it runs into multiple directions...