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