zhao@ipsi.UUCP (Jian Zhao) (02/16/91)
I need to simulate the following behavior: In a widget tree, some subtrees belong to different clients, but their behaviors are the same as in one client. Example: a RowColumn containing two buttons. I need two buttons that are connected with two different clients, but when the RowColumn is resized, then the changes of two buttons are same as they would be in one client. The initial motivation of above requirement is to construct concurrent user interfaces in a uniform and easy way. If this is difficult on the widget level, can I do something similar on the window level (i.e. in a window tree, some subtrees are connected with different clients)? Jian Zhao GMD-IPSI (zhao@ipsi.darmstadt.gmd.dbp.de) Dolivostr. 15 (ph: 0049-6151-875868) D-6100 Darmstadt F.R. Germany
rthomson@mesa.dsd.es.com (Rich Thomson) (02/19/91)
In article <1504@ipsi.UUCP> zhao@ipsi.UUCP (Jian Zhao) writes: >In a widget tree, some subtrees belong to different clients, but their >behaviors are the same as in one client. Since widgets live inside the client process, this will be difficult without a complete rewrite of Xt. >If this is difficult on the widget level, can I do something similar on >the window level (i.e. in a window tree, some subtrees are connected with >different clients)? Windows live in the server (but are only part of the state of a widget) and any client program that knows the window ID of a window (and has a connection to the display on which the window was created) can do output to the window. However, there are some restrictions on selecting input on a window from multiple clients. Basically, selecting for a button press on a window is a one-client-only kind of operation, while selecting for an expose event on a window can be done by multiple clients. XID's (and thus window IDs) are constructed from two parts: the client part and the resource part. The client part is derived from the process id of the client, I believe. My impression is that the process creating the window in the server must still be running in order for that window to be displayed (i.e. if you kill the client, its resources are freed in the server, which includes windows). I'd be interested in hearing anything more you find out about the possibilities. Writing really big software programs that interact with the user through graphical interfaces can be problem. The solution to the "one, big executable" problem is to split the program into multiple modules, each executing in a single process (also prevents one from having to link with a huge amount of other stuff to get something that runs). However, once the process is split into multiple processes, you have a problem with the basic: while (1) GetEvent(), ProcessEvent(); model of input processing. You either have a central process that distributes the input across multiple compute processes, or a bunch of processes all attempting to manage the same input, possibly communicating back and forth to each other to establish some kind of control protocol (i.e. who has the user's focus?). -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer