I thought I'd take a look at the X routines that are in the 2.0.1 release of Self so I would understand James Noble's stuff (when I get to see it) a bit better. I finally sat down at a console and did 'ui start' to see what happens. It definitely works... (Normally it is NCSA Telnet, X under Mach386, or DecWindows for me) It seems that one should be able to write some simple code to at least *open* a window. Alas, it never gets mapped. Can anyone shed any light on this? Is anyone else doing mainstream work on the Self X-interface. Here is the code that I put together by looking at uiX.self:
lobby _AddSlotsIfAbsent: (| mooch = () |) mooch _Define: (| parent* = traits oddball. display. window. displayName <- unix environmentVariable: 'DISPLAY'. start = ( display: xlib display open: displayName. window: xlib window createOnDisplay: display At: 5@26 Size: 500@@500. window name: 'Test #1'. window iconified: false Input: true. window map. inspect: display. inspect: window. ). |)
BTW: with regard to comment of using ':0.0' versus 'hostname:0.0': I would assume that XOpenDisplay considers :0.0 to mean unix:0.0, which usually means to open an AF_UNIX domain socket rather than an AF_INET (tcp) socket. This is usually in /tmp/.X11_unix/X?
BTW: with regard to comment of using ':0.0' versus 'hostname:0.0': I would assume that XOpenDisplay considers :0.0 to mean unix:0.0, which usually means to open an AF_UNIX domain socket rather than an AF_INET (tcp) socket. This is usually in /tmp/.X11_unix/X?
'Twas that way, but a later release (I forget which number) improved on that even further. In systems which implement shared memory, there is a three-level hierarchy:
host:0.0 - AF_INET socket unix:0.0 - AF_UNIX socket, exactly as you described :0.0 - Uses shared-memory between client & server, completely bypasses network serialization. Yes, it's a hack which might be construed to violate client/server privacy, but it *is* more efficient. If this connexion is not available, falls back to unix:0.0 behavior. In essence, ":0.0" means "local server, fastest possible connexion"; I would imagine that mechanisms other than systemV shared-memory have been implemented by various vendors.
And, as described by a previous commentor, X will not flush to the display until the event queue is polled or an explicit XFlush() given; typically it is not an issue since an application will alternate output with a call to XNextEvent() to await further user input.
- JJ Larrea
self-interest@lists.selflanguage.org
-
J. J. Larrea -
richards＠turing.scs.carleton.ca