
Pause/unpause any X11 application - vermaden
https://vermaden.wordpress.com/2018/09/19/freebsd-desktop-part-16-configuration-pause-any-application/
======
owaislone
Very cool. I tried it on KDE Neon (ubuntu 18.04) and it worked perfectly.
Didn't even leave any artifacts. However, all input events were queued up by
KWin and as the application handled them as soon as I resumed it.

Would be seriously cool if KWin natively supported this so apps would truly
freeze. Would fit in perfectly with Plasma's Activity system.

~~~
geokon
You can suspend a whole Plasma activity already. Isn't that more useful?

~~~
owaislone
Really? I've never noticed it. Apps running in another plasma activity always
show up as running instead of stopped and continue to consume resources. I
only tested by switching between activities.

~~~
geokon
They don't suspend by default. I don't use KDE any longer so maybe it's
changed, but you just needed to right click on the activity in the activity
panel and there should be a menu item to suspend the whole activity. It's
really a non-obvious feature.. :)

It's very handy and it's the main thing I miss from KDE b/c you can have more
stuff "running" on a wimpy computer. I'd usually have a whole activity for
some project I only touch once a week and it'd just sits suspended in the
background till I needed it again

------
oever
It would be wonderful to have a pause button on the titlebar of applications.

~~~
imglorp
Great idea. Probably needs to be WM dependent. I started looking at the Gnome
path and realized adding a window title bar menu item is probably easier,
because they seem pretty locked into the Big Three buttons, and you'd get into
layout and icon issues.

------
hultner
This is actually very neat, I haven't though about pausing desktop
applications to save battery/CPU before. Tried it out real quick with Safari
on my work laptop (macOS), worked like a charm with

    
    
       killall -STOP "Safari"
    

Safari is paused/suspended

    
    
       killall -CONT "Safari"
    

Responding again.

Shouldn't be to hard to hook it up to a keyboard shortcut which grabs the
active window and sends stop/continue signals to that window.

~~~
vermaden
The `xdotool` is available in the [https://brew.sh](https://brew.sh) so you
can just use the provided `desktop-pause.sh` script with a shortcut which does
exactly that - "grabs the active window and sends stop/continue signals to
that window".

~~~
hultner
Does this work for Aqua applications as well?

I'm thinking we'd like to use something like Hammerspoon or AppleScript to
fetch the PID of the currently focused window.

[https://www.hammerspoon.org](https://www.hammerspoon.org)

------
auscompgeek
Heh, nice. I also wrote a simple script a long while ago, after someone wrote
Universal Pause Button for Windows.
[https://gist.github.com/auscompgeek/5da8f27e50feb185d1e2](https://gist.github.com/auscompgeek/5da8f27e50feb185d1e2)

There are a couple of functional differences I can see:

\- I directly read /proc to grab the current process status, which probably
isn't very portable...

\- vermaden's will also stop the children of the process.

Unfortunately I don't really use this any more, since I use Wayland these
days.

------
pjc50
Handy, although that's not how I was expecting it to work - SIGSTOP is all
well and good, but what if your window is coming from a remote system? Or does
nobody use ssh X forwarding any more?

What I was expecting was a means of suspending the X event loop, so the
application remains "running" but idle.

~~~
mcny
There's a machine I should into but I don't know if I can x inner ssh because
it isn't publicly available.

I ssh into another machine and then ssh from there to that machine. I don't
even know how to search this question. The machine in the middle doesn't have
a display. X over ssh is difficult.

~~~
pjc50
It _can_ work if X forwarding is enabled on both hops. However, X11 forwarding
may be disabled in the sshd_config on the remote system.

It doesn't require a physical display. If it's working then it should set the
$DISPLAY environment variable inside the ssh session.

~~~
dfox
Another thing that is required for X11 forwarding is installed xauth on the
server side (that means even the middle host(s)), nothing else X11 related is
required.

------
pbhjpbhj
>Can you imagine opening xterm(1) terminal and searching for all Chromium or
Firefox processes and then freezing them one by one every time you need it? Me
neither.

I can, "pkill -STOP firefox"?

pkill takes regex too.

Y'all have heard of ctrl+z too I hope.

~~~
vermaden
You are right about pkill.

About CTRL-Z and other of these I once wrote about them :)

[https://vermaden.wordpress.com/2018/07/08/ghost-in-the-
shell...](https://vermaden.wordpress.com/2018/07/08/ghost-in-the-shell-
part-2/)

~~~
pbhjpbhj
Your style is really easy to read, but I thought you meant there was something
wrong with ctrl+z : thought I was going to get schooled!

Nice blog posts, well done.

------
BagOfPistchios
The only times I have ever wanted to freeze an application it was for the
purpose of it not hogging CPU time in favor of some interactive program, and
had no better way of doing that. On Linux, the Con Kolivas MuQSS CPU scheduler
introduces a new scheduling policy called SCHED_IDLEPRIO which runs a program
only if there is absolutely nothing else to run. It is perfect for long-
running programs that don't need interactive performance.

EDIT: The example given in this article is also IMO better solved by using
SCHED_IDLEPRIO >Other example may be some heavy processing. For example you
started RawTherapee or Darktable processing of large amount of photos and you
are not able to smoothly watch a video. Just pause it, watch the video and
unpause it again to finish its work.

------
blueyed
This is really useful, especially for browsers.

I've created a WIP recipe for awesomeWM a while ago, which supports stopping
special clients (browsers, thunderbird, slack) after a given timeout of being
unfocused, and also when minimizing them.

[https://github.com/awesomeWM/awesome-
www/pull/111/files](https://github.com/awesomeWM/awesome-www/pull/111/files)

------
grapeli23
The cgroup freezer is much better (reliable).

[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/cgroup-v1/freezer-
subsystem.txt)

~~~
vermaden
In what way its more reliable?

It works only on Linux.

Mine approach works on Linux/FreeBSD/OpenBSD/Illumos/Solaris/UNIX/...

~~~
stubborn_d0nkey
More reliable not more available. It's because programs in userspace can mess
with the signal usage, while they can't with the cgroup feezing.

------
saagarjha
It’s interesting to see that stopping a process causes visual artifacts when a
window on top of it is moved. This is really odd, since it seems like
applications should be able to affect each other in that way; that is, this
not isolated so that a frozen window shows a snapshot of how it looked when it
was sent the signal and nothing else?

~~~
rhn_mk1
That depends on the window manager. The application state is not really
affected, it just stops updating (redrawing its area). When another window
moves away, the window manager asks the "underlying" application to update
that area of the screen. It's dead, so the WM keeps displaying the last thing
that was there, until something else happens in that spot.

On the other hand, compositing window managers will dedicate a separate buffer
to each application, where they have exclusive access. That kind of a window
manager would not have to ask the application to update anything - it would
just take the image from _the dedicated application 's buffer_ and update the
screen with it. Since the application's buffer can't be modified by anything
else, it would have the last state of the application in it. That would in
turn find its way to the screen. No glitches.

~~~
oh5nxo
It also partially depends on how the client program has configured her
windows, and how the X server handles related stuff.

------
fabiospampinato
This is great! I've just added support for this to my Phoenix [1] setup.

[1]
[https://github.com/fabiospampinato/phoenix](https://github.com/fabiospampinato/phoenix)

------
Uplink
I'm nitpicking, but is there a reason why you use the numeric signal number in
Linux? On my machine "kill -SIGSTOP" works as expected, and I don't remember a
time when you couldn't use signal names like that.

~~~
jwilk
Neither "kill -SIGSTOP" nor "kill -17" is portable. (In fact 17 is SIGCHLD on
x86 Linux…)

You should use "kill -STOP".

~~~
vermaden
Fixed, thank you for pointing that.

~~~
jwilk
The blog post still uses "kill -17" and "kill -19".

------
emilfihlman
This is seriously cool idea.

But could you not get the same effect with nice?

~~~
c0l0
No, you cannot. A given task, running at maximum "niceness" (i.e., the lowest
"priority" in regard to its peers) will happily consume 100% CPU if it has
enough work to do - at least in total absence of other consumers of that
resource.

SIGSTOP effectively tells the scheduler to just not allocate any CPU time to
the task any more, which makes the task unable to perform any work (and also
not consume any additional resources, of course).

~~~
comboy
Awesome, for those of you wondering just like me - it's SIGCONT.

------
vermaden
One thing about the title, its not `xdotool` that does the pause/unpause, the
`xdotool` is used only to get PID of active application with -a option.

Same with -s option where you will select the target window with `xprop`
command.

The pause/unpause is done by the `kill` command of course.

This title was not set by me.

~~~
pbhjpbhj
Apropos of nothing, you can use xdotool for rudimentary gui macros like very
simple game bots and such.

Your post made me think perhaps xkill had an option to send other signals than
abort, but it doesn't appear to without modification.

~~~
jolmg
I believe xkill doesn't send any signals at all. Rather it tells the x-server
to destroy a window and close its connection with the program that opened the
window. If programs die, it's only because they weren't expecting their
connection to suddenly be closed, as most wouldn't.

