Menu - render over child window

[Caspian Merlin]

Child window is a DoubleWindow which has set_on_top() called on it after creation.

The menu bar is part of the main window.

As you can see, the menu correctly renders over the child window - on Linux. But on Windows, it doesn't: it's obscured by the child window.

Presumably this is to do with low-level implementation of how the menu works - is it possible to get it to behave like this on Windows as well?

[Albrecht Schlosser]

On 3/25/25 18:51 Caspian Merlin wrote:
> Child window is a DoubleWindow which has set_on_top() called on it
> after creation.

There is no 'set_on_top()' method in FLTK. Where did you get it from,
and what does it do? Is this implemented for all FLTK platforms?

> The menu bar is part of the main window.
> As you can see, the menu correctly renders over the child window - on
> Linux. But on Windows, it doesn't: it's obscured by the child window.
> Presumably this is to do with low-level implementation of how the menu
> works - is it possible to get it to behave like this on Windows as well?

We can't tell, as long as we don't know what your set_on_top() method
does. Presumably it forces the child window to be on top, even over our
menu windows. Maybe the set_on_top() method is not at all implemented on
Linux (X11, Wayland) and therefore the menu works as expected whereas
the child window it "on top" on Windows because of your (or anyone
else's) implementation of that method/function...

But this is only a guess. We need more info.

[imm]

On Tue, 25 Mar 2025, 17:57 Caspian Merlin wrote:.

As you can see, the menu correctly renders over the child window - on Linux. But on Windows, it doesn't: it's obscured by the child window.

See where? Did you intend to post a screenshot or some code?

I don't seem to have either.

Anyway, as Albrecht said, the method you described doesn't match any FLTK one.

What effect are you actually intending to achieve?

Perhaps we can determine the "FLTK way" to attain the desired result?

If you can describe what it is you want to do, we can certainly suggest some ways to try, but what you have outlined so far doesn't really help us to help you!
--
Ian
From my Fairphone FP3

[imm]

Ah, hold on: are you using Mo's Rust wrappers?

That might make more sense - be useful to have mentioned this was Rust (assuming that it is, of course!)

Even then, it'd still be better to describe what you want to achieve, because the effects you describe in the OP don't really clarify it for me.

[Albrecht Schlosser]

On 3/25/25 19:42 imm wrote:

On Tue, 25 Mar 2025, 17:57 Caspian Merlin wrote:.

As you can see, the menu correctly renders over the child window - on Linux. But on Windows, it doesn't: it's obscured by the child window.

See where? Did you intend to post a screenshot or some code?

I don't seem to have either.

I got it, reposting for completeness. I hope you, Ian, get this one.





BTW, I checked the Google web interface and I don't see it there. Weird.

[Greg Ercolano]

On 3/25/25 11:42, imm wrote:

On Tue, 25 Mar 2025, 17:57 Caspian Merlin wrote:.

As you can see, the menu correctly renders over the child window - on Linux. But on Windows, it doesn't: it's obscured by the child window.

See where? Did you intend to post a screenshot or some code?

I don't seem to have either.

    Hmm, the screenshot shows up in the mailing list (in Thunderbird anywayh) as an inline image,
    but it's not showing up on the web interface for google groups or on fltk's web interface.

    I think the web interfaces to the group only support attachments, or inline images arranged
    as attachments. But inlines done with <img src="data:image..raw_image_data"> is apparently
    not supported.

[Caspian Merlin]

Sorry - I pasted an image into the inital message, but it appears when it was submitted this wasn't preserved. I'll try attaching it instead.

Yes, I'm using Mo's Rust wrapper.

The main application window consists of a MenuBar at the top, to be used as a window menu, and a GLWindow that occupies the rest of the window.

Some of the menu items cause smaller, child windows to open. I want those windows to display on top of the main window even if the main window has the focus.

If a child window is newr the top of the main window and you click one of the items on the main window's MenuBar, the drop-down menu may overlap with the child window. The behaviour I want is that the menu draws over the entire child window - including the OS / Window Manager-specific title bar etc. This happens by default on my Linux box (KDE Plasma), but not on Windows 11. On Windows, the menu draws underneath the child window because the child window is on top of everything. However, programs that use the Win32 API to draw menu bars *do* render the menus on top of any other windows, even if those windows are on top of the window from which the menu is being drawn.

The attached screenshot is on Linux, KDE Plasma, which shows the intended behaviour. On Windows, the menu draws underneath the child window.

[Bill Spitzak]

My guess is that FLTK should turn on “always on top” for menu windows

On Mar 25, 2025, at 12:07 PM, Caspian Merlin <cas...@merlins.online> wrote:

Sorry - I pasted an image into the inital message, but it appears when it was submitted this wasn't preserved. I'll try attaching it instead.

Yes, I'm using Mo's Rust wrapper.

The main application window consists of a MenuBar at the top, to be used as a window menu, and a GLWindow that occupies the rest of the window.

Some of the menu items cause smaller, child windows to open. I want those windows to display on top of the main window even if the main window has the focus.

If a child window is newr the top of the main window and you click one of the items on the main window's MenuBar, the drop-down menu may overlap with the child window. The behaviour I want is that the menu draws over the entire child window - including the OS / Window Manager-specific title bar etc. This happens by default on my Linux box (KDE Plasma), but not on Windows 11. On Windows, the menu draws underneath the child window because the child window is on top of everything. However, programs that use the Win32 API to draw menu bars *do* render the menus on top of any other windows, even if those windows are on top of the window from which the menu is being drawn.

The attached screenshot is on Linux, KDE Plasma, which shows the intended behaviour. On Windows, the menu draws underneath the child window.

<Screenshot_20250325_190318-1.png>

On Tuesday, March 25, 2025 at 6:50:07 PM UTC Ian MacArthur wrote:

Ah, hold on: are you using Mo's Rust wrappers?

That might make more sense - be useful to have mentioned this was Rust (assuming that it is, of course!)

Even then, it'd still be better to describe what you want to achieve, because the effects you describe in the OP don't really clarify it for me.

--
Ian
From my Fairphone FP3
   

On Tue, 25 Mar 2025, 18:42 imm, <imaca...@gmail.com> wrote:

On Tue, 25 Mar 2025, 17:57 Caspian Merlin wrote:.

As you can see, the menu correctly renders over the child window - on Linux. But on Windows, it doesn't: it's obscured by the child window.

See where? Did you intend to post a screenshot or some code?

I don't seem to have either.

Anyway, as Albrecht said, the method you described doesn't match any FLTK one.

What effect are you actually intending to achieve?

Perhaps we can determine the "FLTK way" to attain the desired result?

If you can describe what it is you want to do, we can certainly suggest some ways to try, but what you have outlined so far doesn't really help us to help you!
--
Ian
From my Fairphone FP3

--
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 visit https://groups.google.com/d/msgid/fltkgeneral/f87942ba-2179-47df-b47a-c81e2ad66c12n%40googlegroups.com.
<Screenshot_20250325_190318-1.png><Screenshot_20250325_190318-1.png>

[imm]

Albrecht; I still didn't see the picture when you reposted it.

But I do when it was reposted as an attachment.

Which brings me to: That just looks like all kinds of wrong.

If the "child" windows have title bars and border decorations drawn by the WM, then they are fully windows in their own right, and there's no circumstance in which it makes sense for them to appear over another window, but underneath that window's menu drop-down. Even if they are modal (or non-modal, I suppose) then I don't think I'd expect them to be drawn over the "main" window whilst being under the "main" window's menu... Just seems weird.

Is window modality what the Rust "on-top" function is setting? I don't know the Rust code - Mo?

Mind you, the docs seem to suggest you apply the "on-top" after the window is shown, and I don't think you can change window modality whilst it's shown, can you? 

So maybe it's not modality at all but something else?

If the "child" windows are truly subwindows I'd not expect them to have any WM decorations at all, so I assume these can't be subwindows then.

Do you want them to have WM decorations?

[Caspian Merlin]

If the "child" windows have title bars and border decorations drawn by the WM, then they are fully windows in their own right, and there's no circumstance in which it makes sense for them to appear over another window, but underneath that window's menu drop-down. Even if they are modal (or non-modal, I suppose) then I don't think I'd expect them to be drawn over the "main" window whilst being under the "main" window's menu... Just seems weird.

Hmm, this is the behaviour I would expect. Imagine you've popped out a panel or toolbar in an IDE or office program - it often does become a top-level OS window, complete with titlebar and decorations. It's set always to be on top of the main window (otherwise it would disappear behind it as soon as you interact with the main window). Equally, if you select the 'File' menu of the main window, it'd be annoying if the menu drew underneath the widget you'd popped out. See attached pic from LibreOffice Writer, where the 'Tip of the Day' window displays above the main window, but the main window's menus display above it.

Is window modality what the Rust "on-top" function is setting? I don't know the Rust code - Mo?

Mind you, the docs seem to suggest you apply the "on-top" after the window is shown, and I don't think you can change window modality whilst it's shown, can you? 

So maybe it's not modality at all but something else?

I suspect they're not really "child" windows in the true sense of the word - they're windows created in the same was as the main window.

I've had a look at the fltk_rs source - the set_on_top functionality calls OS specific APIs to hint to the window manager that the window should be displayed on top of other windows (even those drawn by other processes).

In Windows it calls SetWindowPos and passes in HWND_TOPMOST. In X11 it uses _NET_WM_STATE_ABOVE.

 

If the "child" windows are truly subwindows I'd not expect them to have any WM decorations at all, so I assume these can't be subwindows then.

Do you want them to have WM decorations?

I would, ideally, as I'd like it to be possible to drag them outside the main window if desired.

[Caspian Merlin]

Including aforementioned screenshot here as an attachment.

[Greg Ercolano]

On 3/25/25 17:21, Caspian Merlin wrote:

If the "child" windows have title bars and border decorations drawn by the WM, then they are fully windows in their own right, and there's no circumstance in which it makes sense for them to appear over another window, but underneath that window's menu drop-down. Even if they are modal (or non-modal, I suppose) then I don't think I'd expect them to be drawn over the "main" window whilst being under the "main" window's menu... Just seems weird.

Hmm, this is the behaviour I would expect.

    Interesting -- whatever technique you used to inline the image in THIS ^^ reply message, the image showed up inline in both web interfaces to the forum just fine as an inline image. (It also shows up when you followed up as an attachment)

    So you can continue using that technique if you like.

    I'm one of the forum admins and often handles back end issues; if you can remember anything different about how you constructed the inline image in your first message vs. the above message, that'd help me. Perhaps a different application to post the message? Or maybe a copy/paste vs. an 'Insert image'?

    Trying to figure out the cause.
    (Sometimes posting from the google forum interface is the problem, whereas posting from email works fine)

[Caspian Merlin]

That is interesting indeed. Both times I used the Google forum interface - the first time I pasted the image from the clipboard, whereas this latest time I used 'insert image'.

[Albrecht Schlosser]

On 3/26/25 02:05 Greg Ercolano wrote:

    I'm one of the forum admins and often handles back end issues; if you can remember anything different about how you constructed the inline image in your first message vs. the above message, that'd help me. Perhaps a different application to post the message? Or maybe a copy/paste vs. an 'Insert image'?

    Trying to figure out the cause.
    (Sometimes posting from the google forum interface is the problem, whereas posting from email works fine)

Greg, FYI: I'm using Thunderbird to read the fltk.general group (mailing list), and I got the image in the OP's initial post - which Ian didn't see.

Then I posted this image in a follow-up message and I'm pretty sure (not 100% though) that I pasted it inline into the message (using Thunderbird's "HTML" editing features). Ian replied later that he didn't get my image as well.

