From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <200512042300.jB4N0eH08548@zamenhof.cs.utwente.nl>
References: <2186708a75eab646a7016140a1f91784@plan9.bell-labs.com>
	<439096F7.2020900@lanl.gov> <4390AE03.9060606@village.com>
	<50D14CA6-11E3-4300-9F84-F92EF42B87D2@telus.net>
	<200512022048.jB2Km9W02755@zamenhof.cs.utwente.nl>
	<200512042300.jB4N0eH08548@zamenhof.cs.utwente.nl>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0270C500-6902-4BF0-9E3C-A097A4EFF6BD@telus.net>
Content-Transfer-Encoding: 7bit
From: Paul Lalonde <plalonde@telus.net>
Subject: Re: p9p open apps in same window (Re: [9fans] 9con in Madrid?)
Date: Sun,  4 Dec 2005 15:13:26 -0800
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Topicbox-Message-UUID: b7ee8f78-ead0-11e9-9d60-3106f5b1d025

My current hack is based on the window ID in the environment; it  
works reasonably well with one caveat: the calling application should  
not use the window while the callee has it.  The X sync problem that  
happens is because the caller is called to resize, as well as the  
callee.  As far as mouse and keyboard events, that seems fine, as I  
redirect them to the new (child) window to receive them first.   I  
think there are really a limited number of cases to lock to stop the  
problem.

What does plan9 do when in a rio window I call "acme &"?  Does the  
acme still take over the window?  What happens to the shell?

One of the things that I have with my hack is a trivial "window"  
program that works like the plan9 one - very useful.  A wloc based on  
xwininfo rounds it out.  The last thing that it caused was more  
fussing with new namespace policies and service inheritance from a  
parent namespace.  It's ok for my current purposes, but still a  
little clunky.

Paul

On 4-Dec-05, at 3:00 PM, Axel Belinfante wrote:
> Thinking (just a bit) more...
> the env var is irrelevant since with above
> approach rio will never see it anyway  -
> rio will only see that a new window appears.
> Rio does know which window is currently active,
> and thus it might just decide to replace (overlay)
> the 'body' of that one, if it is an 9term
> (it can recognize those using X properties, I'm pretty sure)
>
> Something like plan9's window would then be useful
> to explicitly create new windows (9terms or directly apps)
> (dunno if it's already there)
> That should also take care of windows that are
> programmatically created on startup.