Re: Draft 1.9c

[raster rasterman com]

On 24 Nov, Greg J. Badros scribbled:
->  raster@rasterman.com writes:
->  
->  > On 24 Nov, Greg J. Badros scribbled:
->  > ->  raster@rasterman.com writes:
->  > ->  
->  > ->  <snip>
->  > ->  
->  > ->  > actually there is alreayd a machine name property as part of icccm:
->  > ->  > WM_CLIENT_MACHINE(STRING) = "raster.su.valinux.com"
->  > ->  > 
->  > ->  > so u use this in combo with PID (which fills the missing link) and then
->  > ->  > the WM or taskbar or whatever can manage all apps that are onthe same
->  > ->  > machine - and even coudl spawn helper apps on the particular machine
->  > ->  > the app is running on (if it van do this) to try kill or whatevre its
->  > ->  > pid there... so as long as we have a machien name AND a PId -we're set
->  > ->  
->  > ->  We actually can do this for legacy applications via the
->  > ->  "scwm_set_pid_property.so" module that comes in
->  > ->  scwm/utilities/pidproperty.  Then you do:
->  > ->  
->  > ->  LD_PRELOAD=$exec_prefix/scwm_set_pid_property.so xlogo
->  > 
->  > oh scwm did an alpreload hack! DAMN! i was planning on doign that..
->  > didnt know.. cool.. i shodul check it out.. :) i wonder if its done as
->  > efficiently as it coudl be.. dunno.. need to read src.. this sia good
->  > call - i was planning on having an LD_PRELOAD AND a hacked Xlib too
->  > (replacement Xlib soi distributions coudl include it)
->  > 
->  > if a wm (or helper app) spawns the process it can add the LD_PRELOAD to
->  > the env (tho SUID apps wont work.. but thats a minefield on its own)
->  > 
->  > very good.. :) excellent.. :)
->  
->  Glad you like it;  I thought it was pretty clever, but was surprised
->  when we (Toby Sargeant and I) pulled it off.  (Actually while down
->  under, in fact -- maybe it's something in the Australian air that
->  suggests the id).
->  
->  WRT efficiency, we just do a little bit of extra work on XCreateWindow
->  and XCreateSimpleWindow calls before handing off to the real routine.
->  There's a small hit, but not noticeable, for sure.  Certainly your
->  feedback is appreciated.

hmm - well i was going to impliment it as follows:

hook to XcreateWindow, XCreateSimpleWindow AND XReparentWindow.
if the parent window for the creates is root then and ONLY then set it.
if a window is reparented to the root window THEN and ONYL THEn set the
property.

this woudl mean only toplevels have the ID. shoudl be more efficient -
i can't think of a too mucg more efficient way of doing it. (

->  > ->  and the xlogo window gets its SCWM_RUNNING_PID property set to be its
->  > ->  process id.   Scwm also provides a helper procedure, too:
->  > ->  
->  > ->  (window-pid WINDOW)
->  > ->  
->  > ->  The pid property stuff also lets you set another arbitrary Id which is
->  > ->  useful for reliably determining which execution of a process a popped-up 
->  > ->  window corresponds to.  (E.g., to be able to treat a single start of an
->  > ->  application differently in the window manager, w/o affecting its X
->  > ->  resource name or titlebar name).
->  > 
->  > well thsi can be done just by PID :) oh hold on.. hmm no actually if
->  > the spawnign spawns a process that spawns yet another process that
->  > spanws yet another process (ie scriptS) then we have isses.. yes an
->  > inherited evnironment variable set by the wm fo rthat "launch" that is
->  > then set on all widnows displayed by that app.. yes.. i see this use..
->  > perhaps it shoudl be in the spec (apps have to set a property ont he
->  > window thta is the contents of thsi variable (numeric) ie:
->  > _NET_INSTANCE_ID(CARDINAL)
->  
->  Right.  It gets tricky in even simple cases of shell-scripts that wrap
->  starting a GUI tool.
->  
->  I think these sorts of things should also be proposed to the XFree folks 
->  since support from them will make the legacy application issue go away
->  on their X servers (and perhaps commercial X servers will then follow).

well thats easy to do.. I can handle some of that myself and submit
patches - nee dot discuss ont he xfree86 list first - but i'm on the
xfree86 devel list - the onyl issue here is standards - it needs to
kind of be agreed on - technically its a no-brainer and we coudl get
dirstibutions and vendors to ship patched xlibs easily.

->  Greg

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com     raster@valinux.com
                                    raster@enlightenment.org raster@linux.com
				    raster@zip.com.au