Open GoogleCodeExporter opened 8 years ago
Since the X monad and the Query monad are MonadIO instances, I suppose it's
easy to write to files. Is there a simple way to create a window and write to
it?
Original comment by wei....@gmail.com
on 21 Jan 2010 at 4:29
I think I've found the issue. The way SpawnOn works is by associating a
managehook which will move the program to a specific workspace, with the
program's pid. Say we want to execute opera, the pid we recorded is for
"/bin/sh
/usr/bin/opera".
However, when manageSpawn comes to manage the spawned program, the pid it
sees is for "/usr/bin/opera", different from what we recorded. Therefore, it
does
nothing, and opera is placed on our current window.
This issues begs a question: why does spawnPID do a double-fork? Below is code
from XMonad.Core:
-- | spawn. Launch an external application. Specifically, it double-forks and
-- runs the 'String' you pass as a command to /bin/sh.
spawn :: MonadIO m => String -> m ()
spawn x = spawnPID x >> return ()
-- | Like 'spawn', but returns the 'ProcessID' of the launched application
spawnPID :: MonadIO m => String -> m ProcessID
spawnPID x = xfork $ executeFile "/bin/sh" False ["-c", x] Nothing
Original comment by wei....@gmail.com
on 21 Jan 2010 at 7:35
For tracing execution, you can use XMonad.trace if you have a MonadIO m =>
...,
otherwise you can use Debug.Trace.trace, which will print stuff when otherwise
pure
code is evaluated.
This patch might be helpful:
http://www.haskell.org/pipermail/xmonad/2009-September/008474.html
But I can't comment on the need to fork processes x times.
Original comment by vogt.a...@gmail.com
on 21 Jan 2010 at 4:02
@vogt.adam, Thanks for your comment. The patch you're linking to does address
the
issue, but it's against pre-0.9.1. I don't know how to adapt it to the latest
version.
Original comment by wei....@gmail.com
on 21 Jan 2010 at 7:12
You could still use it with 0.9.1, here's how:
darcs get --tag 0.9.1 http://code.haskell.org/XMonadContrib
darcs apply --mark-conflicts path/to/patch
$EDITOR xmonad-contrib.cabal
And the only conflicts to resolve are the dependencies for xmonad (so keep them
like
0.9.1, but add filepath or something).
Original comment by vogt.a...@gmail.com
on 21 Jan 2010 at 7:54
Please ignore my comment about spawnPID, it's not the culprit. I'll try to
adapt the
patch to the darcs version.
Original comment by wei....@gmail.com
on 22 Jan 2010 at 2:59
It's kind of hard to fully wrap my head around Daniel Wagner's patch, so I
created
my own hack. Hope it's useful for other people.
Original comment by wei....@gmail.com
on 22 Jan 2010 at 6:02
Attachments:
Were the previous patches rejected due to the portability of the procfs?
Is this a won't-fix then?
Original comment by wil...@willem.vanlint.name
on 5 Aug 2011 at 7:39
If it needs to look for children of the spawned process, two possibilities
occur to me:
(a) use ps; assume POSIX compliance, or test for BSDish vs. POSIX
(b) there are portable libraries for this kind of thing, although the
dependencies may get interesting (the most portable one I can think of is
libgtop...).
Off the top of my head, various Unix-like OSes and the normal ways to get at
this information:
* Solaris: libkvm or /proc (note that /proc is not the same as on Linux or
*BSD)
* *BSD, OS X: sysctl; libkvm is available for the *BSDs but not OS X
* Linux: /proc; libkvm is available
libkvm has the difficulty that it usually requires setgid kmem, so you'd need a
setgid helper program.
It would be better, both for this and for startup notification in desktop
managers, if someone had had the sense to recognize that a variant of
_NET_WM_PID that recorded and passed on the pid of the original process would
be useful, but the free desktop folks seem to have missed that notion. (Hm;
maybe the way to go from here is to look at how desktop managers do startup
notification and borrow that. I believe it's a freedesktop.org standard.)
http://standards.freedesktop.org/startup-notification-spec/startup-notification-
0.1.txt
There's also a reference implementation which might be worth interfacing to or
reimplementing in Haskell.
Original comment by allber...@gmail.com
on 6 Aug 2011 at 12:30
Original issue reported on code.google.com by
wei....@gmail.com
on 21 Jan 2010 at 4:19Attachments: