Programmatically open a Fl_Sys_Menu_Bar sub menu?

[Brian Larsen]

Is there a way to *programmatically* cause a Fl_Sys_Menu_Bar to open?
Say a menu bar has "File  Edit  Search" and I left click "File" it
opens the File sub menu. I would like to cause that same thing from
a subroutine.

[Manolo]

It's possible to do it for an Fl_Menu_Bar as follows :

  Fl_Menu_Bar *bar = ...
  const Fl_Menu_Item *v = bar->find_item("File");
  v = bar->menu()->pulldown(bar->x(), bar->y(), bar->w(), bar->h(), v, bar, 0, 1);
  bar->picked(v);

This works well also for an Fl_Sys_Menu_Bar on non macOS platforms,

and also produces something on macOS where the menu is in the system menu bar,

but not what one would probably expect.

I'll see if something can be done to open access to this feature.

[Brian Larsen]

Thank you very much, that is super helpful. I didn't realize I needed to invoke pulldown().

I'm currently only running on Linux, so I could use Fl_Menu_Bar, but I though it might

be better in the long run to use Fl_Sys_Menu_Bar.

[Manolo]

Le lundi 13 mai 2024 à 10:12:11 UTC+2, Brian Larsen a écrit :

Thank you very much, that is super helpful. I didn't realize I needed to invoke pulldown().

I'm currently only running on Linux, so I could use Fl_Menu_Bar, but I thought it might

be better in the long run to use Fl_Sys_Menu_Bar.

FYI: class  Fl_Sys_Menu_Bar is nothing but class Fl_Menu_Bar on non-macOS platforms

(Linux included). FLTK introduces a difference between these 2 classes only under macOS

where Fl_Sys_Menu_Bar allows to create and use a proper macOS system menu bar at the 

top of the display.

[Manolo]

A new API has been added to FLTK to handle this feature.

Its's Fl_Menu_Bar::play_menu(const Fl_Menu_Item*)

and works for all menu bars, that is, Fl_Sys_Menu_Bar included

and all platforms, macOS included.

[Brian Larsen]

Cool, I was fine with the manual steps you gave me previously, but the new API will 

mean other people won't have to figure out those steps. I periodically download

the latest 1.4.x nightly version so I will try out the new API once I have a version

that includes it. Thank you.

[Brian Larsen]

I realized the 1.4.x snapshots are not as frequent as I thought, so I just cloned the repo.

I changed my code to use play_menu() and it works as expected on Ubuntu 22.04. Oh

and I build FLTK with clang++ 14.0.0. 

There is one funny issue, but it happens even with the old code. I haven't tried making 

a minimal program to test this yet, so I don't expect anyone to spend time on it. I'm

mainly curious if it's a known issue. 

I have 2 monitors and when I use my hotkey (ALT+M) to cause the menu to open, the 

popup menu is displayed on the monitor where my mouse cursor is, which might not 

be the same monitor the app is running on. It's possible I've done something wrong 

since I've sub-classed FL_Window and am using handle() to catch keydown and mouse 

events. 

Anyway, thanks for creating an easy way to do what I originally asked about!

[Manolo]

Le jeudi 23 mai 2024 à 10:12:33 UTC+2, Brian Larsen a écrit :

I have 2 monitors and when I use my hotkey (ALT+M) to cause the menu to open, the 

popup menu is displayed on the monitor where my mouse cursor is, which might not 

be the same monitor the app is running on. It's possible I've done something wrong 

since I've sub-classed FL_Window and am using handle() to catch keydown and mouse 

events.

That should be fixed, hopefully, with commit 0a6610c of the FLTK git repo.

 

[Brian Larsen]

I pulled the latest changes from git including 0a6610c. That change didn't help my case, but

the nice thing is that it showed me where to look in the code. I don't know the FLTK source

code at all, but after a fair bit of trial and error I found something that works, at least for me.

I think the previous issue (even before your change) is that 

Fl_Window_Driver::driver(this)->menu_window_area() is based on the mouse position, which

is exactly what we *don't* want. I changed that to use Fl::screen_xywh() passing in the menu

X, Y instead of mouse x, y.

I hope it's ok to attach a git patch, it's been a looong time since I've done a pull request for any

repo, plus it's really late here :)

[Manolo]

Le jeudi 23 mai 2024 à 18:44:57 UTC+2, Brian Larsen a écrit :

I pulled the latest changes from git including 0a6610c. That change didn't help my case, but

the nice thing is that it showed me where to look in the code. I don't know the FLTK source

code at all, but after a fair bit of trial and error I found something that works, at least for me.

I think the previous issue (even before your change) is that 

Fl_Window_Driver::driver(this)->menu_window_area() is based on the mouse position, which

is exactly what we *don't* want. I changed that to use Fl::screen_xywh() passing in the menu

X, Y instead of mouse x, y.

Unfortunately your change proposal isn't correct because it shunts the use of an

overridden version of the menu_window_area() member function for the

Wayland platform. By the way, I would believe the issue doesn't hold under Wayland.

We agree that what needs to be done is to prevent function menu_window_area()

from choosing a display based on the mouse position. That's exactly what

commit 0a6610c does because function menu_window_area() works based

on the mouse position only if its last argument is -1, and that's what the commit changes

(see the code of Fl_Window_Driver::menu_window_area() in file src/Fl_Window_Driver.cxx).

