doc@jalapeno.UUCP (Tom Dockery) (01/05/90)
ficc!peter (Peter da Silva) writes: >A dominant standard toolkit is something I'd like to see very much... >but should it be so tightly tied to X? In programming in X, the UI >tends to dominate the app. This tends to lead to unfortunate consequences. >Like, say you want a program to go away for a while and do some work. >Under X you lose the UI... and you can't even put up an "I'm busy" sign >because it won't get displayed until you return to the event loop. >-- Huh? Much as I prefer NeWS to X, in this case I must point out a couple of inaccuracies. While it is true that if the client program is otherwise occupied, it will ignore anything on the event pipeline (they *do* queue up), This can be dealt with by taking advantage of the multitasking nature of the OS. So instead of tightly binding to the toolkit, simply use interprocess communication; or use multi-threading (light-weight processes) if supported by the OS. OK, that's a bit of a hack that I shouldnt *have* to do, and it wont work under MS-DOS (but we are talking *real* OS here), but in practice it isnt that hard, and works just fine. Does this sound like a hack to make X act like NeWS? You bet! And it greatly improves X's manners, which is a great argument for the superiority of the NeWS approach to server design. Secondly the "I`m busy" sign is simple; pop up the stupid thing *before* you go out to lunch. The event loop simply calls the "out to lunch" sign before it goes, and takes it down after it gets back. The event loop is one way; I can send stuff to the server from anywhere, once the connection is established. Indeed, the initial contact and initialization of resources in the server is generally made before the event loop is even started. To make a human analogy, I dont expect to be able to put up my sign after I'm already at the pizzeria; I do it on my way out. Tom Dockery Market Focus Technologies
brewer@ANTARES.MCS.ANL.GOV (01/05/90)
fajita!jalapeno!doc@suntan.West.Sun.COM (Tom Dockery) writes >ficc!peter (Peter da Silva) writes: >>A dominant standard toolkit is something I'd like to see very much... >>but should it be so tightly tied to X? In programming in X, the UI >>tends to dominate the app. This tends to lead to unfortunate consequences. >>Like, say you want a program to go away for a while and do some work. >>Under X you lose the UI... and you can't even put up an "I'm busy" sign >>because it won't get displayed until you return to the event loop. >>-- [Some stuff deleted] >Secondly the "I`m busy" sign is simple; pop up the stupid thing >*before* you go out to lunch. The event loop simply calls the "out to >lunch" sign before it goes, and takes it down after it gets back. The >event loop is one way; I can send stuff to the server from anywhere, >once the connection is established. Indeed, the initial contact and >initialization of resources in the server is generally made before the >event loop is even started. To make a human analogy, I dont expect to >be able to put up my sign after I'm already at the pizzeria; I do it on >my way out. But how about something like continously updating a counter or some informational text while the application is doing its work? I want to be able to change something on the screen while the application is working in order to let the user know how the processing is going (i.e. number of things done, what it is currently doing, etc.). I'm sure there is probably a hack to do it, but what a pain in the ass. I don't want to program a workaround for every little thing like that. (And please don't anyone tell me its a "feature"; which reminds me of my favorite X windows joke: Q. How do most X programmers spend their time? A. Programming workarounds to X windows "features.") Orlie Brewer Mathematics and Computer Science Division, Argonne National Laboratory 9700 South Cass Avenue, Argonne, Illinois 60439 (312) 972 - 5094, brewer@mcs.anl.gov