Always a pleasure, thanks. I won't take credit for the Pascal wrapper of XForms. I just updated and cleaned up some FreePascal stuff for my use. I did notice the latest XForms was even better than 10 years ago. The Image library component of XForms is also worth mentioning, since it gives you a direct mapping to the screen. You are right "OK. We steered this thread sufficiently far away from flu-shots, and I feel good about that." My wife and I moved here from the U of M when we had children in the early 80s. I don't know how else to avoid the drug carnage, but the hillbilly culture is also dead end. My engineer daughter's wedding was at the JJHill library in St. Paul, with some password of "books." Her new father-in-law is a 75y/o Paleontology professor in Lubbock, Texas who now seriously questions Darwin because he is studying modern Biophysics of genetics and cell biology. Thanks for helping hold civilization together. We can't afford to lose it. Iznogoud wrote: > Still sounds to me like you are living a pretty good life in the boonies. > > A lot was discussed on USENET in the 90s and on webpages in early 2000s > about the "backwardness" of the X11 client/server terminology. My personal > understanding, and the best explanation I can provide to clear up confusion, > is that an X server "serves the display" to clients who want to "connect and > display on it." Remember, on Linux, the user sitting at the X server's display > does not even own the X server process. But to be clear, to do 3D acceleration > there are some devices that need to be owned by the user, and the starting of > the X session makes sure that ownership of those devices in /dev/ are handed > to the user. I am rusty on this, but it has been like that since the 90s. And > I just looked, and on my desktop right now I am the owner of /dev/xconsole. > > Yup... It can confuse people; I can see that. > > Your book probably has a much better high-level explanation of the graphics > context than I can provide. In a nutshell, all drawing happens through some > kind of graphics context, and there are separate graphics contexts for > different functionality. Programmatically, you just create the GC type that > you need and then you start using its resources. Not much to know here unless > you are diving deep into the X architecture, which is probably not worth your > time right now. > > If you have got as far as hacking Pascal together with C for X11 client > applications, you are not exactly a n00b then... > > Unix sockets are great, and simple to program. "Unidirectional pipes," which > is what you were talking about with those two file descriptors, I use all the > time for real-time applications that require communication across threads. > I use POSIX threads (always), and I make unidirectional pipes in order to > pass data across them instead of using shared memory and dealing with race > conditions. I put the output file descriptor of the unidirectional pipe in > a "select() monitoring state with a long timeout, and trap events as they > come, meaning one thread piping data to the other. It has never let me down. > But if anyone has a better method, I am dying to hear it. > >> >> Unix was engineered, and works like a symphony orchestra. >> > > The fact that so much was ported to Linux/BSD from modern, desktop-use driven, > single-user oriented platforms (like Windows) is a testament to an excellent > OS architecture. Some old American programmers in the 70s can stand proudly. > > OK. We steered this thread sufficiently far away from flu-shots, and I feel > good about that. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >