@gvnnz Thank you for the report and sorry for the late reply.

@ManoloFLTK wrote:

That would mean 1.4 is correct in refusing to resize a non-resizable window, and 1.3.8 is incorrect. Would you agree ?

Manolo, I'm afraid I can't agree. Although you could strictly say "yes, that's it", I tend to disagree because

1. this behavior appears to be a regression WRT 1.3.x and
2. it does not manifest on all other platforms tested by me with FLTK 1.4.0 (Windows, macOS, Wayland on Linux)

I can see what happens: we're setting minw, minh, maxw, maxh as window attributes. This means the window can't be resized by the user.

However, it does also seem to affect the resize() behavior when called by the program and I don't think it should do this. I don't see all the details and don't know how to fix it (yet) but for now I'd say it's a bug (regression) and should be fixed. I can look into the details but not today. I just tested and wanted to let you know what I found out so far.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/471/1195676849@github.com>