0.7.xdev does not dock certain applications

[Michael B. Trausch]

Found in: AllTray trunk (0.7.2dev+ from lp:alltray r39)

AllTray fails to dock applications which are started with a wrapper shell script, such as OpenOffice.org and MonoDevelop. This is because the wrapper script is started by AllTray and (naturally) has a different process ID than the target windows to dock. AllTray needs some way of accurately detecting target applications. It is likely that the shell script's process ID will be the parent process ID of the actual program in most (if not all) of these cases, so that needs to be looked into.

[Michael B. Trausch (mtrausch)]

I have this working in trunk for some things, like MonoDevelop, but not others (such as OpenOffice.org). It'd appear that OpenOffice.org's shell script dies at some point before the user interface actually appears, and so the means that are being used to detect this type of situation are ineffective, because OpenOffice.org's process then has a PPID of 1 because init inherits it.

Need to find out if the children of zombies are considered to be orphans or not, and whether or not that is a portable idea, though... or think of another way to try to catch that that isn't specifically special-casing.

[Michael B. Trausch (mtrausch)]

This bug depends on bug 382548.

[Michael B. Trausch (mtrausch)]

I have AllTray attaching to grandchildren... when we know that they're our grandchildren. Looks like I am going to have to add some sort of heuristics to detect KDE apps and OpenOffice.org, though...

[Michael B. Trausch (mtrausch)]

This bug is really getting to be annoying me. :-)

I thought I had found a solution, but Unix-like systems seem to consider zombie processes' children to be orphaned, so trying to keep AllTray's child process around as a way of retaining the PID for its children (by preserving the child's PPID value) doesn't work out, at least on Linux and NetBSD.

One potential solution that I have thought of is to simply use a helper library that can provide assistance by intercepting fork() and returning information to the parent AllTray process. The only problem that I can think of there is that it wouldn't work for application software that has to run setuid or setgid, because the dynamic linker (at least on Linux, don't know about other systems) won't let that happen without the library itself being setuid/setgid, which is less than desirable. However, I haven't (yet) come up with an alternative to that...

Arrgh. Why can't the world just be happy place and let zombies have children?

[Michael B. Trausch (mtrausch)]

This bug is squashed in lp:alltray r95. Woo-hoo! :)