gancarz@decvax.UUCP (02/27/87)
In article <> don@BRILLIG.UMD.EDU (Don Hopkins) writes: > >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? Putting the entire toolkit on the server's machine would tend to overburden the server. Many of the toolkit components have a fair number of calculations to perform. This computation would be better off in the client's address space where it can be farmed off to remote machines. Why would you want just one client to configure? The proposed architecture for the standard toolkit allows you to configure all clients at once, yet you can tailor each client individually to the n-th degree. Furthermore, you may want multiple instances of the same client to have different visual attributes to make it easier to distinguish them. (How many people on a LAN use only one instance of 'xload'?) Breaking the toolkit out as a separate process sounds tempting, but I would question whether it be would be a big win for highly interactive applications. The communications paths would become a bottleneck because, for every user interaction, at least two IPC calls would occur: one between the server and the toolkit, and one between the application client and the toolkit. Text widgets would certainly suffer in this case. Ditto for valuators and scroll bars tied to graphics windows. The X11 server should not be used as a primary means of communication between two clients because there are other, more generic mechanisms provided by the operating system for accomplishing the same thing efficiently. >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? A standard on key or mouse bindings isn't evil and may even be helpful. There is already implicit agreement between window managers and clients. For example, although the "button-grabbing" window managers let you grab the mouse buttons without any modifiers, most documentation warns against this practice. I believe a reasonable standard is that applications NEVER grab the buttons with modifiers. But, if they must, at least make the modifiers user-tailorable. That leaves the meta keys open for window managers and other "global" applications. I already see this as an emerging standard. I'll take the Fifth regarding what window managers should do with events. Few people fully understand this area. This will be better understood when X11-style window managers become the vogue. > >Perhaps the window manager is the place to put the ToolKit? The communications overhead would be prohibitively expensive for reasons described above. --Mike