From the mail headers of my mail:
```

Content-Type: multipart/alternative;
 boundary="------------6L33PCj0LtaAihZn9ZKZWe1j"
Message-ID: <cf6fe68d-624a-42eb...@aljus.de>
Date: Tue, 25 Mar 2025 20:08:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [fltk.general] Menu - render over child window

```

Interesting: I don't see the image in the 'text/plain;' part of the mail (<< comment in red >>):
```

This is a multi-part message in MIME format.
--------------6L33PCj0LtaAihZn9ZKZWe1j
Content-Type: text/plain; charset="UTF-8"; format=flowed

On 3/25/25 19:42 imm wrote:
> On Tue, 25 Mar 2025, 17:57 Caspian Merlin wrote:.
>
>     As you can see, the menu correctly renders over the child window -
>     on Linux. But on Windows, it doesn't: it's obscured by the child
>     window.
>
>
> See where? Did you intend to post a screenshot or some code?
> I don't seem to have either.

I got it, reposting for completeness. I hope you, Ian, get this one.


       << empty lines, no image here >>

BTW, I checked the Google web interface and I don't see it there. Weird.

```

However, the image is included in the 'text/html;' part (excerpt below, image text bold, in blue):
```

    I got it, reposting for completeness. I hope you, Ian, get this one.<br=
>
    <br>
    <br>
    <img src=3D"cid:part1.A9kRA...@aljus.de" alt=3D""><br>
    <br>
    <br>
    BTW, I checked the Google web interface and I don't see it there.
    Weird.<br>
    <br>

```

