Re: [racket-users] problem of gui layout using side-by-side frames

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

-- 
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/e7a8ecff-7070-4943-8d2c-08cb4790c8fbn%40googlegroups.com.

Re: [racket-users] problem of gui layout using side-by-side frames

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

-- 
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/F5B4FF9E-AF69-4EB5-956D-7F220B2C1A51%40biomantica.com.

Re: [racket-users] problem of gui layout using side-by-side frames

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

-- 
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/A7B7013B-1A5D-472E-83D4-9E145DF3E6B4%40biomantica.com.

Re: [racket-users] problem of gui layout using side-by-side frames

[George Neuner]

On 8/12/2021 2:52 PM, Jens Axel Søgaard wrote:
Den tor. 12. aug. 2021 kl. 20.44 skrev George Neuner 
mailto:gneun...@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


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

--
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/edefed61-4303-b56c-3d58-109789f69565%40comcast.net.

Re: [racket-users] problem of gui layout using side-by-side frames

[Jens Axel Søgaard]

Den tor. 12. aug. 2021 kl. 20.44 skrev George Neuner :

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

-- 
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/CABefVgxCaZQB%3Dq_2cO1U8%3DGAFMmB16ii0-OVuFYxPv1HSQb4_g%40mail.gmail.com.

Re: [racket-users] problem of gui layout using side-by-side frames

[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

--
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/2eb0a4bd-c71b-107b-dce8-ff33f26d7baf%40comcast.net.

Re: [racket-users] problem of gui layout using side-by-side frames

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

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.

Re: [racket-users] problem of gui layout using side-by-side frames

[George Neuner]

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/5c29e25d-aa1d-1326-2d3e-ca6b3cbe9175%40comcast.net.

Re: [racket-users] problem of gui layout using side-by-side frames

[Andrew Beyer]

On Wed, Aug 11, 2021 at 7:44 PM Don Green  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.

-- 
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/CACG9B3GC3EQ39bovMxiYFouf%2BsC63xVUPaJb2qQYHgAKTbW-PA%40mail.gmail.com.