Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!bloom-beacon!spdcc!merk!alliant!linus!pop From: pop@linus.UUCP (Paul Perry) Newsgroups: comp.windows.x Subject: Re: Window Managers and Client Menus Message-ID: <72490@linus.UUCP> Date: 28 Sep 89 04:21:27 GMT Organization: The MITRE Corp., Bedford, MA Lines: 35 To: ncrlnk!wright!odin!adatta@uunet.uu.net (Amitava Datta) In-reply-to: ncrlnk!wright!odin!adatta@uunet.uu.net's message of 26 Sep 89 21:36:18 GMT On the topic of client menus, having written an application that supports multiple users, I would like to support the user interface portion AT the server so that the user gets better response and the application client isn't bogged down 'timesharing' for users. The way I do it now is to have a separate client that just handles certain menus. So I think the important point for me is not menus that conform to a window manager's look and feel but the ability to distribute the 'input' user interface portion of the client. When OSF was making a decision on their user interface RFT, it was clear that NeWS did have some nice things that X did not support. Among them, the fact that the NeWS server is a programmable server, in that, as I am told, an application can download code to the server. Could someone shed some light if X could or is not intended to incorporate such a mechanism ? If it can, then I would prefer this mechanism because it can do more that just menus (rubber-banding being a common reference). Otherwise, I would be interested in knowing why the X designers chose not to incorporate such a mechanism. (Or maybe I am just misinformed about the NeWS capabilities) Paul O. Perry Phone: (617) 271-5641 MITRE Corporation ARPA: pop@mbunix.mitre.org -- Paul O. Perry Phone: (617) 271-5641 MITRE Corporation ARPA: pop@mbunix.mitre.org Burlington Road Bedford, MA 01730