2008/11/21 David T. Lewis <[EMAIL PROTECTED]>: > 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. > Yup
>> 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. Inside only, or just have a child-parent relation? I mean, does a child-parent implies, that child window should live inside rect designated by parent and parent always acts as background window, or its free to be placed anywhere? > 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. > Of course, because there is a single window. But once you have many... > 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). > I think i will support both options. You should be able to create a top-level windows as well as childs of existing top-level window. I'm not sure however how things play well with coordinate system & events in latter case. I'm also concerned a bit with a window manager communication. How to tell window manager that window should have different decoration, like having static border, or can't be closed (don't show close button) , or having no decoration at all - only area for painting etc. I want (at least try) to support a set of generic assets throughout all platforms. > 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 don't see the need in having multiple comm channels. Squeak VM having single event queue, that's makes no sense to use multiple queues inside X11 backend. Of couse if X11 allows to manage everything through single channel. > 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. > Thanks for explanation anyway. Since i never did anything for X11, so any bit of information is wellcome :) > Dave > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
