maximized state and normal frame size lost after hide/show

[Eirik Byrkjeflot Anonsen]

Cosmin Apreutesei <cosmin.apreutesei at gmail.com> writes:

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

That's the reason I always try to avoid any applications written in
Java/Swing, and will never implement any of my own applications in that
framework. They insisted on having a well-specified behaviour rather
than following the platform's standard behaviour.

> 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 :)

There are certainly some guarantees that an API should make. However,
the guarantee of exact behaviour in all cases is not one of them. There
are plenty of cases where it is entirely reasonable to only make partial
guarantees.

For example, in a system where there are individual events to report the
new size and position of a window there is no compelling reason to
guarantee that the size events always comes before the position events
(or vice versa) when both size and position changes at the same time.
But certainly there should be a guarantee that any change in size and/or
position will generate suitable events.

But more importantly, an API that goes for fully specifying the
behaviour of all operations is likely to end up specifying behaviours
that are in conflict with the user's expectations and wishes. Users have
different ideas about what is a good user experience, and if the
application does not respect that, the user will be unhappy. This
particularly applies to inter-application issues such as window
management (I know I am usually unhappy when an application chooses to
override my window manager's behaviour.)

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

Well, I was wondering a bit about that. It seemed like an odd thing to
want :)  (Though I can see some potential use cases)

> 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
> :)

Hmm, I see. Ok, you make a point. But I still think in total there are
better solutions to that problem than requiring synchronous behaviour
with all its downsides. (For your use case, handle double-pressing Esc
as a single event to bring the window to "normal" mode, rather than two
Esc events as individual "restore one layer of flags" requests. Yes,
that is a workaround for being in an async environment rather than a
"good solution" on its own. Then again, as I say later, I really don't
think it is a "good solution" to have each application do window
management policies on its own either.)

Of course, when you say that you hit many little annoyances when porting
code from one system to another, that's just the way it is. Different
systems behaves differently and porting is always a pain. It is quite
impressive which assumptions you don't know you made until you run into
a system that doesn't fulfill those assumptions :)

>> 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 :)

Yes, "WM" or "WM/shell" is not the right term. What you describe is a
"toolkit". And that is exactly why everybody says you should use Qt or
Gtk (or one of the others). Those are toolkits. On windows, there is a
toolkit built-in to the "operating system". On linux there is not. On
linux, there isn't even some way to put graphics on the screen at all.
You need something like X for that. And X just provides the foundations
that more complex systems, like toolkits, can build on without trying to
mandate which toolkit you should use.

However, if you have chosen to draw the boundary of "the operating
system" between x.org and the toolkits (a pretty arbitrary choice,
really) and you don't like the idea of using anything not part of "the
operating system", then there is still a toolkit that you can use: Xt.
This is the closest you'll get to a "built-in" toolkit for X. It is
pretty much the X equivalent of the windows toolkit. I wouldn't
recommend it, though. It is pretty horrible by modern standards. (Though
I understand it was pretty good at the time it was created.)

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

I think you're completely wrong about that. But my argument ended up way
too long, so I'm dropping it :)

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

I did extrapolate a bit :)

The fact that you made a function that could be called from the
application that looked a lot like window management functionality, made
me think you probably were trying to do window management policy in the
application. And your full example above actually bears me out.

To clarify: You think that it is a useful interaction pattern to press
Esc to turn a minimized window into a maximized window (when the window
was maximized before being minimized). And you further think it is
useful to press Esc to turn a maximized window into the normal mode. I
know you think so, because you said that was what you did and why you
have this method.

I think you may be right. I don't think I would prefer that interaction
pattern, but I can accept that other people might.

However, this is clearly a "window management" interaction pattern. It
isn't part of what your application does within its client area, it is
part of how your application's outer window is handled. So doing this
from the application itself seems odd. If you think this is a useful
interaction pattern, it should be useful for *all* applications. Thus
this is something that should be done in the WM, rather than by each
application on its own.

And of course, for a user who does not think this is a good interaction
pattern, you have now forced your window management policy on that user.
In this particular case, chances are users wouldn't be annoyed by it, as
the pattern wouldn't be triggered in cases where the user wouldn't
expect it. Probably.

That being said, I agree that sometimes it makes sense to "break the
rules". I just don't think that should be the normal choice.

(I seem to remember having used a few applications that took it upon
themselves to implement "better" window management behaviours. Some of
which actually had a nice behaviour. And I seem to remember that after
using them for a short while I got sufficiently fed up with the
inconsistensies that I stopped using them, even if they were "better".
Unfortunately, I can't remember any actual examples.)

> 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?

It is a very interesting point, because I also hear that
counter-argument a lot. I even make it myself :)

There is no doubt that giving the GUI dev more power is all good, *all
else being equal*. But all else is rarely equal. If giving the GUI dev
more power means taking that power away from the WM devs, then the
trade-off may not be a good one.

It is not that I distrust the GUI developer more than other developers.
However, window management policies are patterns that should apply to
all applications. I certainly trust a single application (the WM) to be
able to do that in a coherent manner much more than I trust a myriad of
individual GUI developers working independently to end up with a
consistent user experience. That's why I say it is bad idea to implement
window management policy in each application.

Also, of course, if it is done in the WM, there is only a single place
to change if someone comes up with a better pattern. If we leave it to
each individual application, changing common patterns will be pretty
much impossible.

>> 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 :)

Hmm, ok I think I start seeing where you are coming from.

First of all, using a standard toolkit (like Qt or Gtk) is not "bringing
your own toolkit". Arguably, coding directly to Xlib *is* "bringing your
own toolkit", but that's a bit of a red herring.

It is true that some systems may not have your toolkit of choice
pre-installed, but I think you will have problems finding any reasonably
mainstream distribution where Qt and Gtk are not trivially accessible
and installable. Far more so than e.g. DirectX on Windows. In fact, I
think most systems already have both installed, because they will be
using at least one application that needs each.

In summary, I don't think it is unreasonable to require the user to
install one of the mainstream toolkits in order to use your application.

I believe any requirement of a single, well-defined,
backwards-compatible desktop environment stack would be extremely
detrimental to the improvement of the desktop experience. I believe the
possibility of choice is a great driver for experimentation with new
ideas, and that this is essential to making things better.

In fact, I'm convinced we wouldn't have the high-quality toolkits of
today, if there had been a strong mindset of the backwards compatible
desktop environment stack. We would probably still be using Xt.

Yes, there are compatibility issues, and I must say I think MS have done
a marvellous job with their compatibility work. And yet, they aren't
fully backwards compatible either. There are plenty of older
applications that does not work on newer Windows. Windows 7 even shipped
with a license to run Windows XP in a virtual machine to provide the
maximum backwards compatibility.

(Also, I don't particularly care about taking market share from MS. I
just want a high-quality system I can work with and play with. In fact,
I have a suspicion that "taking market share from MS" is one reason for
some of the less fortunate developments of the "linux desktop
experience".)


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

Which is exactly what we have. And everyone says so: Use a toolkit, not
Xlib!

(Sorry for the long mail. I tend to write too much.)

eirik