Re: [Perlplusplugin-developers] More on X-events
Status: Beta
Brought to you by:
fholtry
From: Frank H. <fh...@lu...> - 2000-09-20 15:05:06
|
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 | ------------------------------------------------------------------------------- |