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

[Havoc Pennington <hp redhat com>]

Hi,

I suppose this is a bit off-topic for nautilus-list, but it's a fun
thread anyhow... ;-)

Maciej Stachowiak <mjs noisehavoc org> writes: 
> Apps are responsible for most of their own sizing and positioning on
> Mac OS X and it works pretty well.

Yes, Mac classic works this way too, I read up on it in the Mac
HIG. But you also can't configure the window size/positioning policy
I'm guessing, or at least can't plug arbitrary policies, and I bet the
GUI toolkit enforces policy such as where dialogs appear with respect
to the main document window. (Since you have a standard GUI toolkit.)
On X, people expect to configure things and/or swap out window
managers, and there is no standard toolkit where policy can be placed.

This is simply the first of the approaches I listed that would work -
the app being totally in control, with a style-guide or
toolkit-enforced policy.

> > Using Metacity which denies apps this ability, I get much more
> > predictable and consistent window behavior, it's very nice. The UI
> > is simply better.
> 
> Can you cite some specific examples of what is better?

 - apps never randomly override placement policy. e.g. gnome-terminal
   insists on doing this, but I have it turned off, so my placement
   policy is honored. I see regular posts on gtk-list where people
   want to force a startup position in their apps.

 - dialogs always appear centered over the app, right now horizontally 
   centered and vertically just under the transient parent titlebar;
   if no transient parent, they appear centered on the screen.
   While if you honor positions, sometimes they are centered onscreen,
   sometimes over app vertically centered, sometimes over app under
   the titlebar (and sometimes GTK_WIN_POS_MOUSE, horrors).

 - xmms doesn't work

 - AisleRiot never decides its titlebar should be offscreen (to be
   fair, the real culprit here is Sawfish's gravity-guessing
   heuristic)

 - web sites with obnoxious popups (or pop-unders). Metacity does a
   good job of disallowing pop-unders, and keeping popups from being
   in irritating places. (an example of apps that are
   hostile/untrusted...)

> > Yes, 5% of apps may have a good excuse. So we need to provide
> > structured semantic escape hatches that allow those excuses through.
> 
> Ultimately you'll end up reimplementing full size/positioning support
> but through a different mechanism than the standard one. I'm not
> really sure how this is a win.

If you do the restore win position thing (as for Nautilus windows),
the last two missing semantic types (UTILITY and SPLASHSCREEN), the
FULLSCREEN state, and honor geometry hints, it works pretty well.

The reason to ignore the standard mechanism is that it's broken - the
ICCCM doesn't say the WM has to honor it, in fact says the WM is
allowed not to, and it doesn't say when the app should set it, and
when the app should leave it alone - because these things aren't
specified, you can't know whether it's correct to set the position in
any given case. Apps in fact do NOT currently have any way to set
position/size reliably, and any app that relies on being able to do so
is broken - you can't do that in X. The ICCCM does not specify any way
to set position that is guaranteed to actually happen.

Any new hint would have to specify under what circumstances the app
can be considered to know better than the WM where to put a window,
and I don't actually know what those circumstances would be.  But then
the WM would be able to honor the hint in those cases, without
e.g. having dialogs placed in random application-specific places.

(Note that there actually is a way to force Metacity to resize a
window - change the min/max size in the geometry hints to the size you
want, then change them back - but don't tell anyone... ;-)

(Also, xmms could work using the new _NET_WM_MOVE_RESIZE hint, but 
don't tell anyone that either ;-)
 
> This may make sense for individual positioning (even then I'd
> disagree, because the application-specific situation is often more
> important than any concerns about other windows on the screen).

Examples of when the app situation is more important for placement?

> 1) The panel changes size when I change a panel's type from edge to
> aligned or whatever.

DOCK semantic type is allowed to self-size/position.

> 2) When I scale down an image in the gimp, the window containing the
> image resizes correspondingly.

I think that sounds awful, I would consider it a benefit to disable
this. (Gimp actually has it off by default, it's a user preference. I
think the way the feature should probably be implemented is via
geometry hints anyway, not via configure request. So then it would
work when ignoring configure requests.)

> 3) Gnome Mines changes the window size when I change the game grid
> size.

If gnomine wasn't broken (and it is), it would change both min and max
size geometry hint, i.e. the window should not be user-resizable - try
expanding the window now, and see why it's currently broken.

Metacity honors geometry hints, so still works if gnomine is fixed.
It doesn't fail catastrophically right now, it just gets in the same
state it's in if you resize the window larger manually.

> 4) When I set my mpeg player to play a clip in double size, the window
> resizes.

Changes min size geometry hint, so still works.

> 5) When I change the terminal's font size, the window resizes (in
> pixels) to maintain the same character row x column size.

Indeed, broken right now ;-) (Not totally broken, since the size hints
change and you do get the proper size increments.)

I can easily imagine handling this special case (permit resize from
old size to new size with same row x column), though I don't know if
it's a special instance of some general case.
 
I do already save app sizes across sessions this way, in --geometry
format, which fixes a bug you get with most WM's now if you change the
gnome-terminal font and don't resave your session.

> All of these resize requests are obviously correct and should be
> honored. What is the benefit of ignoring them? 

Most of them _are_ honored, because the necessary semantic info is
already reflected in the size hints, the configure request is just
cruft.
 
> I think the more general problem is lack of policy.

Well yes, as I said, an alternative solution to this is to simply spec
out the entire policy, and make apps or some defined cooperation of
apps/WM responsible for implementing it. But that isn't going to
happen. So any policy we get will be window-manager-imposed.

There are two other approaches other than "WM fully in control," those
are "just define a single policy" and "have the app fully in control."
If you're going to have a programmatically-defined pluggable policy,
either the app or the WM has to be in control, using hints provided by
the other. i.e. we need to get all the relevant info into one C
function to be considered appropriately.



Seriously, I would probably honor all configure requests on semantic
type NORMAL if I had to ship Metacity as more than my personal
entertainment prototype, and probably would honor size changes on
dialogs. The only thing I'd probably put in production is ignoring
position hints on dialogs. This is because on some level you can't
fight the system, and also because of GUI toolkit API complexity -
"just set the position" is the only thing most developers will
understand.

But for my personal use, I prefer to have some apps that don't work
quite as intended (e.g. splashscreen gets cascaded), than have dialogs
jumping around and gnome-terminals in stupid places and so on.  Also,
I like windows to stay the size/position I made them, changing at
runtime breaks how I've arranged my windows. And I can fix all the
apps I use personally to support the semantic types and correct
geometry hints, because they are all open source. ;-) So the "app
authors won't understand it" argument doesn't matter so much to me.

Also, I want to prototype a WM that ignores configure requests, so I
can see the issues involved and get all the needed semantic hints in
the EWMH spec, or at least see that it won't work for reasons XYZ.  It
isn't really bloating EWMH, because the semantic types all involve
different decorations, etc. in addition to size handling.

Havoc