barmar@think.COM (Barry Margolin) (06/22/88)
In article <8806211610.AA15708@leviathan.cs.umd.edu> ogata@LEVIATHAN.CS.UMD.EDU (Jeff Ogata) writes: >Why window managers? Couldn't all the functions of the window >manager be handled by default widget code that the clients had more control >over? Or something? Am I missing something obvious that only window managers >can do adequately? I think there are a couple of reasons for window managers. First of all, it reduces network I/O, by allowing many of the routine, repetitive actions of managing a set of windows to be done in the server, without requiring an excessive set of messages between the client and server machines. Second, it guarantees a certain level of consistency. If window manager functionality were moved into client libraries then things would be weird if two clients were using the same server but incompatible toolkit libraries. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jkh@ardent.UUCP (06/22/88)
>I think there are a couple of reasons for window managers. First of >all, it reduces network I/O, by allowing many of the routine, >repetitive actions of managing a set of windows to be done in the >server, without requiring an excessive set of messages between the >client and server machines. Actually, it doesn't buy you that. Since the window manager is a client like anything else, the round trip time still exists. In fact, because of some of the mechanisms often required to implement certain types of window managers, having a window manager configure a window is often quite a bit more expensive than just having the window move itself. What the window manager buys you more than anything else is the ability to change the "look and feel" (oh no! lawsuit! lawsuit!) of an arbitrary set of client windows without having to recompile them with a different toolkit (or whatever library you implement to handle window management at the client level). You're free to run any window manager you want, and as long as it follows some reasonable set of conventions, the client doesn't have to know which one it is. Window managers also allow a more "global" viewpoint on the window hierarchy, which makes things like tiling window managers possible. It would be very difficult (not to mention really messy) to do that sort of thing at the client level. Jordan Hubbard
diamant@hpfclp.SDE.HP.COM (John Diamant) (06/23/88)
> Couldn't all the functions of the window manager be handled by default > widget code that the clients had more control over? Well, yes they could, but there are good reasons not to. First of all, that would cause all clients to grow unnecessarily (now the code is all shared in the window manager). Second, and more importantly, the purpose of the window maanger is to manage shared resources (screen real estate, in this case). No single application can understand the requirements of all the applications unless it is designed to know about all the applications (as window managers are). For instance, how would you implement a tiling layout policy within each individual application? They have to know about each other to tile properly. Finally, applications are written independent of the window manager used, so the end user gets to decide what window management policy (and what window manager) he wants to run. Putting all the options in each application would be virutally impossible (and a waste of effort and space). John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
jeff@rainy.atmos.washington.edu (efBwe) (06/28/88)
In article <8806221643.AA00408@scrod.ardent.com>, jkh@ardent.UUCP writes: > What the window manager buys you more than anything else is the ability > to change the "look and feel" (oh no! lawsuit! lawsuit!) of an arbitrary > set of client windows without having to recompile them with a different > toolkit (or whatever library you implement to handle window management at the > client level). You're free to run any window manager you want, and as > long as it follows some reasonable set of conventions, the client doesn't > have to know which one it is. I think that's what window managers are for too. But it's not enough. I'd like to see a more general manager that handles more context sensitive things such as scroll bars and menus. Users have different preferences about these sorts of things as well. Take xterm (X11) for example. I, personally, am driven up the wall by the xterm scroll bar. When I press the left mouse button it, intuitively enough, displays an upward pointing arrow but it moves the window *down*. I would also like it to have real estate driven menu selection as well so I don't have to press the control key to get the menus up and remember which button runs which menu. These are things which I should be able to fix in all applications uniformly by specifying preferences to some manager. It's true that this would complicate the world a bit by making applications dependant on the window manager for such things but this could be solved by having them handled in a default way by X itself and grabbed by clients (particularly window managers). For example, if an application has several menus all with titles it could notify the system of their existence and if there was no window manager to handle them the system could default to displaying them in a stacked fashion when any mouse button is pressed in the window for that application. A window manager could then grab them and assign them to particular buttons or to special regions on the screen (in the title bar perhaps). I think the more user interface functionality we can put into a more global manager the better off we'll be in terms of consistency.