Hello. I’m working on C++/Windows.
My goal is to remove borders with glfwWindowHint(GLFW_DECORATED, false) but also maximize the window outside of the area covered by the taskbar, rather than fullscreen.
When I turn decorations on, the default “maximize” button of the window does exactly what I want. It even moves the window when the taskbar moves. But I want to implement that in my own GUI and glfw does not seem to give me a function for that. I can only go completely fullscreen.
How should I do? I thought of a trick like:
- Leaving decorations on
- Maximizing the window
- Measuring the frame
- Remove decorations and increase the window size to replace them
- Repeat every time the window is refreshed (i.e, when the task bar is moved)
But that sounds a bit wacky. Or I could make some platform-specific code to find out the correct position and size, but… meh. That’s not what I’m using GLFW for.
This issue of maximized borderless windows on Windows has been raised before, and I created an issue for it on the GLFW Github site.
It looks like the intended behaviour will be implemented in milestone 3.4, as there is already a large backlog on GLFW.
As a workaround, you could use the windows function SystemParametersInfo with the uiAction set to SPI_GETWORKAREA to get the work area (desktop size excluding task bar).
Thanks for the reply. Looks like I’ll have to wait for 3.4 and use this dirty system-specific code in the mean time.
It’s too bad GLFW doesn’t have this yet because it looks like it’s the last step to allow the developer to make a fully customized window GUI that behaves like a normal window with simple platform-independent code. I don’t think it’s an incompatibility issue, because all systems relevant for GLFW seem to have a taskbar anyway, so it definitely could have been done earlier. But I’m not going to cry, because GLFW is already great.
That and proper dragging and resizing of undecorated windows, and possibly a work area query as well.
Yes, definitely. I welcome a patch for the Windows maximization issue that robustly implements @dougbinks’ option #1 and would try to get it into 3.3. Otherwise I’ll try to address it in 3.4.