On Thu, Nov 20, 2008 at 09:14:51PM +0200, Igor Stasenko wrote: > Hello David, > > Today i took a look at the unix port of squeak, where it deals with > host windows.. ouch!! > > The main file - sqUnixX11.c is a big bloat of C code , which tries to > deal with anything at once. ouch!!
The design intent (not mine of course) was to allow Squeak to be an X11 client with the entire world of Squeak living inside an X11 window. For sure some reorganization will be needed in order to do this differently. > I'm slowly reading it, trying to understand how it works. > The Xlib window management is quite different from what i used to see > in windoze. > As i understand, it using two windows - one for decoration and to be > managed by window managers, and second is for actual squeak content. Yes. This is because of the distiction between top-level windows and other windows on X11. X window managers treat top-level windows differently, and Squeak is running in an X window that is the child of a top-level window. Loosely speaking, the top-level window corresponds to an "application" which might have a hierarchy of windows inside it. In the case of Squeak, only one child window is needed because Squeak takes over from there and everything else is "inside of" Squeak itself. > The number of flags, settings, startup options to set-up a host window > is overwhelming. The docs, as for everything in unixes, is quite > obscure and often don't tell anything about purpose of option/function > - just what it does and what it expects as input. Yes, it's enough to make your head spin. Note however that this is not really a Unix thing. X11 was developed for VMS and DECNet as well as Unix, and proprietary DEC systems used X11 for many years. It runs on other operating systems and network transports also. But the Unix flavors seem to have outlived the other better-documented proprietary operating systems ;) Also I have to say that when you see the size of the bookshelf required to document X11, it really makes you appreciate something like Squeak where everything from top to bottom is visible and you can figure the whole thing out on your own. > As i see in sqUnixEvent.c , the windowIndex member of events is > ignored and set to 0. So at first stage it would require to change > functions there to honor a window index. I think that's right. > I found some analogies with my windoze code - you are also keep own > private registry for host windows and operating with 1-based window > handles (i'm using 0-based index). Yes. The VM needs to keep track of host windows, because there is no good way to ask the window manager to do it for you. > There is a couple of interesting things which i discovered: > any action, like window move & size can be completely ignored by window > manager. This is fundamental to X window. Squeak is the client. It can ask the server to do things, but the window manager and the X server are in control. An important aspect of this (that I thought about but did not implement) is to figure out how many connections there should be to the X server, and how the X events should be routed to Squeak. Traditionally (in Ian's implementation), there is one top-level X window being managed by the X window manager, a child window in which Squeak lives, and a single communication channel between the client application (the Squeak VM) and the X server. Any X event that arrives on this channel can just be delivered to "all of Squeak" and there is no need to figure out which X window it refers to. In order to expand this to work for multiple host windows, you want to figure out if each host window should live inside an X window within its own top-level X window (that is how I was doing it), or should each host window be a child of a single Squeak window (this might make sense if the intent of the host windows was to implement widgets such as buttons and text boxes for example). Also, you need to decide if each top-level host window should have its own separate communication session to the X server such that X events are naturally delivered to that window, or if there should be one connection with code to dispatch the events to the right destination. Either way, the X events need to get back to the VM in such a way that the correct X windows are refreshed, and the correct semaphore or process gets alerted in the Squeak image. I'm writing this from memory so I probable have messed up some of the details, but that is the general idea. As I said, I never did finish an implementation. It can certainly be done, but it will require some more thinking about the design, as well as some reorganization of the current Unix X11 support code. Dave _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
