FLTK breaks when resize request is denied

[fltk]

FLTK breaks when resize request is denied

[ManoloFLTK]

I use FLTK 1.4 and the slightly modified version given below of test/button.cxx
and run it on Windows 10 as follows:

• maximize the window
• click "Beep"
  ----> the window recovers its initial size and is correctly painted and reactive.
  Same lack of problem under X11 and macOS.

Can you give a minimal source code that displays the problem?

#include <stdlib.h>
#include <stdio.h>
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Button.H>
#include <FL/fl_ask.H>

void beepcb(Fl_Widget *me, void *) {
me->window()->size(320,65);
}

void exitcb(Fl_Widget *, void *) {
exit(0);
}

int main(int argc, char ** argv) {
Fl_Window *window = new Fl_Window(320,65);
Fl_Button *b1 = new Fl_Button(20, 20, 80, 25, "&Beep");
b1->callback(beepcb,0);
/*Fl_Button b2 =/ new Fl_Button(120,20, 80, 25, "&no op");
Fl_Button *b3 = new Fl_Button(220,20, 80, 25, "E&xit");
b3->callback(exitcb,0);
window->end();
window->resizable(window);
window->show(argc,argv);
#if 0
Fl::add_fd(0, stdin_cb);
#endif
return Fl::run();
}

[CendioOssman]

Let me have a look and get back to you.

[CendioOssman]

Resizing to a smaller size seems to have better success. Change to try 2000x2000 (or whatever is larger than your screen) and you should see the issue.

I can reproduce it here with 1.3.5 and your test program. I have not tried master.

[ManoloFLTK]

OK. I see that too here under Windows10 if I resize to something larger.
No problem under X11 and macOS, though.
But why would one want to resize to larger than the full screen?

[ManoloFLTK]

I believe that is fixed adding this statement
wait_for_expose_value = 0;
just before
SetWindowPos(fl_xid(pWindow), 0, scaledX, scaledY, scaledW, scaledH, flags);
near the end of function Fl_WinAPI_Window_Driver::resize() of file src/Fl_win32.cxx

@Albrecht-S : could you, please, validate this change? It's OK in Windows10 and Windows XP,
and also if the window is created with fullscreen().

[Albrecht-S]

Will look into it...

[Albrecht-S]

First of all: yes, @ManoloFLTK's proposed change seems to "fix" the issue but I don't think that this is the correct solution. In the same method we have:

      if (i && W > 0 && H > 0)
	wait_for_expose_value = 1;

Hence, the proposed fix would reset the wait_for_expose flag which has been set before for a good reason. ISTR that this was needed if a window was resized larger than before, but I'm not sure if this was for Windows or (very likely) for another OS.

I did some tests and I was wondering if SetWindowPos() would fail under certain conditions but I couldn't find such a case.

I also noticed that sometimes the maximize icon in the window decorations seemed to have a wrong state. Example:

1. maximize the window
2. click the beep button to resize the window to a smaller size

Now the maximize button still shows the maximized state and the tooltip says to go back to normal window size (hard to translate from German to correct WEnglish (Windows English)).

This needs more tests, but this is all I can contribute today. I'll see what I can do tomorrow or later.

[ManoloFLTK]

The "wait_for_expose_value = 0;" statement is not merely undoing what has been done
previously, because it's done only if resize_from_program is true, which means
the app programmed a window resize. I agree the suggested change in not
entirely satisfactory because the maximize button may be in a wrong state.

Another approach would be to refuse programmed resizes when the
window is maximized, as implemented by the pseudo-diff below, again for
function Fl_WinAPI_Window_Driver::resize() of file src/Fl_win32.cxx :

if (is_a_resize) {
+ if (resize_from_program && shown()) {
+ // don't obey "resize from program" when window is maximized
+ WINDOWPLACEMENT winfo;
+ winfo.length = sizeof(WINDOWPLACEMENT);
+ BOOL ok = GetWindowPlacement(fl_xid(pWindow), &winfo);
+ if (ok && winfo.showCmd == SW_SHOWMAXIMIZED) return;
+ }
pWindow->Fl_Group::resize(X, Y, W, H);

[Albrecht-S]

Yes, this new proposal looks reasonable. We could do this (disallowing resizing when the window is maximized) - or we could maybe use GetWindowPlacement() to reset the window to normal state before applying the resize, like this:

 if (is_a_resize) {
+  if (resize_from_program && shown()) {
+    // Restore window to "normal size" if window is maximized   **changed**
+    WINDOWPLACEMENT winfo;
+    winfo.length = sizeof(WINDOWPLACEMENT);
+    BOOL ok = GetWindowPlacement(fl_xid(pWindow), &winfo);
+    if (ok && winfo.showCmd == SW_SHOWMAXIMIZED) {
+      winfo.showCmd = SW_SHOW;                                  **changed**
+      SetWindowPlacement(fl_xid(pWindow), &winfo);              **changed**
+    }
+  }
 pWindow->Fl_Group::resize(X, Y, W, H);

Note: this code is untested. If it resulted in flashing because it would show the window before doing the actual resize then the code would need to be reorganized. It's just an idea. I hope it would also solve the issue posted by Pierre.

@CendioOssman: Either disallowing resize by program or resetting the window to normal state before resizing seem to be possible ways to solve this issue. The latter would need tests though (whether it really solves the issue or not). What do you think?

[ManoloFLTK]

The proposal above that aims at resetting the window to normal state
and then resizing it does not work: the window gets frozen, as with unchanged code.

[ManoloFLTK]

As an additional information: the current FLTK 1.4 for the macOS platform
disallow resize calls that try to enlarge a window when it's maximized.

[ManoloFLTK]

Under Ubuntu, a resize request sent by the program to a maximized
window is also ignored. Thus, I have committed the fix mentionned above
so such requests are also ignored under the Windows platform.

@CendioOssman : is it OK with you to close the issue?

[CendioOssman]

For now I guess. But bear in mind that Linux has many different window managers with wildly different behaviours. Not an issue for us right now, but might come back to bite us in the future.

[Albrecht-S]

FYI: I agree with @ManoloFLTK's solution and withdraw my own proposal in #65 (comment) . Thanks for fixing this.

@ManoloFLTK Do you intend to backport this to 1.3.x (presumably 1.3.6)?

[ManoloFLTK]

There are far more important changes not present in 1.3 than this one.
My understanding has always been that 1.3.5 would be the last release before 1.4.

I very strongly believe we should try instead to release 1.4 because

• HighDPI support is important now under X11
• pango allows to draw any text with any font under X11, as it is with other platforms
• 1.3.5 does not work well with macOS 10.15

[abrolag]

I would be quite keen to see V 1.4 out there. Any likelihood of it this year?

[Albrecht-S]

Maybe, likely, I don't know yet.

Please let's discuss this in fltk.coredev.

Closing this issue now.