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