Maximize/minimize event order

support
1

What is the intended event arrival order when window is maximized/minimized?

Currently on Windows when I maximize a window, I receive events in the following order:

  1. Position
  2. Maximized
  3. Size

Is this consistent between platforms or is it not guaranteed? I would actually expect events to arrive in the following order:

  1. Maximized
  2. Position
  3. Size

This would be achievable if maximized event was tracked via WM_SYSCOMMAND (wParam == SC_MAXIMIZE), which arrives before WM_MOVE and WM_SIZE. Currently it is tracked via WM_SIZE (wParam == SIZE_MAXIMIZED), but WM_SIZE arrives after WM_MOVE - hence the current order.

2

The order of events is not guaranteed.

With enough code event order could absolutely be made consistent, but GLFW isn’t trying to be a perfect abstraction. Rather it tries to be easily used, read, debugged and modified while also behaving as natively as possible on each platform. It’s compromises all the way down.

Enforcing a behavior that goes “against the grain” of a system tends to produce brittle code. Your proposed solution is an unintentional example, as WM_SYSCOMMAND isn’t emitted when maximizing a window via ShowWindow. That could be fixed with another workaround, but multiplied by all currently undefined behavior GLFW would become large, hard to maintain and harder to extend.

That said, we have been tightening the specification during 3.x when that has turned out to be a good trade-off. The current docs promise a lot more than 3.0 did.

3

Awesome! Thanks for your answer.
I should have rtfm’d more before posting this question.