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.
