Adding an item to an Fl_Tile

[Jeffrey Ellis]

I'm trying to add an existing, already displayed Fl_Double_Window to an Fl_Tile that is also already existing and displayed. No matter what I try, the Fl_Double_Window is not displayed where I intend it to be within the Fl_Tile. Any ideas why this would happen? I am giving Fl_Tile:add the coordinates relative to the Fl_Tile but it is always shown as relative to the screen. 

[Albrecht Schlosser]

On 6/5/26 02:36 Jeffrey Ellis wrote:

I'm trying to add an existing, already displayed Fl_Double_Window to an Fl_Tile that is also already existing and displayed. No matter what I try, the Fl_Double_Window is not displayed where I intend it to be within the Fl_Tile. Any ideas why this would happen? I am giving Fl_Tile:add the coordinates relative to the Fl_Tile but it is always shown as relative to the screen.

First of all, please tell us the FLTK version you're using; if from Git, please provide the git rev (hash). This may be relevant, particularly because Fl_Tile recently got some improvements. Also, the OS/platform (Windows, Linux, macOS) and version should be provided.

Just adding a new child (Fl_Double_Window) to an existing Fl_Tile is certainly not enough. Using a window type as a child of Fl_Tile is possible, but it's easier to use an Fl_Group, and if you want to reparent an Fl_(Double_)Window as a subwindow, then it's very likely that you *must* hide() and show() it after reparenting. This may depend on the OS as well.

Fl_Tile also has some restrictions on its children, see docs here: https://www.fltk.org/doc-1.4/classFl__Tile.html#details .
Citation: "For the tiling to work correctly, the children of an Fl_Tile must cover the entire area of the widget, but must not overlap. This means that all children must touch each other at their edges, and no gaps can be left inside the Fl_Tile."

The consequence is (AFAICT) that you will likely need to change the coordinates of the other children as well to make it fit as required.

This is all based on guessing. To enable us to help you it would be best if you could provide a simple, but complete (compileable) example source code (one short file) that shows what you try to do. Then we could try to test and help you.

[Matthias Melcher]

FLTK has two different versions of Fl_Window. If an Fl_Window Is shown without a parent, it will be created as a full desktop window with decoration. If it is shown as the child of another, we call that a sub window. A subwindow has its own window handle in the in the host window system (hWnd in Windows). As a side effect, it also resets its coordinate system to 0,0. 

You only ever create a sub window if you *must* have a separate handle (hWnd), for example to create a hardware accelerated rendering context.  If you create a subwindow merely to have a 0,0 origin, you are creating a ton of overhead for your system.

So, I f your window is a desktop or subwindow is decided when it is first shown. If you take an existing desktop window and make it the child of another window, the window will sill remain a desktop window. The correct way to display this is to create a new window (or in this case, a Fl_Group at 0,0), remove the children from the Fl_Double_Window and add them to the group instead. You must make sure that the children's coordinates get updated to their new parent's coordinates. Calling show() on the group should now work as expected. You can now delete the original Fl_Double_Window.

 

 - Matthias

[Matthias Melcher]

Matthias Melcher schrieb am Freitag, 5. Juni 2026 um 14:07:58 UTC+2:

You only ever create a sub window if you *must* have a separate handle (hWnd), for example to create a hardware accelerated rendering context.  If you create a subwindow merely to have a 0,0 origin, you are creating a ton of overhead for your system.

... but otherwise behaves just like another group inside the existing window... 

Gosh, this Is historic and so hard to explain ;-)

[Albrecht Schlosser]

On 6/5/26 14:07 'Matthias Melcher' via fltk.general wrote:

So, I f your window is a desktop or subwindow is decided when it is first shown.

Correct, I agree so far.

If you take an existing desktop window and make it the child of another window, the window will s[t]ill remain a desktop window.

I doubt that this statement is true in general. IMHO hide()ing the subwindow, removing it from the group, and subsequently show()ing it should make the window a normal desktop window. Therefore I wrote a test program to verify whether this is the case, and I found some platform specific issues (still work in progress). I'll open an issue (probably tomorrow) with more details, but for now in a nutshell:

1. "Converting" a desktop window to a subwindow using hide(), Fl_Group::add(), and then show() works flawlessly on all supported platforms.

2. The opposite, i.e. removing a subwindow from an existing Fl_Window (Fl_Group) and then hide()ing and show()ing it - which should IMHO make it a standalone "desktop" window -  doesn't work as expected (by me) on some platforms:

2a) Linux (X11) and Windows (tested only under Linux with Wine so far) both work well: the window gets normal window decorations.

2b) Linux (Wayland) and macOS: the new "desktop" window is borderless (no decorations) and can't be moved. This is likely caused by some internal stuff that's not reset as it should be, but that's only a guess.