As I wrote, just FYI.

More details: I just checked my Thunderbird settings in menu 'View - Message Body as' (blue).

Viewing the OP's message:

• Original HTML: image is shown (this is what I use)
  
• Simple HTML: no image
• Plain Text: no image
• Google Web Interface, for completeness: no image
  

Viewing my own message:

• Original HTML: image is shown
• Simple HTML: image is shown
• Plain Text: no image
• Google Web Interface, for completeness: image is shown

Ian, if you're using Thunderbird, can you please check these settings?

If not, what do you use to view the messages? Mail client, newsgroup, or anything else?

[Mo_Al_]

Hello all,

@Caspian
Maybe you intended to call make_modal on the child window instead of set_on_top?
set_on_top() was added to fltk-rs because users wanted a way to really set the window to be on top of everything else.
So from your issue, it seems it's working correctly on windows!
On linux it's only implemented for X11 using _NET_WM_STATE_ABOVE and on macos using NSWindow::setLevel.

[Caspian Merlin]

@Caspian
Maybe you intended to call make_modal on the child window instead of set_on_top?
set_on_top() was added to fltk-rs because users wanted a way to really set the window to be on top of everything else.
So from your issue, it seems it's working correctly on windows!

Hi Mo,

First off - fantastic work with fltk-rs and cfltk.

