Path: utzoo!censor!geac!jtsv16!uunet!bloom-beacon!BRILLIG.UMD.EDU!don From: don@BRILLIG.UMD.EDU (Don Hopkins) Newsgroups: comp.windows.x Subject: Window Managers and Client Menus Message-ID: <8909191608.AA14078@brillig.umd.edu> Date: 19 Sep 89 16:08:21 GMT References: <8909181736.AA04699@gaak.LCS.MIT.EDU> Organization: The Internet Lines: 83 I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process. I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching. Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-) c(-; Once were done forging the menu manager standard, how about we do text editors, huh?) -Don Date: Mon, 23 Feb 87 18:31:00 EST From: Don Hopkins Message-Id: <8702232331.AA08434@brillig.umd.edu> To: cartan!weyl.Berkeley.EDU!rusty@ucbvax.berkeley.edu Cc: xpert@athena.mit.edu In-Reply-To: cartan!weyl.Berkeley.EDU!rusty@ucbvax.berkeley.edu's message of 23 Feb 87 19:44:43 GMT Subject: Uwm extensions, perhaps? Date: 23 Feb 87 19:44:43 GMT From: cartan!weyl.Berkeley.EDU!rusty@ucbvax.berkeley.edu (Rusty Wright) In article <8702211303.AA01735@gjetost.wisc.edu> solomon@GJETOST.WISC.EDU (Marvin Solomon) writes: >... > >What's the solution? I think it is to get rid of the idea of window >manager as a separate process, and build "window-manager" functions >into all windows. That scares me. Wouldn't we then have the problem that suntools has where the suntool binaries are huge? On my sun 3/50 the suntools program itself is 728 blocks and the various other tools that run under suntools are 952 blocks. Yuck. How about setting up some sort of standard? For example, all window managers must use control+shift when the mouse is in a window or an icon, and when it's in the background the control+shift is optional. -------------------------------------- rusty c. wright rusty@weyl.berkeley.edu ucbvax!weyl!rusty I see just the same problem with XToolKit. I would like to see the ToolKit as a client that you would normally run on the same machine as the server, for speed. Interactive widgets would be much more interactive, you wouldn't have to have a copy of the whole library in every client, and there would be just one client to configure. The big question is how do your clients communicate with it? Are the facilities in X11 sufficient? Or would it be a good idea to adopt some other standard for communication between clients? At the X conference, it was said that the X11 server should be used by clients to rendezvous with each other, but not as a primary means of communication. Why is that? Setting a standard on any kind of key or mouse bindings would be evil. The window manager should be as transparent as possible. It solves lots of problems for it to be able to send any event to the clients. For example, how about function to quote an event that the window manager would normally intercept, and send it on? Perhaps the window manager is the place to put the ToolKit? -Don