On Fri, Sep 04, 2009 at 08:43:35PM +0200, Carlos R. Mafra wrote: > Ok, it may not be "wrong" per se, but it also makes wmaker > fail to restore the session correctly for me (it probably works for > you because 'xulrunner' is in your PATH). This doesn't work for me either, because xulrunner is just an application launcher and it needs certain env. variables to be set.
> For thunderbird 'xprop' tells me this
> WM_COMMAND(STRING) = { "/usr/lib64/thunderbird-2.0.0.22/thunderbird-bin" }
This is for old TB with statically-linked xulrunner.
> So I was just wondering if wmaker could have some other way of getting the
> "true" command used to start the application, and not believe faithfully in
> the
> "lies" (or imprecisions) that the applications may tell.
Not unless you can associate window with docked appicon with
EXEC. However, this also can be incorrect with shared appicons.
With FF 3.x and TB 3.x they both will fall on one appicon because
of xulrunner.Xulrunner WM_CLASS.
Another method is to look at PID (_NET_WM_PID property) and get
/proc/PID/cmdline, but this should be done iff WM_COMMAND is
unset and you sure that _NET_WM_PID contains local process id:
_NET_WM_PID(CARDINAL) = 11831
WM_CLIENT_MACHINE(STRING) = "hell.fortress"
In this example FF is running on remote host, WM_CLIENT_MACHINE
doesn't match $HOSTNAME.
However, you'll get the same results (thunderbird-bin), because
real command a) may be (grand)*parent of a given process, b) may
not even exist because of "exec". In my example
/proc/11831/cmdline contains /usr/bin/xulrunner.
--
Regards,
Sir Raorn.
signature.asc
Description: Digital signature
