Quoting Brandon Allbery (2016-03-10 18:39:01)

http://hackage.haskell.org/package/xmonad-contrib-0.12/docs/XMonad-Layout-St...

FWIW, I have considered using this but eventually just wrote a script that makes for less surprising behavior: https://gist.github.com/anonymous/a89fbe442b71cbda2b40 It should be easy enough to translate it into bassh (the only zsh-specific syntax in there is in line 44). Dependencies are pgrep, xprop and xclip. Usage: bind to a key and use to stop the process that spawned a window (hopefully anyway: not all applications play well when it comes to _NET_WM_PID). It's a bit rough around the edges but works for me (firejail broke something about it though that I still need to fix). -vrs

On Sun, Jun 12, 2016 at 3:53 PM, Adam Sjøgren wrote:

But. Uhm. What if I only want to apply it to some programs (Firefox), or one workspace (say, "3")?

Since it's a layout, you can't apply it to individual windows (or programs --- in fact you cannot with 100% reliably map a window to a program, by X11's design). For workspaces, consider XMonad.Layout.PerWorkspace. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Sun, Jun 12, 2016 at 5:02 PM, Adam Sjøgren wrote:

The documentation is confusing to me - some places '|||' is used to combine things, other places it isn't.

||| separates layouts. Layouts are complete in and of themselves. Other things are layout modifiers. As the name suggests, they modify other layouts; the layout to be modified is a parameter, and there may be other parameters which may also be workspaces. Maybe this will be clearer: Full -- this is a layout, it can stand by itself or be modified smartBorders Full -- this is a layout modifier applied to a layout smartBorders -- this is an error, because it is not applied to a layout. "It is a purple." -- a purple *what*? smartBorders ||| Full -- this is an error because you are saying "either use smartBorders or use Full". But smartBorders is not a layout , layoutHook = avoidStruts $ layoutHook defaultConfig |||

modWorkspace "3" stoppable (layoutHook defaultConfig)

which doesn't seem to work, as the browser running on workspace 3 (mod-3 takes me there), keeps using 5-8% CPU according to top when another workspace is active.

I hate their example because it is not clear that it has all the layouts in defaultConfig twice and only the second list has the stop behavior. You need to mod-space 3 times to get to a stoppable layout. If you want stoppable to always be active on workspace 3: layoutHook = avoidStruts $ modWorkspace "3" stoppable $ layoutHook defaultConfig (I find it interesting that you were able to figure out that modWorkspace applies only to layout modifiers as opposed to layouts, but you couldn't recognize that (|||) only works with layouts, not layout modifiers.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Mon, Jun 13, 2016 at 11:43 AM, Adam Sjøgren wrote:

I am trying that now, and it doesn't seem to work for me - the Firefox on workspace 3 is still using 5-10% CPU, regardless of how long I have been on another workspace.

I was waiting to see if the author of the contrib would jump in, but I guess not. (Contribs are contributed, as the name suggests, and we can't necessarily support all of them directly.) That said, browsers are likely to be a specific screw case these days because sandboxing means that windows or even individual tabs may be running in their own processes (they certainly are in Chrome / chromium). It is not reliably possible (indeed, not necessarily possible at all) to go from an X11 window to all the associated processes, especially going in both directions (that is, downward from a window to tab sandbox processes *and* up from it to the parent browser process(es)), so stopping the whole browser is not going to happen and individual tab processes may well keep running as well, with only the process that created the window itself stopped. (I can't speak for Firefox, but for Chrome this will be a process largely independent of all the tabs, other windows, and various other working processes including any installed apps.) I could also imagine the browser not handling this well since it might well not expect a single process in the chain to be stopped (...or it might handle it by sending SIGCONT on seeing a process come back to waitpid() with WSTOPPED, defeating the layout modifier). -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Tue, Jun 14, 2016 at 5:52 PM, Adam Sjøgren wrote:

If I move xeyes to workspace 3, the state keeps being reported as 'S' by ps. It never changes to 'T', even 15 seconds after switching to workspace 1.

Wait, are you ever making workspace 3 current in this, or just moving with mod-shift-3? Layouts don't (and can't) react to the latter; the layout can only stop and start processes when you switch to or away from a workspace. The shift operation only manipulates the StackSet without informing the layout. (In theory a layout could be notified, but it'd require more layout methods and those methods would have to guarantee they don't try to draw anything or manipulate the screen / windows directly because the workspace might not be current.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Tue, Jun 14, 2016 at 6:11 PM, Adam Sjøgren wrote:

Brandon writes:

...

On Tue, Jun 14, 2016 at 5:52 PM, Adam Sjøgren wrote:

...

...

If I move xeyes to workspace 3, the state keeps being reported as 'S' by ps. It never changes to 'T', even 15 seconds after switching to workspace 1.

...

Wait, are you ever making workspace 3 current in this, or just moving with mod-shift-3? Layouts don't (and can't) react to the latter; the layout can only stop and start processes when you switch to or away from a workspace.

Makes no difference either way. Does it work for you?

Haven't tried because I don't have a sandbox setup on this machine (to run a separate xmonad setup from my main one in xephyr). I just realized xeyes was a bad choice; Stoppable relies on _NET_WM_PID, and... pyanfar «.xmonad*pyanfar» Z$ xeyes & sleep 3; xprop -name xeyes _NET_WM_PID; kill $! [1] 14711 _NET_WM_PID: not found. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Tue, Jun 14, 2016 at 6:23 PM, Brandon Allbery wrote:

On Tue, Jun 14, 2016 at 6:19 PM, Brandon Allbery wrote:

...

I just realized xeyes was a bad choice; Stoppable relies on _NET_WM_PID, and...

If you test this with a terminal, use one that doesn't use factory backends (like xterm or urxvt --- NOT urxvtc!) or suppress the backend factory; otherwise you get the pid of the factory and will be very unhappy when it suspends every terminal instance because they're all owned by the factory.

I should also mention that I pointed out these and other shortcomings of the information any implementation could rely on for this --- which isn't much --- to the author back when they were writing it. You seem to be hitting all the pain spots where it can't work sensibly. (Very recent xorg has a call that could make the xeyes case work, but would not help with the other cases I mentioned. It would also open an interesting potential issue with remote windows via ssh X11 forwarding, where it could suspend the ssh as the apparent owner of the window and cause the remote to time out and drop the connection.) X11 *really* does not want this kind of thing to work. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Adam writes:

Brandon writes:

...

X11 *really* does not want this kind of thing to work.

Maybe the documentation of the module could be amended with a paragraph outlining this.

Putting my keyboard where my mouth is, as a start: · https://github.com/asjo/xmonad-contrib/commit/b2ecbe7471a5d519fc03288614c6df...

(I definitely would not have wasted (your) time trying to get it to run, if it had.)

I don't, however, understand why it doesn't work on Firefox. kill -STOP manually _does_ work on Firefox. And Firefox sets _NET_WM_PID. Best regards, Adam -- "I say, either agree with me or take a hike! I'm Adam Sjøgren right, period! End of discussion!" asjo@koldfront.dk

Paul writes:

I can add another datapoint here: it works with Firefox on my machine, but the exact config and firefox version will be available only later today, when I get back home.

Cool, that would be fun to see. (I'm on 45.2.0) Best regards, Adam -- "You make a hit by putting two flops together" Adam Sjøgren asjo@koldfront.dk

On Mon, Jun 20, 2016 at 10:47:55AM +0300, Paul Fertser wrote:

I've seen a report that 47 doesn't work but I haven't tried it myself

Now I can confirm that Firefox 47.0 can be stopped as well. The report I was talking about was due to running it in firejail. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com

On Tue, Jun 14, 2016 at 4:24 PM, Adam Sjøgren wrote:

Putting my keyboard where my mouth is, as a start: · https://github.com/asjo/xmonad-contrib/commit/b2ecbe7471a5d519fc03288614c6df...

If you can turn this change into a clean, one-commit pull request against xmonad/xmonad-contrib, I'll happily merge it. Or I'll be happy to make the change myself if you don't care about attribution in the git log. ~d