Unix host windows. (Was: Re: [Pharo-project] HostWindows rewrite)
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!! 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. 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. 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 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). There is a couple of interesting things which i discovered: any action, like window move & size can be completely ignored by window manager. Its quite acceptable within my design: you could try to change any window attribute, but there is no guarantee that it will be changed or affect the host window in any way. There is even no guarantee, that given attribute exists. Of course, common attributes, like x,y,width,height, visibility, title , and maybe couple more will be always there, on all platforms. As for the rest attributes - its up to platform implementation to name them and write accessors to them. 2008/11/9 David T. Lewis <lewis@mail.msen.com>:
On Sun, Nov 09, 2008 at 05:05:45PM +0200, Igor Stasenko wrote:
2008/11/9 David T. Lewis <lewis@mail.msen.com>: Oh, that's the bits i'm missing. I found the sources of HostWindowPlugin for win and mac, but was unable to find anything for X11. Can you please send me a sources of it, or link for downloads?
There is no implementation for X11, but I posted a copy of my imcomplete work to the vm-dev list here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2008-July/001977.html
This does have enough support to permit opening windows, moving them, setting window label, etc but it is incomplete and is not integrated into Squeak in any useful way.
And of course, i don't see a need in packing X and Y into a single 32 bit int as its currently done in HostWindowPlugin.
Good, that sounds fine.
Dave
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
2008/11/21 David T. Lewis <lewis@mail.msen.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Fri, Nov 21, 2008 at 05:25:29AM +0200, Igor Stasenko wrote:
2008/11/21 David T. Lewis <lewis@mail.msen.com>:
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?
I'm not sure. Honestly I'm not an expert on this at all, I just hacked on Ian's code and looked at a couple of books. I would guess that the child windows can be placed anywhere, but that in normal operation the window manager controls the top-level window and the child windows follow along within the top-level coordinate system. But I'm not certain about this.
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.
Google ICCCM. There are some conventions for communicating with window managers, but lots of different window managers are in use and they are all different. Note, a window manager is just another X client application, separate from the X server. You could program Squeak to be an X window manager if you wanted to (might be a good project for somebody to try).
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.
Actually this might be mostly a matter of how much "rearranging" to do in the existing Unix X11 support code. Dispatching from a single channel is probably the right thing to do, but it might be easier to just open separate connections. I did not implement either one, so pick your poison ;) Dave
participants (2)
-
David T. Lewis -
Igor Stasenko