[dev] Odds and ends (2/2): $XEMBED

From: Connor Lane Smith <cls_AT_lubutu.com>
Date: Tue, 21 Apr 2015 20:16:53 +0100

Hi again,

In Plan 9, when one executes a graphical program from a terminal
window it will take over that window, so that running a graphical text
editor like Sam from a terminal is not so different from running a
line editor. This was one of my favourite things from the Plan 9 GUI.

Plan 9 Port doesn't do this, perhaps because it isn't possible in
general to identify an X window to make an X embed request to unless
you have its XID -- PIDs, for example, are unreliable (e.g. remote
programs). So, like all other X programs, running a graphical program
in Plan 9 Port will open it as a separate window, leaving the terminal
idle until the graphical program has closed.

My suggestion is that we use an environment variable, say $XEMBED, to
store the XID to which a spawned graphical process should make an
embedding request. The program would check the environment, and
whether it is a foreground process in its terminal (getpgrp() ==
tcgetpgrp(STDOUT_FILENO)). If $XEMBED is set and it is a foreground
process then it would make an X embed request.

This means that a terminal like 9term can have the same behaviour as
on Plan 9, without having to hardcode programs' embedding options, and
running a program in background is not disturbed. Programs that do not
support $XEMBED but do support X embedding would have to be wrapped
(e.g. with next.sh). But I reckon this behaviour is something worth
having.

Thanks,
cls
Received on Tue Apr 21 2015 - 21:16:53 CEST