This is pretty accurate. What FLTK is *trying* to get I will try to describe, the problem is all the window systems (originally Windows but X window managers have gotten increasingly bad) do not provide what is wanted, and FLTK has to deal with whatever is closest:
Here's my full list of modalities:
- Modeless - a modeless window supports interaction when it has the focus but does not grab or block interaction with any other window in its own or other applications.
This is a normal window. Ideally the only thing that will change the stacking order of this window and others is if the user clicks on the titlebar or clicks on a "dead" area (no widget), or the clicked-on widget thinks some currenty-obscured area should be visible, in which case the window is raised to the top of the stack (except for any modal windows, see below). On modern systems this exact behavior is usually impossible, and clicking anywhere always raises the window even when not wanted (which makes it a real pain to do drag & drop!).
- Window Modal - has no effect on other windows in other applications or in this application. Used by pop up menus or other interactive popups (e.g., completion). Normally this is handled automatically by the GUI library's pop-up API.
The primary purpose is "make a window without a window border". It also often stays on top, though most modern api's have a click anywhere outside of this dismiss the window so it does not matter if stay-on-top does not work as the window would go away at the same time it is buried. There is also often some kludge needed to detect if the user clicks on the desktop or another application's window so the window will go away. Getting tihe window to appear exactly where FLTK wants it is also assumed and sometimes a pain to implement.
- Modal - has no effect on other windows in other applications or in this application's windows in the same tree: here 'tree' is the top-level window and any child windows the modal dialog has been invoked on. So, for example, if you have an application and use it to open two top-level windows (e.g., two document windows), and use a modal dialog in one of those windows (e.g., a Find dialog), the modal restriction will only apply to the document window (or child) it is invoked on, and _not_ apply to the other document window (or its children).
This is the primary goal FLTK wants. Any attempt to raise the "parent" window will also raise this one so it is on top. Raising this one should *not* raise the parent, however.
- Application Modal - has no effect on other windows in other applications, but applies to _all_ this application's windows, even in the case of multiple top-level windows. Rarely used.
Usually this is what the window system provides and FLTK has to use it for modal windows. The parent of the modal window is ignored and instead all windows of the application act like parent.
- System Modal - affects _all_ windows in _all_ applications; normally only used for the system login dialog. Dangerous to use this level of modality because a bug could make the entire system unusable.
FLTK cannot make these windows.
In addition there is what FLTK is calling "non-modal". Most of these also cause all events to be sent to the window. FLTK however just pretends keyboard events are going to the window it thinks they should go to, even if the operating system sends them to this window. So "non modal" is used when you want the stacking behavior but don't want to block interaction with the other windows.
I've complained about this situation forever but they are never going to fix this. All that is really needed is that a window should *never* raise automatically, the application has to be able to say when it is raised. And a "raise" should be able to say "put it just below this other window". All window stacking and modality can be done by the app and everything would be much much simpler and usable. But it looks hopeless.