Thus, what we have to do is clarify why commit 0a6610c doesn't work for you.
In my hands it does. Do you have 2 screens with diverse resolutions (i.e., one HighDPI,

one LowDPI)?

[Albrecht Schlosser]

On 5/24/24 10:28 Manolo wrote:

Le jeudi 23 mai 2024 à 18:44:57 UTC+2, Brian Larsen a écrit :

I pulled the latest changes from git including 0a6610c. That change didn't help my case, ...

We agree that what needs to be done is to prevent function menu_window_area()

from choosing a display based on the mouse position. That's exactly what

commit 0a6610c does because function menu_window_area() works based

on the mouse position only if its last argument is -1, and that's what the commit changes

(see the code of Fl_Window_Driver::menu_window_area() in file src/Fl_Window_Driver.cxx).

Thus, what we have to do is clarify why commit 0a6610c doesn't work for you.
In my hands it does.

Brian, are you using configure/make or CMake for your FLTK build?

There are chances that the dependencies are not complete *if* you use configure/make to build FLTK and that recompilation after updating to the latest commit didn't recompile the file in question. Hence, if you use configure, please make sure that you do a full rebuild (make clean;make).

CMake builds (even with Makefile's) don't suffer from these dependency issues and should rebuild reliably after pulling changes. Therefore I strongly recommend to use CMake (and there are even more reasons to do so).

BTW: the *weekly* snapshots are created every Friday morning (about 9am UTC +/- 1 hour) and announced on the main web site.

[Brian Larsen]

Manolo,
My monitors are different sizes, but using the same resolution. The DPIs will
be a little different; Here is the output of "xrandr | grep -w connected"
DP-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 544mm x 303mm
DP-4 connected primary 1920x1080+1920+0 (normal left inverted right x axis y axis) 600mm x 340mm

Just to make sure we're talking about the same thing, my issue is when the
mouse is hovering over the opposite screen. Obviously if I click on the
opposite screen my app no longer has focus so there can't be any problem.

I need to revert my local change and retest with some debug output. I'm
pretty sure that in my case the screen number was being returned as -1
when the mouse was hovering over the opposite screen. I'll try to provide 

some debug info a bit later today.

Albrecht,
I'm using confgure/make. My process for testing changes was
  - Change the code
  - FLTK: make clean; make
  - FLTK: sudo make install
  - My App: make clean; make
I definitely had Manolo's last change, I saw it in the source code and
I could see by my debug output that my local changes were being used.

[Brian Larsen]

For reference my primary monitor (screen 0) is on the right and the
secondary monitor (screen 1) is on the left.

With commit 0a6610c, play_menu() always opens the menu on screen 0.
I tried all 8 combinations involving
  - The terminal where the app is started can be on screen 0 or 1
  - The app opens on 0 or 1 (because of its previously saved position)
  - The mouse can hover over 0 or 1

I added a printf in menuwindow(). When play_menu() occurs menuwindow() is
called 2 times. The first time 'n' (returned by Fl::screen_num()) is the correct
value for the screen where the app is displayed. The second time 'n' is always 0.

Here is an example when the app is on screen 1:
*** menuwindow(): n=1, X=479, Y=29, Wp=1105, Hp=25, scr_x=0, scr_y=0, scr_w=1645, scr_h=925
*** menuwindow(): n=0, X=482, Y=54, Wp=1, Hp=0, scr_x=1645, scr_y=0, scr_w=1645, scr_h=925

Does that help at all or do you need me to try to create a minimal example
to see if the problem also occurs with that?

[Brian Larsen]

Oh, I just tested with examples/menubar-add, it has the same issue. Run it
and use one of the shortcuts; Alt+F, Alt+E or Alt+H.

[Manolo]

Brian: the issue should be fixed with new commit 00dc350

[Brian Larsen]

Excellent, that does fix the issue. Thank you.

[Brian Larsen]

BTW, I just added Fl_Native_File_Chooser to my app and it has the same problem.

Since this issue seems very similar I added it to this conversation. Is that ok or is

it better to create a new conversation?

[Manolo]

and what is this problem?

[Brian Larsen]

Similar to the menu problem. Using a hotkey (like Ctrl+O) to open the File Chooser causes it

to open on whatever monitor the mouse is hovering over, which might not be the monitor

the app is open on.

[Manolo]

That is not something under FLTK's control

[Greg Ercolano]

On 5/24/24 10:22, Brian Larsen wrote:

Similar to the menu problem. Using a hotkey (like Ctrl+O) to open the File Chooser causes it to open on whatever monitor the mouse is hovering over, which might not be the monitor the app is open on.

Hmm, while I don't work with multiple monitor setups much, that behavior doesn't sound bad to me for the Fl_Native_File_Chooser dialog window, as dialogs don't have to be "attached" to the application the way a menu positing does.

This positioning seems consistent with single window situations where posting dialogs like (fl_message) tries to open under the mouse is, so the dialog can be easily navigated without having to swing the mouse around just to enter it. At least that's the behavior on window managers that support window positioning hints from the app. I take it wayland window managers perhaps do not support this, as they seem to like to control where windows are positioned, and may ignore the "hints" from the app.

I would think it maybe even confusing if it opened dialogs in a window that the mouse wasn't in.

[Brian Larsen]

Oh, of course, the Fl_Native_File_Chooser by design is a detached/floating window so it's current 

operation is fine. I was too focused on the previous issue with play_menu() and thought that

Fl_Native_File_Chooser had a similar issue, but that was incorrect. So this is not an issue.