maximized state and normal frame size lost after hide/show

[Cosmin Apreutesei]

> Aha.
>
> XWithdrawWindow() basically tells the windowmanager: "please forget about
> this window. I'll now re-use it for entirely different purposes"

I see. So the WM removes the state because it thinks I'm done with the
window. I have to find another way then.

> The correct solution depends on what you're trying to do,

I'm trying to hide a window and then later be able to put it back it
in its previous state (that includes maximized state).

I'll try XUnmapWindow() and send UnmapNotify myself like Qt does, see
how that goes.

> FYI, X11 is not an API but a protocol.

Well, I think this is a false dichotomy. It's not like I have a
problem with the wire format :) Besides, that's not even technically
true if you want to use OpenGL these days.

> APIs like Xlib or xcb implement it
> and user code would rather use toolkits like Qt, gtk, fltk, ... which more
> or less nicely abtract the usual tasks.

That's the advice I see everywhere. "Hey, X is not for you, so you'd
better swallow up a 50MB pile of C++ whose build system alone has more
LOC that your entire X backend will ever have.". Well, I don't buy it.
Just look at the X backends in Qt, GLFW, SDL, Chromium, etc. it's a
battlefield. Doesn't look like these will end my pains automatically.
They look more like a big rug to sweep X under to me :)

>> function restore()
>>    if minimized() then
>>       unminimize()
>>    elseif maximized() then
>>       unmaximize()
>>    end
>> end
>>
>> If that's not provided by the API already, how can I possibly
>> implement the above with an async API?
>
>
> I'm not actually sure where you see an async problem in the above -

Well, what does the following sequence do with an async API on a
maximized window that is also minimized?

    restore()
    restore()

 - with an async API the second call will go through the first branch
since the window wasn't unminimized yet;
 - with a blocking API it would do what you expect;
 - with an async API that implements restore() itself as a single
command it would also do what you expect.

The fact that you didn't see any problem with that code should be
evidence of how non-intuitive async APIs are. You simply can't mix
commands with queries with async APIs (incidentally this is why grabs
i.e. command queues were invented but they're limited to
mouse/keyboard).

> if you want to wait for a reaction of the window manager process, you obviously need to wait for that

This is what I'm doing now (empty-the-queue, issue-the-command,
poll-until-specific-event) but:

 - if the event I'm waiting for doesn't come my app will block forever.
 - discarding events while waiting might invalidate any tracked state
(like the window's normal position that we discussed before).

I just don't feel the robustness, you know :)

> You're confusing things here in that X11 is, as mentioned, NOT an API and
> Xlib is a very low-level API. It's not meant to be "simple".

Nice try :) First, low-level APIs don't have to be complex, they can
be simple and powerful. Second, you can't just call something bad
"complex" and hope people won't notice the difference and leave you
alone :)

X is bad because it talks to both clients (toolkits, apps) and WMs
using the same API, when in fact clients should only ever talk to WMs
and shouldn't even be able to connect to X. Clients would then target
WMs and would be able to use specific features of each WM like the
ability to maximize a window, or the ability to create a notification
icon or an OSX-style top-edge menu bar, or the ability to use
on-screen input methods. You see, it's fine that X is all mechanism
and no policy. Problem is, **user interaction is all about policy**.
If X would've been architected that way, Mir wouldn't even happen.
Here them out: "we think that the handling of input methods should be
reflected in the display server protocol, too. As another example, we
consider the shell integration parts of the protocol as privileged and
we'd rather avoid having any sort of shell behavior defined in the
client facing protocol." Don't get me wrong, I don't think Mir folks
know what they're doing any more than Wayland folks do because I don't
think that either team has been much on the other side of their APIs
to really know how it feels, i.e. it doesn't look like they design
these APIs from user code... but what do I know about any of this :)