Some programs (e.g., WPS office, Steam) might unmap its window(s)
but keep them in the background instead of destroying them immediately.
It is up to the programs (i.e., owner of the windows) when to reuse them,
so we should not simply destroy these windows, or these programs might
have undefined behaviors!
We should 'unmanage' these windows when they are unmapped and store
them somewhere (so that we know they're hidden, and might be reused
sometime in the future by their owner programs). When the owner programs
want to reuse these window (most likely via XConfigureRequest),
we will manage these window again.
The windows unmapped by a program itself will be stored here:
std::unordered_set\<Window> hiddenwindows;
Note: Only windows unmapped by their owner programs will be affected
by this commit, while windows unmapped by the user/wm will not.
This commit fixes issue #23.
Some programs (e.g., WPS office, Steam) might unmap its window(s) but keep them in the background instead of destroying them immediately. It is up to the programs (i.e., owner of the windows) when to reuse them, so we should not simply destroy these windows, or these programs might have undefined behaviors!
We should 'unmanage' these windows when they are unmapped and store them somewhere (so that we know they're hidden, and might be reused sometime in the future by their owner programs). When the owner programs want to reuse these window (most likely via XConfigureRequest), we will manage these window again.
The windows unmapped by a program itself will be stored here:
Note: Only windows unmapped by their owner programs will be affected by this commit, while windows unmapped by the user/wm will not.