Path: utzoo!attcan!uunet!husc6!bloom-beacon!WSL.DEC.COM!price
From: price@WSL.DEC.COM
Newsgroups: comp.windows.x
Subject: Re: Novice question about X toolkits
Message-ID: <8807052119.AA09762@eros.dec.com>
Date: 5 Jul 88 21:19:56 GMT
References: <9740036@hpfclp.SDE.HP.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 32


>I can easily conceive of cases where the window manager could not possibly
>place a dialog box as well as an application could (because the application
>has knowledge of the contents of the dialog box).
>
>So, I agree with you, only if you didn't mean to include transient windows
>when you said top level windows (even though they are in the sense of the
>X window tree).

Right, I guess I should have been more specific. When I stated that
window management should never be built into applications, I meant that
the application programmer should adhere to the IC3M conventions and
not take things into their own hands, ignoring the (or assuming a
particular) window manager. I believe that window managers such
as uwm are broken if they are not compliant with the current IC3M
draft spec (but, since the IC3M is currently a draft spec, I am not
surprised or disappointed [yet :-) ]).

Regarding app-defaults vs. user preference defaults: An interesting point,
but the distinction is probably not important in practice. I believe that
most window managers should attempt to grant initial geometry specs
whether user preference or programmer specified, to the best of their
ability. If I as a user have placed a geometry spec in a defaults file,
I don't want the window manager to ignore it and ask me where to place
the window.  Similarly, if a program is creating a transient window,
the window manager should attempt to honor window positioning specified
by the program, and not force a rubberbanding operation on the user.

-chuck
digital equipment corporation

% cat .std_disclaimer >/dev/null