maximized state and normal frame size lost after hide/show

[Cosmin Apreutesei]

> However, I believe you hardly ever have a real use for that.

I want to make a cross-platform API that has well-specified behavior.
An underspecified API that behaves differently for even the most basic
tasks it's not very useful. I don't wanna say "don't expect events to
fire in any order or always, don't expect commands to always work or
to exhibit predictable behavior" and call that a good job. That's not
a good job, that's just low standards :)

> For your specific case, why are you calling restore() twice in a row?

See above, but please note that the question is a slippery slope (i.e.
next you might ask why I need a restore() method at all and so on).
But to answer your question: I've put restore() on the Esc key for a
certain window. I was used to hitting Esc twice to get to normal
state. In Linux that didn't work. I hit many little annoyances like
that in the course of development which made for an awful dev
experience so naturally I want to plug in as many of these little
behavioral holes as I can. Apps break at the seams, not in the middle
:)

> But if you only talk to the WM you would never be able to render anything into the client area of your window.

WM is maybe not the right term. "WM/shell" might be better? The
WM/shell should provide the _entire language of interaction _ with the
user from opengl contexts to input methods to open/save dialogs. Just
like the Windows API :)

> Do you really think this is a good idea? It would mean that if you write
> your application for Unity, it will only work on Unity. You want to make
> it work with Gnome, you will have to provide a separate implementation
> for that. And then another one for Kde. And another for fvwm. And
> another for ion3. And another for xmonad. Etc.

Yes but there wouldn't be that many because the requirements for a
good WM/shell would be much higher then. You would have to make an
actual value proposition to the app dev to make her target your WM.
Right now your WM is just an annoying "test target" (i.e. I have to
test my app on your WM because I can't be confident that my app won't
misbehave just because I followed EMWH or because I use Qt or
whatever).

Once you have a few stable and popular WM/shells, not too many, the
incentives for abstraction would then appear. Right now abstraction
stems from recommendation-grade paper standards (ICCCM etc) that cover
a very small portion of functionality, instead of being actual
software that abstracts existing actual software. It's completely
backwards. Behavioral standards are a dead-end IMHO.

> Right. And if you try to force your policy on the user against the user's wishes and the WM's design, it will be hard to make that work.

I'm not sure I can link that to what I said. But anyway, this is
interesting because I keep hearing that. This general distrust of the
GUI developer, where does that come from? Do you think that a GUI dev
should have _less_, rather than _more_ power in order to be able to do
a good job at making a good UI?

> And it mostly works.

Descriptive standards tend to have that "mostly" effect :) Imagine if
the ARM spec would be like that, we probably wouldn't have smartphones
:)

> Or to put it another way: If X had defined policy, we wouldn't have any
> Gnome, Kde, awesome or ratpoison. We would have only mwm. If we were
> lucky. Freeing the WM from the display server has enabled the
> development of alternative policies.

Exactly my point -- X should stay mechanism-only, but apps should not
connect to it. But they shouldn't bring their own toolkits either!
Instead, there should be a stable (i.e. forever backwards compat)
DE+WM+everything shell API that's always on the user system like
WinAPI is. It's really the only way to shave any market share from MS
and to bring app devs to Linux. It looks like Canonical is kinda
starting to get it, I'm not sure how seriously though :)

> I think the infrastructure should not itself focus on programmer-friendly APIs.

I agree. Which is why I think X should not be visible to apps but
should only be the compositing+input API of WM/shells.