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
pop@linus.mitre.org (Paul O. Perry) (02/19/91)
> In article <1504@ipsi.UUCP> zhao@ipsi.UUCP (Jian Zhao) writes: I could not reach you by email direct, so at the risk of exposing some silly ideas to the net, here it goes .. >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. Good question ! I don't think that there is a strait forward way to do this because the server maintains instance hierarchies of windows, not of widgets. > 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)? Yes, this I know you can do because I have tried it out. I had one client open a window, then have a second client find the window of the first and then draw into that same window. For the second client to identify the first's window you need some way of distinguishing it, and what I did was to attach a window property (or atom) to the top level window with a string of the name of the application. You might consider the same approach for a widget set, but now you have to change the widget set to post properties on the windows of their widgets :-( . This would allow child widgets to find their parents. I can see that this approach might not be enough though, particularly for constraint widgets, which would have to know something about their children (i.e. how they want to be managed). >The initial motivation of above requirement is to construct concurrent user >interfaces in a uniform and easy way. If this is the goal, then maybe the above cludge will not do since the performance of properties might not be up to snuff. Alternatively you might consider grafting a widget set into the server so that the server now knows all that it needs to know. This may seem silly at first, but it was suggested by Richard Stallman at Xhibition'89 in another context. At the time it was apparent that a widget set was duplicating state of what the server already had, and putting the widget set in the server would cut down on all that waste. Of course, at the time no one could have agreed on which, if any, widget set should be put in a server, but in time things might change. The other advantage of putting the widget set in the server is that if R5 comes out with a multi-threaded version then the necessary support for concurrency might be in place (of course, the proof is in the details). Finally, if the widget set is in the server then it might reduce the amount of messages to and from the client. Just some thoughts off the top of my head (wrong as they may be). I would be very much interested in any other responses you receive on the subject. Thanks, Paul. Paul O. Perry MITRE Corporation Phone: (617) 271-5230 Burlington Road pop@mitre.org Bedford, MA 01730 UUCP: ...{decvax,philabs,genrad}!linus!pop -- Paul O. Perry MITRE Corporation Phone: (617) 271-5230 Burlington Road pop@mitre.org Bedford, MA 01730 UUCP: ...{decvax,philabs,genrad}!linus!pop