I don't want it to be modal - I want several floating windows which always display above the main window, but I still want the user to be able to interact with the main window. A bit like an undocked toolbar in Office programs:

To be clear, my issue is not with set_on_top: this is working as expected on Linux and Windows (apart from when the main window is fullscreen, but I assume that's an OS limitation).

My issue is that in Windows, the MenuBar menus of the main window render underneath the on-top smaller windows - ideally they would render on top of everything. In the following screenshot from LibreOffice writer, the Properties window is displaying on top of the main window, but the main window's menus still render on top of it:

[Albrecht Schlosser]

On 3/26/25 01:21 Caspian Merlin wrote:
> [ Ian wrote ]

If the "child" windows have title bars and border decorations drawn by the WM, then they are fully windows in their own right, and there's no circumstance in which it makes sense for them to appear over another window, but underneath that window's menu drop-down. Even if they are modal (or non-modal, I suppose) then I don't think I'd expect them to be drawn over the "main" window whilst being under the "main" window's menu... Just seems weird.

Hmm, this is the behaviour I would expect. Imagine you've popped out a panel or toolbar in an IDE or office program - it often does become a top-level OS window, complete with titlebar and decorations. It's set always to be on top of the main window (otherwise it would disappear behind it as soon as you interact with the main window). Equally, if you select the 'File' menu of the main window, it'd be annoying if the menu drew underneath the widget you'd popped out. ...

I think the terms "child window" and "subwindow" need some clarifications to avoid misunderstandings.

In "FLTK speech" a child window or subwindow is a window that is embedded in another window. Such a subwindow never has a border of its own, and it can't be moved around etc. by the user (WM). However, such FLTK subwindows are typically also their own OS windows, just being embedded in another window.

Other windows created by the main process usually have a border (unless explicitly disabled) and fall into three (four [1]) categories (Ian can maybe explain this better):

1. Independent top level window
2. Modal window
3. Non-Modal window

All these window types are separate OS windows.

Type 1 is, as the name suggests, completely independent, like a window of another program. It can be occluded by (all) other windows of the same application.

Type 2 and 3 are related to their "parent" [2] window (the main window or any other window of the application) and stay always on top of that window.

Modal windows (type 2) also grab all input (keyboard and mouse clicks) directed to their "parent" windows, whereas non-modal (type 3) windows don't do that (you can interact with the "parent" window while the non-modal window is visible.

(Ian, please correct me if there's anything wrong with my explanation).

[1] Menu windows and tooltip windows are another category: they don't have a border but they are "modal" to their "parent" window (which can be another menu window in case of submenus). Menu windows are also their own OS windows.

[2] I used the term "parent" window (parent in "...") to mean the relationship on the OS level, not in the FLTK 'Fl_Group::parent()' sense which means the opposite of a subwindow. Sorry for the confusion.

That said, AFAICT setting a window to stay on top of all other windows (as set_on_top() obviously does) is not considered good style (discouraged) because it affects other applications's windows as well. I don't think that this is possible under Wayland at all, and as we can see, it's very much platform dependent.

Therefore the OP should look for implementing their way to show the "child" window (which is not a child window in the FLTK sense, as written above) as a modal or non-modal window instead. FLTK has ways to do this (but it must be done before showing the window, as Ian said). Whether fltk-rs can set a window modal or non-modal  I can't tell, but maybe Mo can offer more insights.

I hope this helps.

[Albrecht Schlosser]

On 3/26/25 15:17 Caspian Merlin wrote:

Hi Mo,

First off - fantastic work with fltk-rs and cfltk.

I don't want it to be modal - I want several floating windows which always display above the main window, but I still want the user to be able to interact with the main window.

Then your window(s) should supposedly be "non-modal" which is not the opposite of "modal", despite its naming. See my previous post.

[Caspian Merlin]

I might have referred to them wrongly, but the windows are currently non-modal and that is working as expected. I can still interact with the main window without issues, and when I call set_on_top on the pop-out windows, fltk-rs calls the relevant OS APIs to make sure they always display on top of everything. I appreciate this isn't implemented in Wayland, but at any rate the program seems to be using X11 even when in a Wayland session for whatever reason.

The sole issue that I am having is the fact that on Windows, the application menus render underneath the non-modal windows, whereas on Linux they render on top of them (as I would expect).

Windows:

Linux (KDE Plasma):

[Ian MacArthur]

On Wednesday, 26 March 2025 at 13:33:45 UTC Albrecht-S wrote:

Ian, if you're using Thunderbird, can you please check these settings?

If not, what do you use to view the messages? Mail client, newsgroup, or anything else?

OK - so I'm not using Thunderbird: I was travelling, so was using my phone (gmail) and it doesn't show the inline images.

Back in the office now, using Outlook I do see the inline images.

Using the google groups web interface - I mainly don't see the inline images...

 

[Ian MacArthur]

On Wednesday, 26 March 2025 at 14:17:32 UTC Caspian Merlin wrote:

I don't want it to be modal - I want several floating windows which always display above the main window, but I still want the user to be able to interact with the main window. A bit like an undocked toolbar in Office programs:

That's what Microsoft refer to as "non-modal" - and for various historical reasons FLTK uses that naming convention too.

Note that there are 3 typical window states "normal", "modal" and "non-modal".

So what you are describing is what MS and FLTK call a non-modal window: it remains on top of it's parent's main-window, but does not block event delivery to teh main window.

That is not the same thing as  "set_on_top()"  whilst is just about the z-ordering, not the modality, at least as far as I understand it.

I do not know what the Rust-ism is for creating a non-modal window though. Mo would know more.

[Ian MacArthur]

On Wednesday, 26 March 2025 at 14:22:47 UTC Albrecht-S wrote:

I think the terms "child window" and "subwindow" need some clarifications to avoid misunderstandings.

In "FLTK speech" a child window or subwindow is a window that is embedded in another window. Such a subwindow never has a border of its own, and it can't be moved around etc. by the user (WM). However, such FLTK subwindows are typically also their own OS windows, just being embedded in another window.

Other windows created by the main process usually have a border (unless explicitly disabled) and fall into three (four [1]) categories (Ian can maybe explain this better):

1. Independent top level window
2. Modal window
3. Non-Modal window

All these window types are separate OS windows.

Type 1 is, as the name suggests, completely independent, like a window of another program. It can be occluded by (all) other windows of the same application.

Type 2 and 3 are related to their "parent" [2] window (the main window or any other window of the application) and stay always on top of that window.

Modal windows (type 2) also grab all input (keyboard and mouse clicks) directed to their "parent" windows, whereas non-modal (type 3) windows don't do that (you can interact with the "parent" window while the non-modal window is visible.

(Ian, please correct me if there's anything wrong with my explanation).

This aligns with my understanding - and I think what Caspian wants is for his floating windows to be set non-modal w.r.t. his main window, and it ought then to work out fine.

FWIW I cobbled together (on Windows) a quick check of this in C++ / fluid and it seemed to work, so assuming there is a Rust wrapper for setting the floating windows to be non-modal I think that's the answer.

 

[Ian MacArthur]

On Wednesday, 26 March 2025 at 14:50:39 UTC Ian MacArthur wrote:

FWIW I cobbled together (on Windows) a quick check of this in C++ / fluid and it seemed to work, so assuming there is a Rust wrapper for setting the floating windows to be non-modal I think that's the answer.

 

Having posted this, it occurred to me it might actually be _useful_ to post may (allegedly working!) example. Here's the fluid file.

Compile with

fluid -c  non-mod.fl

fltk-config --compile non-mod.cxx

Or whatever local equivalents you use!

==========================================================

# data file for the Fltk User Interface Designer (fluid)
version 1.0309
header_name {.h}
code_name {.cxx}
Function {} {open
} {
  Fl_Window float_1 {
    label {Float 1} open
    xywh {856 434 309 207} type Double non_modal visible
  } {
    Fl_Button {} {
      label Hide
      callback {float_1->hide();}
      xywh {25 25 64 20}
    }
  }
  Fl_Window float_2 {
    label {Float 2} open
    xywh {876 454 309 207} type Double non_modal visible
  } {
    Fl_Button {} {
      label Hide
      callback {float_2->hide();}
      xywh {25 25 64 20}
    }
  }
  Fl_Window main_win {
    label {Main Window} open
    xywh {686 389 784 526} type Double visible
  } {
    Fl_Menu_Bar {} {open
      xywh {0 0 784 20}
    } {
      Submenu {} {
        label {Menu 1} open
        xywh {0 0 62 20}
      } {
        MenuItem {} {
          label {item 1}
          xywh {0 0 30 20}
        }
        MenuItem {} {
          label {item 2}
          xywh {0 0 30 20}
        }
        MenuItem {} {
          label {item 3}
          xywh {0 0 30 20}
        }
      }
      Submenu {} {
        label Other open
        xywh {0 0 62 20}
      } {
        MenuItem {} {
          label {item 1}
          xywh {10 10 30 20}
        }
        MenuItem {} {
          label {item 2}
          xywh {10 10 30 20}
        }
        MenuItem {} {
          label {item 3}
          xywh {10 10 30 20}
        }
      }
    }
    Fl_Button {} {
      label {Show 1}
      callback {float_1->show();}
      xywh {20 490 64 20}
    }
    Fl_Button {} {
      label {Show 2}
      callback {float_2->show();}
      xywh {109 490 64 20}
    }
    Fl_Button {} {
      label Quit
      callback {float_1->hide();
float_2->hide();
main_win->hide();} selected
      xywh {710 490 64 20}
    }
  }
}

(end of file)

 

[Ian MacArthur]

On Wednesday, 26 March 2025 at 15:13:55 UTC Ian MacArthur wrote:

Having posted this, it occurred to me it might actually be _useful_ to post my (allegedly working!) example. Here's the fluid file.

And here's "the same" as "plain" C++, in case that is any more useful to our rustacean colleagues... I confess I do not know how to do this in Rust myself...

I should probably shut up now:

=====================

#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Button.H>
#include <FL/Fl_Menu_Bar.H>

Fl_Double_Window *float_1=(Fl_Double_Window *)0;
Fl_Double_Window *float_2=(Fl_Double_Window *)0;
Fl_Double_Window *main_win=(Fl_Double_Window *)0;

static void cb_Hide(Fl_Button*, void*) {
  float_1->hide();
}

static void cb_Hide1(Fl_Button*, void*) {
  float_2->hide();
}

Fl_Menu_Item menu_[] = {
 {"Menu 1", 0,  0, 0, 64, (uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {"item 1", 0,  0, 0, 0, (uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {"item 2", 0,  0, 0, 0, (uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {"item 3", 0,  0, 0, 0, (uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {0,0,0,0,0,0,0,0,0},
 {"Other", 0,  0, 0, 64, (uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {"item 1", 0,  0, 0, 0, (uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {"item 2", 0,  0, 0, 0, (uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {"item 3", 0,  0, 0, 0, (uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {0,0,0,0,0,0,0,0,0},
 {0,0,0,0,0,0,0,0,0}
};

static void cb_Show(Fl_Button*, void*) {
  float_1->show();
}

static void cb_Show1(Fl_Button*, void*) {
  float_2->show();
}

static void cb_Quit(Fl_Button*, void*) {

  float_1->hide();
float_2->hide();
main_win->hide();
}

int main(int argc, char **argv) {
  { float_1 = new Fl_Double_Window(309, 207, "Float 1");
    { Fl_Button* o = new Fl_Button(25, 25, 64, 20, "Hide");
      o->callback((Fl_Callback*)cb_Hide);
    } // Fl_Button* o
    float_1->set_non_modal();
    float_1->end();
  } // Fl_Double_Window* float_1
  { float_2 = new Fl_Double_Window(309, 207, "Float 2");
    { Fl_Button* o = new Fl_Button(25, 25, 64, 20, "Hide");
      o->callback((Fl_Callback*)cb_Hide1);
    } // Fl_Button* o
    float_2->set_non_modal();
    float_2->end();
  } // Fl_Double_Window* float_2
  { main_win = new Fl_Double_Window(784, 526, "Main Window");
    { Fl_Menu_Bar* o = new Fl_Menu_Bar(0, 0, 784, 20);
      o->menu(menu_);
    } // Fl_Menu_Bar* o
    { Fl_Button* o = new Fl_Button(20, 490, 64, 20, "Show 1");
      o->callback((Fl_Callback*)cb_Show);
    } // Fl_Button* o
    { Fl_Button* o = new Fl_Button(109, 490, 64, 20, "Show 2");
      o->callback((Fl_Callback*)cb_Show1);
    } // Fl_Button* o
    { Fl_Button* o = new Fl_Button(710, 490, 64, 20, "Quit");
      o->callback((Fl_Callback*)cb_Quit);
    } // Fl_Button* o
    main_win->end();
  } // Fl_Double_Window* main_win
  main_win->show(argc, argv);
  return Fl::run();
}

// End of File

[Caspian Merlin]

@Ian that works a treat.

@Mo - from what I can tell, the set_non_modal function isn't exposed in fltk-rs - is this something you would consider?

[Mo_Al_]

Thanks for your kind words.

fltk-rs exposes set_non_modal via make_modal(bool):
https://github.com/MoAlyousef/cfltk/blob/8f3ab8fad00854991ff8564bb0f6a950bd5479d0/src/cfl_window.cpp#L117

It also exposes clear_modal_states() directly if needed.

[Caspian Merlin]

Oh, I feel stupid - I saw that method but didn't realise it took a bool as an arg... Thank you very much. It's working great!