Matthew.Diamond@MAPS.CS.CMU.EDU (02/02/90)
> Re: Beginner question: forcing update of labelWidget display > ... > The problem is that the XtSetValues() call clears the Label Widget's window, > and tells that X Server to generate an exposure event for that window. The > window will not actually get painted until your code drops back into > XtAppMainLoop() and resumes processing events. > > Can you work around this? Yes, but its pretty ugly, and could cause your > application to hang. I would suggest that you would be better served by > looking to a more event-driven model for you application. > Speaking for myself, I would be interested in hearing what the work-around is. I am writing a user-interface which is supposed to be interchangeable with an existing user-interface. The idea is that we take applications that use the old, textual interface, link them with my libraries instead, and then they have a mouse-driven, graphical interface, with no change to the application's code. The problem is that these applications were not written to the event-driven model. I can process events whenever my code is called (most user I/O is handled by me, since I am replacing keyboard procedures with code that accepts input from the mouse too). But there are times when my code is not being called and the application's display freezes for a while. I attempted to use XtAddTimeOut() to add an event-loop that would be run periodically, but of course I found that timeouts are handled in the event-loop, they are not true interrupts. Our group may find that we can live with this problem, or I may try using Unix interrupts to periodically interrupt the application, forcing it to process certain events (i.e. Expose) before continuing. But if there is another way, I'd like to hear it. Matthew Diamond MAPS Project, Carnegie-Mellon University matt@maps.cs.cmu.edu
klee@chico.pa.dec.com (Ken Lee) (02/02/90)
In article <9002011609.AA05640@ATHENA.MIT.EDU>, Matthew.Diamond@MAPS.CS.CMU.EDU writes: > The problem is that these applications were not written to the event-driven > model. I can process events whenever my code is called (most user I/O is > handled by me, since I am replacing keyboard procedures with code that accepts > input from the mouse too). But there are times when my code is not being > called and the application's display freezes for a while. Two possible solutions are: 1. Catch and dispatch events yourself, and live with non-updated displays when you can't catch events. 2. Create a second process to do X stuff using a normal X event loop and communicate with the main application using sockets, pipes, or ptys. Examples of this method include xmh, xdbx, and even xterm. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
hvr@kimba.Sun.COM (Heather Rose) (02/02/90)
In article <2654@bacchus.dec.com> klee@decwrl.dec.com writes: >In article <9002011609.AA05640@ATHENA.MIT.EDU>, >Matthew.Diamond@MAPS.CS.CMU.EDU writes: >> The problem is that these applications were not written to the event-driven >> model. I can process events whenever my code is called (most user I/O is >> handled by me, since I am replacing keyboard procedures with code that >accepts >> input from the mouse too). But there are times when my code is not being >> called and the application's display freezes for a while. > >Two possible solutions are: > >1. Catch and dispatch events yourself, and live with non-updated >displays when you can't catch events. > >2. Create a second process to do X stuff using a normal X event loop >and communicate with the main application using sockets, pipes, or >ptys. Examples of this method include xmh, xdbx, and even xterm. 3. Use the XView toolkit. The XView notifier supplies a function which is tailored to your needs, notify_do_dispatch(). The basic idea is to read from some file descriptor (perhaps stdin) and continue to process window events. I've included a short example program from the O'Reilly XView Programmer's Manual to illustrate a very simple case. This example can be found on line with the XView toolkit source, distributed with X11R4. The XView notifier provides other functionality such as notification on signals, timers, input pending on any file descriptor: sockets, pipes, files; child process death, and more. Heather ------------------------ This example is not very interesting, but it does show that you can get input from a file descriptor, do something with it, and still process window events. /* * ntfy_do_dis.c -- show an example of implicit notifier dispatching * by calling notify_do_dispatch(). Create a frame, panel and "Quit" * button, and then loop on calls to read() from stdin. Event * processing is still maintained because the Notifier uses it's own * non-blocking read(). */ #include <stdio.h> #include <xview/xview.h> #include <xview/frame.h> #include <xview/panel.h> Frame frame; main (argc, argv) int argc; char *argv[]; { Panel panel; char buf[BUFSIZ]; int n, quit(); xv_init (XV_INIT_ARGC_PTR_ARGV, &argc, argv, NULL); frame = (Frame)xv_create (NULL, FRAME, FRAME_LABEL, argv[0], XV_WIDTH, 200, XV_HEIGHT, 100, XV_SHOW, TRUE, NULL); panel = (Panel)xv_create (frame, PANEL, NULL); (void) xv_create (panel, PANEL_BUTTON, PANEL_LABEL_STRING, "Quit", PANEL_NOTIFY_PROC, quit, NULL); /* Force the frame to be displayed by flushing the server */ XFlush(xv_get(frame, XV_DISPLAY)); /* tell the Notifier that it should use its own read() so that it * can also detect and dispatch events. This allows us to loop * in this code segment and still process events. */ notify_do_dispatch(); puts("Frame being displayed -- type away."); while ((n = read(0, buf, sizeof buf)) >= 0) printf("read %d bytes\n", n); printf("read() returned %d\n", n); } int quit() { xv_destroy_safe(frame); return XV_OK; }
steve@acorn.co.uk (Steve "Daffy" Hunt) (02/14/90)
In article <131133@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: >3. Use the XView toolkit. The XView notifier supplies a function which >is tailored to your needs, notify_do_dispatch(). Yes, but what a shame Sun did not try to write it portably. I am referring to the very dubious technique of redefining syscall wrappers for read, select (and something else) and then using some parochial method for accessing the 'real' syscalls. Wacky. Steve Hunt.
stpeters@dawn.crd.ge.COM (Dick St.Peters) (02/16/90)
(Steve "Daffy" Hunt) writes > In article <131133@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: > >3. Use the XView toolkit. The XView notifier supplies a function which > >is tailored to your needs, notify_do_dispatch(). > Yes, but what a shame Sun did not try to write it portably. I am > referring to the very dubious technique of redefining syscall wrappers > for read, select (and something else) and then using some parochial > method for accessing the 'real' syscalls. Wacky. That "parochial" method is available on Ultrix machines, Masscomps, and even under Eunice, the Wollongong UNIX emulation for VMS. What a shame some vendors don't provide it. What would you have Sun do? Rewrite everyone's OS? I'll bet this method is available in SysVR4 :-) -- Dick St.Peters, GE Corporate R&D, Schenectady, NY stpeters@dawn.crd.ge.com uunet!dawn.crd.ge.com!stpeters
hvr@kimba.Sun.COM (Heather Rose) (02/16/90)
In article <1647@acorn.co.uk> steve@acorn.UUCP (Steve "daffy" Hunt) writes: >In article <131133@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: >>3. Use the XView toolkit. The XView notifier supplies a function which >>is tailored to your needs, notify_do_dispatch(). > >Yes, but what a shame Sun did not try to write it portably. I am >referring to the very dubious technique of redefining syscall wrappers >for read, select (and something else) and then using some parochial >method for accessing the 'real' syscalls. Wacky. We're working on making it portable. Suggestions/fixes welcome ;-) Heather
steve@acorn.co.uk (Steve "Daffy" Hunt) (02/16/90)
In article <9002151623.AA19195@dawn.crd.Ge.Com> stpeters@dawn.crd.ge.COM (Dick St.Peters) writes: >(Steve "Daffy" Hunt) writes > >> Yes, but what a shame Sun did not try to write it portably. I am >> referring to the very dubious technique of redefining syscall wrappers >> for read, select (and something else) and then using some parochial >> method for accessing the 'real' syscalls. Wacky. > >That "parochial" method is available on Ultrix machines, Masscomps, >and even under Eunice, the Wollongong UNIX emulation for VMS. What a >shame some vendors don't provide it. Yes, so what, it's available under any Berkeley-based system, including ours. That does not make it portable. Let's see. Syscall(). Cursory research shows that:- it's not in X/Open. it's not in ANSI. it's not in POSIX. it's not in the SVID. Looks really portable. As I originally said, it's a parochial method. From that most famous source of parochial hacks, BSD. >What would you have Sun do? Rewrite everyone's OS? I'll bet this >method is available in SysVR4 :-) It may or may not happen to appear in some SVR4 implementations, but it's not in the SVID. Besides, the very idea that you can cheerfully redefine symbols and expect everything to work is a parochialism. Steve Hunt.