No exit button on modal window (Windows X64)

[roger tunnicliffe]

as the title says, when I run my application on Windows a modal window will not have an exit button in the right-hand corner. The linux version does. Is this a bug or do I have to do something different on Windows.

Cheers

Roger.

P.S. The text files in the windows version do not have Carraige Characters (0x0d). Should they ??

[wea...@gmail.com]

On Tuesday, October 18, 2022 at 2:38:18 AM UTC+2 rogertunnicl...@gmail.com wrote:

as the title says, when I run my application on Windows a modal window will not have an exit button in the right-hand corner. The linux version does. Is this a bug or do I have to do something different on Windows.

Which windows version (XP,7,8,10,11)? What compiler version? Which FLTK version, release or 1.4? Can you maybe post a minimal example code? 

[roger tunnicliffe]

Windows 7 Home Premium.

fltk-1.3.8

 Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30146 for x64

[roger tunnicliffe]

Oh, and this one too, sorry

 

[Ian MacArthur]

On Tuesday, 18 October 2022 at 01:38:18 UTC+1 roger wrote:

as the title says, when I run my application on Windows a modal window will not have an exit button in the right-hand corner. The linux version does. Is this a bug or do I have to do something different on Windows.

I think that the default styling for modal windows in fltk is for them to be (typically) borderless, so they would have no window decorations, in which case the Windows version is "correct" and it sounds like your X11 version is "wrong" - which X11 window manager do you use? The styling of window decoration is a WM responsibility (it is not done by fltk at all, except maybe under Wayland, and then in only some cases... It's too complicated...)

Modal windows typically need have some specific means to close them, since they are intended to intercept and block all other events to the app until whatever the modal window addresses is resolved: this is usually by having some explicit buttonology to handle the case, or etc...

What are you trying to do , and what are you expecting the windows to do, vs. what they actually do?

 

P.S. The text files in the windows version do not have Carraige Characters (0x0d). Should they ??

Do not think I understood this question.

Can you clarify...

 

[Greg Ercolano]

On 10/18/22 02:13, Ian MacArthur wrote:

P.S. The text files in the windows version do not have Carraige Characters (0x0d). Should they ??

Do not think I understood this question.

Can you clarify...

    He might mean how on Windows, native text files are delimited with CRLF (\r\n) pairs, but if you look at unix native text files on Windows, lines end in just LF (\n).

    Most editors these days prefer one, but handle both.

    IIRC, Mac used to prefer only \r's (0x0d) as a line delimiter (probably just to be annoying lol), but I think since they moved from OS9 to OSX and BSD Unix, they've since become more unixy..?

    These are just differences between platforms, like the way pathnames are delimited with "\" vs "/" on Windows vs. Unix. And in the old and smellye days of MacOS9, ":" was the path delimiter (again, just to be annoying)

[roger tunnicliffe]

Yeah, sorry I was talking about the carraige "return" and line feed characters. 0x0d,0x0a. 

I use jedit and yes it handles them but I have found errors on Windows where it is not handled so well (MASM for instance).

to the original query, I not so sure opening a window that cannot be closed IS the correct behaviour.  

And no, the windows I m seeing that are modal are not borderless.

as for what I trying to do, I am trying to incorporate a cross platform GUI toolkit that works the same way on Windows as it does on Linux. (don't care about MacOS)

Cheers

Roger

[Greg Ercolano]

On 10/18/22 13:19, roger tunnicliffe wrote:

[..re: crlf on windows vs unix..]

I use jedit and yes it handles them but I have found errors on Windows where
it is not handled so well (MASM for instance).

    Yes, good old MASM. I think I still have V1.00 from 1985 or so, lol.

    What you can do is set up your Makefile to run the .asm file through a
    converter that enforces the CRLFs to ensure MASM doesn't see the
    unix style \n's.

    Or perhaps MASM by now has a flag that allows for unix style \n's.

to the original query, I not so sure opening a window that cannot
be closed IS the correct behaviour. 

And no, the windows I m seeing that are modal are not borderless.

as for what I trying to do, I am trying to incorporate a cross platform GUI toolkit that works the same way on Windows as it does on Linux. (don't care about MacOS)

    Although I can't weigh in on this (others surely will), it might help
    to see a screeshot of the non-borderless window that's lacking the "X",
    as this might be a problem with FLTK not flipping a flag that affects
    the window manager, or something..?

[roger tunnicliffe]

The CR/LF isn't a big deal for me (JEdit handles it nicely) I just thought I would mention it as the fltk doco doesn't present particularly well.

as for the screenshot, here 'tis

 

[Greg Ercolano]

On 10/18/22 14:32, roger tunnicliffe wrote:

as for the screenshot, here 'tis

    Huh, yeah, I think those missing buttons are called "window decorations",
    and are provided by the window manager, but controllable I think by FLTK
    as flags for the window.

    I have Windows 7 pro here, so maybe I can replicate with one of the test
    programs.

[roger tunnicliffe]

The difference you'll find is that if the window is Modal they do not appear as opposed to NOT modal, where they do appear

Cheers

Roger

 

[Greg Ercolano]

On 10/18/22 16:45, roger tunnicliffe wrote:

On Wednesday, October 19, 2022 at 8:52:43 AM UTC+11 er...@seriss.com wrote:

On 10/18/22 14:32, roger tunnicliffe wrote:

as for the screenshot, here 'tis

    Huh, yeah, I think those missing buttons are called "window decorations",
    and are provided by the window manager, but controllable I think by FLTK
    as flags for the window.

The difference you'll find is that if the window is Modal they do not appear as
opposed to NOT modal, where they do appear

    Can confirm on Win10Pro with current 1.4.x git / cmake / VS 2019.

    Easy enough to replicate by making this one line change to test/hello.cxx:

diff --git a/test/hello.cxx b/test/hello.cxx
index d7308cd78..84fb82df3 100644
--- a/test/hello.cxx
+++ b/test/hello.cxx
@@ -20,6 +20,7 @@
 
 int main(int argc, char **argv) {
   Fl_Window *window = new Fl_Window(340, 180);
+  window->set_modal();
   Fl_Box *box = new Fl_Box(20, 40, 300, 100, "Hello, World!");
   box->box(FL_UP_BOX);
   box->labelfont(FL_BOLD + FL_ITALIC);

    So devs: is this a bug needing to be reported?
    Seems to be, as the same code has no "X" on Windows but does on Linux/Xwindows:



    The only way to close the window on my Win10pro machine was to hit ESC.

[Ian MacArthur]

On Wednesday, 19 October 2022 at 07:48:57 UTC+1 erco wrote:

    So devs: is this a bug needing to be reported?

    Seems to be, as the same code has no "X" on Windows but does on Linux/Xwindows:

I believe this was "always" so, and has been "since antiquity" - if you fire up older versions of 1.3 it is "the same".

The window decorations are provided by the WM, not be fltk, so the differences you are seeing are WM differences, not fltk ones. On MS-Windows, modal windows tend not to have decorations, non-modal windows do (but sometimes "smaller then usual", depending on WInXX version) and normal windows have the normal decorations.

On X11 systems, where there is a much wider variety of WM in use, the pattern of decoration varies considerably more and there is no particular "common" pattern that I know of; just the whim of the desktop designer in each case...

I should probably point out,  for Roger's benefit if nothing else (for it is often confusing and far from clear!) that there are 3 (three) types of window; that is "modal" and "non-modal" are not a binary pair, they each have unique properties that differentiate them from a "normal" window.

1: Normal window: regular window behaviour, regular decorations, does not affect event delivery to other active windows in its application

2: Modal: always on top, blocks all event delivery to any other window in its application, typically has no decorations, or reduced decorations. Try and avoid having more than one of these active at any time as things get weird very quickly if you do! Typically used for menu items, popups, warnings. Not suitable to use for general window operations.

3:Non-modal: always on top, but does not block event delivery. Usually has widnow decorations though they may be restyled (i.e. smaller) on some platforms. Typically used for floating toolboxes and things of that ilk.

[roger tunnicliffe]

I had a quick look back at a Excel VBA system I wrote some time back (I really like VBA) and the Windows are Modal yet still have the decorations.

That probably has nothing to do with fltk but there must be some parameter to set (or something) to enable the functionality. I does seem strange

though that you can open a window and never be able to close it   

 Cheers

Roger 

[lifeatt...@gmail.com]

Sorry to throw gasoline on this fire but ...

>The window decorations are provided by the WM, not be fltk, so the differences you are seeing are WM differences, not fltk ones. On MS-Windows, >modal windows tend not to have decorations, non-modal windows do (but sometimes "smaller then usual", depending on WInXX version) and >normal windows have the normal decorations.

This isn't quite right.

FLTK has made the choice to disable those decorations on Windows for modal(). The system menu and close buttons are allowed to be there for a modal window under Windows. This code in Fl_Win32.cxx is responsible (bolding mine):

      // Thin border and title bar
      case 1:
        style |= WS_DLGFRAME | WS_CAPTION;
        if (!w->modal())
          style |= WS_SYSMENU | WS_MINIMIZEBOX;
        break;

I.e if modal, don't provide the menu/close and minimize buttons.

Looking at the code for X11, I don't see any similar attempt to turn OFF the buttons for a modal window. Given the headache I got trying

to read the X11 details, I'm thinking it's just HARD to do so for X11.

On the subject though, I do have a concern with this chunk of code in the X11 driver: (FLTK 1.4 : Fl_x.cxx, line 2516)

    if (win->non_modal() && xp->next && !fl_disable_transient_for) {
      // find some other window to be "transient for":
      Fl_Window* wp = xp->next->w;
      while (wp->parent()) wp = wp->window();
      XSetTransientForHint(fl_display, xp->xid, fl_xid(wp));
      if (!wp->visible()) showit = 0; // guess that wm will not show it
      if (win->modal()) {
        Atom net_wm_state = XInternAtom (fl_display, "_NET_WM_STATE", 0);
        Atom net_wm_state_skip_taskbar = XInternAtom (fl_display, "_NET_WM_STATE_MODAL", 0);
        XChangeProperty (fl_display, xp->xid, net_wm_state, XA_ATOM, 32,
            PropModeAppend, (unsigned char*) &net_wm_state_skip_taskbar, 1);
      }
    }

Again, bolding mine. Unless I've misread this, it appears for the modal() case, FLTK will never set _NET_WM_STATE_MODAL. Note this code is the same under FLTK 1.3.5 and FLTK 1.4.  [Here's the commit from 2014]

Kevin

[Ian MacArthur]

On Sunday, 30 October 2022 at 23:23:36 UTC lifeatt... wrote:

 

>The window decorations are provided by the WM, not be fltk, so the differences you are seeing are WM differences, not fltk ones. On MS-Windows, >modal windows tend not to have decorations, non-modal windows do (but sometimes "smaller then usual", depending on WInXX version) and >normal windows have the normal decorations.

This isn't quite right.

FLTK has made the choice to disable those decorations on Windows for modal(). The system menu and close buttons are allowed to be there for a modal window under Windows. This code in Fl_Win32.cxx is responsible (bolding mine):

      // Thin border and title bar
      case 1:
        style |= WS_DLGFRAME | WS_CAPTION;
        if (!w->modal())
          style |= WS_SYSMENU | WS_MINIMIZEBOX;
        break;

I.e if modal, don't provide the menu/close and minimize buttons.

Hi Kevin,

Sure - but this is because the use fltk generally makes of "modal" windows is to show popups and menus, which need to have the decorations suppressed under Win32.

But if you *really* want a modal window with decorations under Win32, you can just turn the decorations back on - though that then needs platform specific code, since X11+<some WM> or macOS behave differently here; not because fltk does, but because the underlying systems do... 

Frankly. modal windows are something of an abomination and the various platforms handle them in "similar but annoyingly and subtly different" ways, so there is no simple answer here.

I (personally) do not much care for using modal windows as a floating window "in its own right", as the behaviours and interactions with other windows, and particularly the "grab()" behaviour are confusing.

Generally, a non-modal window - which will stay on top but not have the grab() behaviour, is easier to deal with. Or just use a regular window - there are not that many cases where the on-top really matters perhaps?

 

Looking at the code for X11, I don't see any similar attempt to turn OFF the buttons for a modal window. Given the headache I got trying

to read the X11 details, I'm thinking it's just HARD to do so for X11.

X11 is "hard" here because X11 is not the WM, X11 is only the drawing system - the WM will be some separate application layer that makes use of X11 et al to render the windows at the appropriate positions and with the appropriate decorations. Under Win32 (and macOS) the drawing system and WM are (more or less) conflated into one "thing" (that is not, strictly entirely, true...)  but not under X11.

[Aside: You can run fltk on an X11 server with no WM at all - I have done this for a "kiosk" mode application in the past, but in that case the windows can not be moved or dragged and have no decorations or etc. And do not overlap them, or weird stuff happens... In fact, just use one big window for the full screen and hope for the best in that case!]

WM on X11 is more or less expected to conform to the ICCCM and its many and various additions and extensions, which pretty much exists "on top of" X11.

So here we are addressing the basics that we can be reasonably confident the X11/WM will cope with, but it is Too Hard to know what all the things the WM *might* be able to do are...

Note also that the default behaviours of "modal" windows under X11 (which doesn't actually use that term in quite that way, IIRC, c.f. XSetTransientFor etc...) is different from the Win32 default, hence I think that accounts for the differences in the way it is "configured" here.

On the subject though, I do have a concern with this chunk of code in the X11 driver: (FLTK 1.4 : Fl_x.cxx, line 2516)

    if (win->non_modal() && xp->next && !fl_disable_transient_for) {
      // find some other window to be "transient for":
      Fl_Window* wp = xp->next->w;
      while (wp->parent()) wp = wp->window();
      XSetTransientForHint(fl_display, xp->xid, fl_xid(wp));
      if (!wp->visible()) showit = 0; // guess that wm will not show it
      if (win->modal()) {
        Atom net_wm_state = XInternAtom (fl_display, "_NET_WM_STATE", 0);
        Atom net_wm_state_skip_taskbar = XInternAtom (fl_display, "_NET_WM_STATE_MODAL", 0);
        XChangeProperty (fl_display, xp->xid, net_wm_state, XA_ATOM, 32,
            PropModeAppend, (unsigned char*) &net_wm_state_skip_taskbar, 1);
      }
    }

Again, bolding mine. Unless I've misread this, it appears for the modal() case, FLTK will never set _NET_WM_STATE_MODAL. Note this code is the same under FLTK 1.3.5 and FLTK 1.4.  [Here's the commit from 2014]

Ah, no... I suspect this is just you being confused by the (entirely reasonable but unfortunately wrong) assumption that modal/non-modal is a binary pair. 

It is not. In general, a non-modal window (at least under X11) might *also* be a modal window, but does not enforce the grab() behaviour, so in this case the win->non_modal() test will return true for both a "modal" and a "non-modal"  (in the FLTK sense) window. Which is deeply confusing; here be dragons, etc.

So the initial check is kinda saying -- if this window has some "modality" (or either tpye) and "transient for" is not already disabled, then let's check if we should be setting the transient, and then check if the window is specifically modal (in the fltk sense) and set that too.

If you see what I mean.

X11 is tricky...