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

[Maciej Stachowiak <mjs noisehavoc org>]

On 16Oct2001 05:03PM (-0400), Havoc Pennington wrote:
> 
> 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
                                              ^
                                         on X Windows
> size/position are doing something that results in inconsistent UI and
> broken window behavior. 

Apps are responsible for most of their own sizing and positioning on
Mac OS X and it works pretty well.

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

It definitely requires window manager support. It requires the window
manager to honor the resize request. :-)

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

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

But it definitely does not apply to resizing once the window is
mapped, since that has nothing to do with global policy decisions.

In fact, I could not find any examples of this happening and having a
bad result. The five cases I found (in my brief cursory search) were:

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

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

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

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

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

All of these resize requests are obviously correct and should be
honored. What is the benefit of ignoring them? Where are the
applications that make "bad" window resize requests after mapping
which should be ignored?
 
> 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.

This may be a good solution for some cases of setting initial window
position. I don't see how it implies to post-map resizing.
 
> 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.

I think you will have to be more specific about these benefits for
your testimonial to be convincing.
 
> 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. ;-)

I think the more general problem is lack of policy. The use of many
different GUI toolkits with different behavior is an equally serious
problem (imagine a random user clicking on an Xaw application's
scrollbar), but I don't think anyone is writing a window manager that
refuses to run non-Gtk applications.

 - Maciej