Re: [Nautilus-list] remembering different properties in different directories?

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes: 
> OK, I think that's interesting for a personal prototype but I don't
> think application authors should have to design their apps to work
> with your admittedly non-production-suitable system.
> 
> Honestly I think your change is pretty illusionary, because apps will
> just end up setting the wrong semantic type or weird hints to bypass
> your rules, which will result in an even more broken system than
> letting apps do what they want.

You're missing that designing the app to work with it is something you
have reasons to do anyway, because all the semantic types are also
decorated differently. So yes you can set type DOCK or UTILITY to be
able to position your non-DOCK app, but then the decorations will be
wrong and the iconize/maximize controls will be wrong. And on the flip
side, if you don't set the semantic types, you also don't get the
right decorations and controls. So the positioning stuff falls
naturally out of the spec as it already is.

But the point is that apps don't need to bypass the rules, once you
handle most cases where they currently want to. And we're quite close
to that already, because Metacity is quite usable without letting apps
set sizes/positions at all, and the cases where it breaks fall into
some easy categories like splash screens.

Once you find all the cases that you need to handle, you could enable
PSize and PPosition in the final released solution. Disabling them is
a tripwire for detecting apps that rely on them. That's the prototype
part.

> I had a much longer response in mind, but since you don't think your
> experiment is suitable for real-world use, I don't think Nautilus or
> other apps should be changed to take it into acount, and so debating
> the issue is not worthwhile.

You misunderstand - I think this is a genuine problem, I'm just saying
Metacity isn't a final solution. By saying Metacity is a prototype, I
don't mean to say it's addressing non-issues, they are real issues.

Because we have an unspecified area, we currently have 5% of
situations broken; changing only the WM to my way makes a different 5%
break, but still 5% broken. To get the 5% fixed, it needs to be fully
specified how things should work.

Thus the purpose of the prototype is to try out one way of doing so,
namely, extending the available hints to get semantic
relevant-to-positioning info to the window manager. As I said, the
other possibilities for fixing the last 5% are to simply remove all
placement policy from the WM and put it in apps/toolkit, or to define
the exact policy and who implements which part. Maybe there are still
more, but I haven't thought of them yet.

I think my way (all policy in WM) is easiest, largely because it's the
way the EWMH spec is designed to work, and the way the ICCCM is
designed to work, and the way SubstructureRedirectMask works. The
"prototype" aspect is that it totally ignores configure requests. That
would be dumped in the final correct scheme; reason I have it right
now is to find cases where apps are needing it.

(Importantly though, note that configure request always has to be
ignored in some cases - e.g. during a window resize operation. So an
app that _relied_ on configure request being honored would definitely
be broken, regardless of this current debate...)

Basically, there should be some way for all apps to work 99-100%
correctly; of course that won't happen, but at the moment it's
_impossible_, even if I'm a very conscientous app author.

(Just to make this remotely relevant to Nautilus - restoring window
positions via a semantic mechanism, such as a "restored window ID,"
would allow the WM to decide not to restore a position in certain
cases, such as "the window is off the screen due to resolution change"
or "the window is in the middle of my Xinerama." i.e. it would allow
policy to be implemented. Right now the app asserts unconditionally
that it wants the window at X,Y, and the WM doesn't know if the reason
for that outweighs or does not outweigh the two considerations I just
mentioned. So the app would need to handle all those cases. In fact
this is a problem currently - many apps need to be hacked to fix
behavior with Xinerama, because they set PPosition. But anytime the
app tries to emulate WM policies, you are either introducing
inconsistency (broken), or you are having to assume what the WM policy
is (though it's not currently specified). Ergo, anything an app does
now is either creating inconsistent UI or relying on something
not-yet-specified and not reliable in the wild. QED.)

> I guess I'd like to add that even though ICCCM allows the window
> manager to ignore application size change requests, it's impossible to
> write reasonable apps under that assumption

It works fine nearly all the time. You forget I'm not just
speculating, I've been using a WM in this mode for a month or two. ;-)

As you probably know, the ICCCM doesn't assume all WMs will honor
PPosition, it actually goes out of its way to say that some won't, and
mentions crackrock like tiling window managers. Moreover the whole
USPosition/PPosition distinction only makes sense if you assume
PPosition can be ignored. So a WM that ignores this hint is entirely
in the spirit of the ICCCM. We aren't talking about MS implementing
POSIX here. Not a fair analogy.

If you're advocating the status quo you're advocating the "punt"
solution, which is to leave it broken - not try to resolve for example
the issue of having apps that remember their size/position, thus
hosing placement policies which are sometimes important; or the issue
of consistent dialog placement; or the issue of what to do with an app
that is too large for the screen.

Admittedly, not earth-shattering issues, but at the same time, would
be nice to fix, and not really that hard to fix. We can at least go
from 5% breakage to 1% ;-)

Unlike a few years ago, we're in a position to enhance the WM hints
and get them deployed in a few years, X isn't totally stagnant
anymore. The EWMH is essentially intended to be a way to do what I'm
saying here.

Havoc