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

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes:  
> There's lots of reasons an application may want to change size or
> position in an application-controlled rather than
> window-manager-controlled way. The window manager can handle most
> user-directed size and position changes but it has no clue about the
> application-specific context. 

Sadly, by my count the vast majority of apps that try to change
size/position are doing something that results in inconsistent UI and
broken window behavior. 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.

Yes, 5% of apps may have a good excuse. So we need to provide
structured semantic escape hatches that allow those excuses through.

> Consider my thread recently about smoothly resizing windows when the
> contents change. There's no way the window manager can handle that
> because it knows nothing about the window context.

I think smoothly resizing may require window manager support in any
case, even for a WM that honors all app requests. It depends on
exactly what you want to do.


The basic issue is the following. To have sane positioning/resize
behavior, you have to implement rules and policies for how all the
competing factors (user's placement policy, semantic window type, 
blah blah) come together to result in a nice UI. There are three ways
to do this:

 - have the entire policy in the application (not possible without 
   scrapping much of the ICCCM and existing WM behavior, and giving 
   apps knowledge of other windows on the screen, and dispensing 
   with user ability to configure the policy globally)
 - have the entire policy in the window manager
 - carefully specify the exact policy, and have clear app
   responsibilities, and clear WM responsibilities, in 
   clearly-defined situations (removes ability to change 
   the policy)

The current situation is that the policy is theoretically in the
window manager, but most WMs let apps override the WM policy; however,
apps do that at random and inconsistently, with no clear guidelines on
when or why. My argument would be that apps _can't_ know what to do,
because they don't have all the necessary information about user
config, other windows on the screen, etc. to make an informed choice.

The reason apps _want_ to override is that from time to time they do
have an extra bit of info that should be taken into account for
handling a particular window in a particular circumstance. I believe
the simplest path to a fully correct UI here is to have apps convey
this information to the window manager when appropriate. The window
type hint in EWMH is a good start that handles many cases.  The
proposal I've had on wm-spec-list for restoring window positions (as
for a Nautilus file window) I think handles the other big case. At
that point I think the problem will be solved, pretty much.

I'm actively pushing to extend the WM spec for this, because I'm
really sold on how much nicer Metacity is due to ignoring various
pieces of application crackrock and enforcing a consistent UI instead.

Plus, I think it is simply a logically inevitable fact that having
both the app and the window manager able to position a window, with no
clear spec for when one should do it vs. the other, cannot lead to a
coherent window size/positioning policy. Look at the entire history of
the X window system UI sucking for empirical evidence, if you don't
buy the a priori argument. ;-)

Havoc