Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Linux] Different Fl_Window::resize() behavior between v1.3.8 and v1.4.0 #471

Closed
gvnnz opened this issue Jul 22, 2022 · 5 comments
Closed
Assignees
Labels
fixed The issue or PR was fixed.

Comments

@gvnnz
Copy link

gvnnz commented Jul 22, 2022

Debian 11
X.Org version: 1.20.11

The following example:

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

int main(int argc, char** argv) {
  Fl_Window* window = new Fl_Window(100, 100);
  window->end();
  window->show(argc, argv);
  window->resize(0, 0, 800, 600); // <---------
  return Fl::run();
}

With FLTK 1.3.8: the window shows up at position (0, 0), 800x600 pixels as expected.

With FLTK 1.4.0 commit 2cedae1: the window shows up in the middle of the screen, 100x100 pixels (the original unchanged size).

@ManoloFLTK
Copy link
Contributor

If you add
window->resizable(window);
after the window->end(); statement in your example program, FLTK 1.3.8 and 1.4 produce the same result.

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

@Albrecht-S
Copy link
Member

@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.

@ManoloFLTK
Copy link
Contributor

@gvnnz The issue should be fixed now under Linux using the most recent master branch. Can you confirm, please?

@ManoloFLTK ManoloFLTK self-assigned this Jul 28, 2022
@ManoloFLTK ManoloFLTK added the fixed The issue or PR was fixed. label Jul 28, 2022
@gvnnz
Copy link
Author

gvnnz commented Jul 29, 2022

Hi @ManoloFLTK and @Albrecht-S, thanks for your feedback. I can confirm that the original example works fine now using the most recent master branch. No need to add window->resizable(window) anymore. Thank you!

@Albrecht-S
Copy link
Member

@ManoloFLTK Thanks for fixing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed The issue or PR was fixed.
Projects
None yet
Development

No branches or pull requests

3 participants