Make a window locked and not resizable ?

[Lucas Sanner]

Hi all,
I'm using the FLTK library for my project, and I want the main window to start locked at the maximized state.
But I also want to prevent the users to resize the window. So basically, the window has only 2 states: maximized or minimized.
I tried the size_range() method:

int main(int argc, char *argv[])
{
    Fl_Double_Window* win = new Fl_Double_Window(800, 400, "My Application");
    int screen_w = Fl::w();
    int screen_h = Fl::h();
    // Blocks the window's size to screen dimensions.
    win->size_range(0, 0, screen_w, screen_h);
    win->end();
    win->show();
    // Start the app maximized.
    win->maximize();
    // Make the app non resizable.
    win->resizable(nullptr);

    return Fl::run();
}


but the window is still resizable when the top border is double clicked or the resize button is clicked.
Is there any way to fix that without hijacking the window manager ?
note: I'm under Linux (Debian 13) with FLTK 1.4

[Manolo]

this approach seems to make it:

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>

int main(int argc, char **argv) {
  int X,Y,W,H;
  Fl::screen_work_area(X,Y,W,H,0);
  Fl_Window *window = new Fl_Window(W, H);
  Fl_Box *box = new Fl_Box(20, 40, 300, 100, "Hello, World!");
  box->box(FL_UP_BOX);
  box->labelfont(FL_BOLD + FL_ITALIC);
  box->labelsize(36);
  window->end();
  window->show(argc, argv);
  return Fl::run();
}

[Lucas Sanner]

Thanks for your help, the window is no longer resizable.
However, the window is not locked at the screen as it is when maximized (ie: it's draggable).
Is there a way to locked the window ?

[wea...@gmail.com]

On Tuesday, May 5, 2026 at 8:12:29 PM UTC+2 lucas....@gmail.com wrote:

Thanks for your help, the window is no longer resizable.
However, the window is not locked at the screen as it is when maximized (ie: it's draggable).
Is there a way to locked the window ?

I'm not sure you can achieve that from your application. I think that is rather a window manager responsibility. Probably you can mess around with some "low level flags and settings", but it's not really a clean solution.

At least this is my opinion. The FLTK devs may have more information about it.

[Greg Ercolano]

On 5/5/26 01:36, Lucas Sanner wrote:

Hi all,
I'm using the FLTK library for my project, and I want the main window to start locked at the maximized state.
But I also want to prevent the users to resize the window. So basically, the window has only 2 states: maximized or minimized.

    You could try disabling window manager borders, IIRC window->border(0), preventing the app from having any window decorations the user can use to grab and resize/move the app. I've made a few fltk apps that are borderless; a clock and an on-screen ruler application to name a few. To handle any kind of app movement had to be done within the app itself (e.g. dragging the clock and ruler around). If you don't provide that, then the user can't move it at all, unless the window manager has hotkeys to override.

    Usually a valid (*)  reason for full screen apps that can't be moved or resized are things like 24/7 demos, kiosks or industrial user interfaces with embedded hardware where you don't want a stray click from the user to accidentally break out of the industrial application and gain access to the machine.

    In these cases it's often best to run without a window manager at all; I used to just run X without a window manager, and then start the FLTK app in place of the window manager, and get the machine to boot into that user login and start X and the app with a script in a forever loop so if the app dies, it automatically restarts.

    There used to be one clear way to do this when there was just X, but now with Wayland and systemd and such, there's often never one way to do things anymore.

    I'm not sure if wayland works the same way, but with X you can just start it and tell it to run your app (in place of a window manager), then your app can interact with X without the window manager, and can do what it wants and the window manager won't be there to let the user take control over the app. So no window title bars or window manager hot keys to worry about. The only thing you have to then worry about is a special key sequence to close X (used to be Ctrl-Alt-Backspace I think?) and some other hot keys that would switch you to the virtual consoles.

___

(*) some not-so-valid reasons are making trojan login and lock screens to nab passwords.

[Lucas Sanner]

Thanks Greg for your informative and insightful response.
A borderless window seems to be the most reliable option among those you mentioned.
But I'm developing an audio/midi editor (DAW) and it would be weird for the users to find themselves "isolated" from their desktop and their other applications.
So I think my best bet is to leave the window behavior as it is but to make all the widgets inside not resizable and start the application in full size (maximize).
The users trying to resize the app will quickly realize that it's pointless.

[Albrecht Schlosser]

On 5/6/26 11:29 Lucas Sanner wrote:
> So I think my best bet is to leave the window behavior as it is but to
> make all the widgets inside not resizable and start the application in
> full size (maximize).

Even full size / maximize is not a constant size. It *obviously* depends
on the screen size, hence you will have to construct your GUI in a
certain size and resize it appropriately anyway. Unless you make it like
1024 x 800 and keep it that small which is not really an option. See
below for more.

> The users trying to resize the app will quickly realize that it's
> pointless.

I don't know how your GUI looks, but maybe you could base your layout on
the new widget (container) Fl_Grid (since 1.4). It allows you to resize
its children in a very flexible way. Just an idea, but maybe not
applicable to your case. I just wanted to mention it.

A good example of Fl_Grid can be found in test/cube.cxx, along with a
layout sketch. You can run the demo program and see how its layout
resizes when the window is resized by the user. If necessary you can
even nest more than one Fl_Grid for special needs. If you have questions
about how to use it, RTFM ;-) and feel free to ask here again.