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

[Havoc Pennington <hp redhat com>]

John Sullivan <sullivan spies com> writes: 
> (1) In each application. Error-prone because there's no guarantee that each
> application will do it right.
> 
> (2) In each window manager. Error-prone because there's no guarantee that
> each window manager will do it right.
> 
> (3) In some built-in part of the system, perhaps a utility in gnome-libs or
> something like that.
> 
> Each of these three approaches has its own costs and benefits. In the simple
> splash-screen case, it seems clear to me that (3) is the least problematic.

I would have phrased (3) as:

 (3) In each GUI toolkit. Error-prone because there's no guarantee
     that each GUI toolkit will do it right.

You have to put it somewhere, and trust that somewhere to do it
right. ;-) So saying there's no guarantee that XYZ will do it right
doesn't really help you decide which XYZ to put it in.

The tiebreaker, I think, is that you really want all your window
positioning to go through one function in one place, because that's
the only way to make window positioning really smart enough, and it's
also the only way to allow people to change how it works.

As soon as the positioning is in two places, you have to specify what
constitutes "do it right" and have it synced between the two.  That
removes any ability to change it, and requires the syncing step.

Note that only the window manager is guaranteed to be unique in a
given user session. Users run many apps based on multiple toolkits.
There are multiple window managers available, but a single user never
has more than one.

Say you documented in much detail what the various kinds of window
were, and how they should be placed, including all corner cases, then
got GTK and Qt and so on to implement all that. Using the same
document, you could extract the categories of window that were
documented, and the information needed to implement the behaviors
described, and provide all that to the WM. It's not any harder to do
it that way.

In any case, the essential task is to document the kinds of window and
how they should behave, that's what I'm interested in figuring out.

I don't doubt that app authors will always want to put all the logic
in their app, so they can know things will work; WM authors will
always want all the logic in the WM so they can know things will work;
and toolkit authors will want all the logic in the toolkit, so they
can know things will work. But, somebody has to lose. ;-)

Havoc