Re: [Perlplusplugin-developers] More on X-events

[Frank H. <fh...@lu...>]

On 20 Sep 2000, Dmitry Karasik wrote:

 >
 >Hi Frank!
 >
 > Frank> This code successfully preserves the Perl/Tk windows most of the
 > Frank> time, but not quite all the time.  I attribute this to the fact
 > Frank> that it sometimes loses the race with the X-server, but I don't
 > Frank> know a way yet to prove that's what happens.
 > 
 >I looked at the script, but I can't test it right now - I'm testing
 >now the Plugin <-> Prima ipc, and I'm currently under win32.

Are you dual-booting?  There's an incredible virtual machine called
Vmware (http://www.vmware.com) that let's you run two (or more) OS's
simultaneously on X86 machines.  Simple keystrokes let you move back
and forth between them.  I use it daily on my desktop at work because I
have to work in Unix/Linux and Winnt environments.

 >As you say, it is not a reliable method to catch events - my idea is, that
 >using the module I'm writing now, it will be possible to get notification
 >directly from the plugin. That should be working in win32, but I can't say
 >anything about X until I test it. The solution I'm trying to make is that
 >the Plugin ( or Netscape) would send a reliable signal to a listening perl
 >program. 
 >   But anyway, I have to get the thick X book, because the whole thing looks very
 >strange - the DestroyNotify comes bottom-up, that's right - but I believed
 >that under any circumstances a child could access it's parent.

With X, you have a minimum of two independant processes involved all the
time.  The X server is responsible for creating and managing the windows
and your application has to request those services from it.  With the
current plugin design you add the Perl interpreter as a third independant
process.  Window resources are sort of jointly owned by the X server and
whatever process requested their creation.  They can prevent other
processes from accessing the resources, including the events.  Even though
the owning process may allow for instance a third process to reparent 
windows into it's heirarchy, that doesn't necessarily imply that the third
process has accesss to any other resources.  I established mostly by trial
and error which events the Perl process could mask on which windows.  


 >I have to look at the manual, or maybe if you have one, please find these

Check http://www.x.org and http://www.rahul.net/kenton/xsites.framed.html.
The kenton site has a huge amount of information on X , including an html
version of the Xlib manual.  I actually just discovered this site this
morning because ftp://ftp.x.org, which used to have a lot of such stuff,
is either down or dead.  Kenton looks like a better choice anyway.

 >specifications also - because mine isn't full.
 > 
 >  PS. - From the other hand, if the X protocol guarantess that a parent is always
 >visible to a child, it is not a race then, but something else.

This is an area where I'm a little fuzzy as to just how X
works.  According to the docs, the X server is supposed to wait for all
processes that have masked an event to respond to it.  Especially with the
DestroyNotify event, this would seem to be critical so that the process
could preserve any state it needed before the window was destroyed.  My
experience with the Plugin seems to indicate this isn't always what
happens.  What I don't know is how the X server determines that a process
has trapped the event and responded to it.  It could be that the process
needs to explicitly signal the server; maybe Perl/Tk does that too
soon. It could be too that the only process waited for is the 
owner/creator.  I just don't know at the moment.
 
 >( an error in the manual :)
 >
 >--
 >Sincerely,
 >	Dmitry
 >
 >--- www.karasik.eu.org ---
 >
 >_______________________________________________
 >Perlplusplugin-developers mailing list
 >Per...@li...
 >http://lists.sourceforge.net/mailman/listinfo/perlplusplugin-developers
 >

-- 
-------------------------------------------------------------------------------
| Frank Holtry           | "If you have the right attitude, interesting       |
| fh...@av...      |  problems will find you."                          |
|                        |                            Eric S. Raymond         |
-------------------------------------------------------------------------------