Use native parent window with fltk widgets to retain Mac menubar of parent application

[anmol....@gmail.com]

In Mac, the menubar is global and a part of all parent windows. So, if I write a plugin in fltk and generate Fl_Window within my plugin it takes over the application menubar.

In order for a simple popup progress bar or a display alert, I need to get the parent window of the application and then create child widgets from it.

From these posts, https://groups.google.com/g/fltkgeneral/c/JHCwXOHwgE4/m/AAGlsXsEn9QJ 

https://groups.google.com/g/fltkgeneral/c/QrTiDHe_gLU/m/m7QxCxARBgAJ 

https://groups.google.com/g/fltkgeneral/c/IMB7BnoeriM/m/pVEDF_zPr_gJ

there is a method partially described to obtain the Mac parent window. How can this be done as an example ? Basically, I want the parent Fl_Window (which I have not created - it already exists as I am making a plugin for another GUI), and add my own widgets.

>>>

// Information used when creating the native window. 
CefWindowInfo window_info; 
#ifdef __APPLE__ 
FLWindow *flwind = (FLWindow*)fl_xid(this->window); 
NSView *view = [flwind contentView]; 
window_info.SetAsChild( view, 0, 0, 500, 500 ); 
#endif 

>>>

In OSX/Cocoa land VST plugins require a reference to NSView, but unfortunately fl_xid() seems to return a reference to NSWindow. Am I on the right track (for the fl_xid part, of course)?

>>>

OSX supports the sub_windows concept something like:
    NSWindow->
        ContentView->
            NSViews->SubViews

[Manolo]

Le dimanche 22 août 2021 à 06:41:25 UTC+2, anmol....@gmail.com a écrit :

In Mac, the menubar is global

correct

and a part of all parent windows.

I don't understand what this means.

So, if I write a plugin in fltk and generate Fl_Window within my plugin it takes over the application menubar.

Try to have fl_open_display() run after your menubar has been created by whatever  non-FLTK toolkit you use.
This way, FLTK won't create its own menubar.

With, FLTK 1.4 you'll also have to call

#include <FL/Fl_Sys_Menu_Bar.H>

Fl_Sys_Menu_Bar::window_menu_style(Fl_Sys_Menu_Bar::no_window_menu);

before fl_open_display() runs. If you don't call fl_open_display() directly, it's called by the

first show() of an FLTK window.

In order for a simple popup progress bar or a display alert, I need to get the parent window of the application and then create child widgets from it.

From these posts, https://groups.google.com/g/fltkgeneral/c/JHCwXOHwgE4/m/AAGlsXsEn9QJ 

https://groups.google.com/g/fltkgeneral/c/QrTiDHe_gLU/m/m7QxCxARBgAJ 

https://groups.google.com/g/fltkgeneral/c/IMB7BnoeriM/m/pVEDF_zPr_gJ

there is a method partially described to obtain the Mac parent window. How can this be done as an example ? Basically, I want the parent Fl_Window (which I have not created - it already exists as I am making a plugin for another GUI), and add my own widgets.

>>>

// Information used when creating the native window. 
CefWindowInfo window_info; 
#ifdef __APPLE__ 
FLWindow *flwind = (FLWindow*)fl_xid(this->window); 
NSView *view = [flwind contentView]; 
window_info.SetAsChild( view, 0, 0, 500, 500 ); 
#endif 

>>>

In OSX/Cocoa land VST plugins require a reference to NSView, but unfortunately fl_xid() seems to return a reference to NSWindow. Am I on the right track (for the fl_xid part, of course)?

>>>

OSX supports the sub_windows concept something like:
    NSWindow->
        ContentView->
            NSViews->SubViews

FLTK doesn't use views but full NSWindow objects  for subwindows. OSX allows an NSWindow to be declared

a subwindow of another NSWindow with this Objective-c message :

    [parent addChildWindow:child ordered:NSWindowAbove];

child is given in FLTK by fl_xid(Fl_Window *window)

and you would have to get the NSWindow object of your toolkit's parent window.

You'll also have to set the child window's frame to position it correctly inside its parent.

[anmol....@gmail.com]

Fl_Sys_Menu_Bar::window_menu_style(Fl_Sys_Menu_Bar::no_window_menu);

This works perfectly and no system menu bar is visible. Is there an option for a menu bar on top of the fltk window ?

- Like in windows ?

So that widgets like Fl_Text_Editor are usable in mac just like in windows.

[Manolo]

Le jeudi 23 septembre 2021 à 09:23:37 UTC+2, anmol....@gmail.com a écrit :

Fl_Sys_Menu_Bar::window_menu_style(Fl_Sys_Menu_Bar::no_window_menu);

This works perfectly and no system menu bar is visible. Is there an option for a menu bar on top of the fltk window ?

- Like in windows ?

So that widgets like Fl_Text_Editor are usable in mac just like in windows.

That's the purpose of FLTK widget Fl_Menu_Bar. Put one such object in each FLTK window containing an Fl_Text_Editor.

[Bill Spitzak]

It would certainly be nice if this "no window menu" behavior was automatic if the fltk program did not try to set the main menu!

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/b9f93413-0989-49ba-90d6-ac4f1464288cn%40googlegroups.com.

[Ian MacArthur]

On 23 Sep 2021, at 18:36, Bill Spitzak wrote:
>
> It would certainly be nice if this "no window menu" behavior was automatic if the fltk program did not try to set the main menu!

Yes - this is one of those tricky ones... I go back and forth a bit on what’s best.

The current way, I have code that #ifdef’s between setting up to use Fl_Sys_Menu_Bar (on OSX/macOS) and Fl_Menu_Bar (everywhere else) and adjusts the window height and widget origin slightly (by one menu bar height) accordingly - which is a PITA to set up but works well thereafter... (Basically, if you use Fl_Sys_Menu_Bar on WinXX or X11, you actually get a “plain” Fl_Menu_Bar, but then you need to make your window taller to accommodate it - or shorter on macOS, depending on how you look at that!)

It would be nice if it did this “magically” for me. Except... sometimes I want the Fl_Menu_Bar style everywhere, even on macOS, so I can see that there may be no “one size fits all” solution to this, really.



As a tangent, I also looked in the past at making Fl_Sys_Menu_Bar do the “system menu” thing on X11 systems using Ubuntu Unity or gnome-3 style desktops, that also have that menu style... but I got nowhere and my head may have exploded trying to figure it out...

[Manolo]

Le jeudi 23 septembre 2021 à 19:37:00 UTC+2, spitzak a écrit :

It would certainly be nice if this "no window menu" behavior was automatic if the fltk program did not try to set the main menu!

I'm not sure to grasp what exactly is meant here, but I've seen one situation that could be improved :

when FLTK is used on macOS while another toolkit creates the mac system menu.

The git repository for 1.4 now supports such situation without asking the user to set explicitly

     Fl_Sys_Menu_Bar::window_menu_style(Fl_Sys_Menu_Bar::no_window_menu);

[Bill Spitzak]

I think we are talking about the same thing. Basically, if the FLTK program does not make any calls to Fl_Sys_Menu_Bar, then the menu bar on the top of the mac is left absolutely unchanged (either as whatever another toolkit set it to, or whatever the default behavior of Mac is when you don't do anything). It sounds like the current FLTK messes with the top menu when the programmer does nothing, which I don't think is correct behavior.

For avoiding having to change your code depending on the platform, I think a window subclass (MainWindow?) would work. If a Sys_Menu_Bar is set up on a system that does not have such a menubar, these windows move all the widgets down sufficiently and add a regular MenuBar. This would allow the programmer to select what window(s) get menu bars, rather than a single one or all of them.

--

You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/791c7acc-0cbc-4782-8d91-91307e1a5860n%40googlegroups.com.

[Albrecht Schlosser]

On 9/24/21 7:45 PM Bill Spitzak wrote:
> I think we are talking about the same thing. Basically, if the FLTK
> program does not make any calls to Fl_Sys_Menu_Bar, then the menu bar
> on the top of the mac is left absolutely unchanged (either as whatever
> another toolkit set it to, or whatever the default behavior of Mac is
> when you don't do anything). It sounds like the current FLTK messes
> with the top menu when the programmer does nothing, which I don't
> think is correct behavior.

I'm not sure about this. For instance, the test/demo app seems to add
'about demo' and 'Print Front Window' items which I think are generally
useful.

I'm not a regular Mac user and didn't explore the Sys_Menu_Bar features
yet, so my observations may not be helpful.

> For avoiding having to change your code depending on the platform, I
> think a window subclass (MainWindow?) would work. If a Sys_Menu_Bar is
> set up on a system that does not have such a menubar, these windows
> move all the widgets down sufficiently and add a regular MenuBar. This
> would allow the programmer to select what window(s) get menu bars,
> rather than a single one or all of them.

+1 ... basically ...

This sounds sensible. However I would rather use an Fl_Window method -
maybe main_window() or menu_bar_window() - since we have more than one
window class that needs this (Fl_Window, Fl_Double_Window, ...). Hard to
tell which one to derive the 'MainWindow' class from.

I'm also not sure what would be "sufficient" to add a regular MenuBar.
This should likely be a user option as well. I know from my own
experience that I had a program where the menubar contained icons which
made it taller than a "normal" menubar.

OTOH I could also imagine an option that does "the opposite": think of a
"standard" (i.e. non-macOS) program that includes a standard menubar. An
option to "convert" this Fl_Menu_Bar to a system menubar *and* move all
the other widgets up by the height of the given menubar *and* decrease
the window height by the same amount would make this application
cross-platform w/o changing any code.

Again, I'm not sure if this would be feasible for a "real" program
because I don't know much about the different menu bar approaches on
macOS and other platforms.

There are maybe more (better?) options to make a "standard" application
macOS (ie. system menubar) aware w/o having to use platform specific
code, different widget positions, and window sizes. At least I hope so.