How to take a screenshot of a window that is not visible in batch mode?
 

What have I tried so far:

- import from imagemagick reports an error for both window id and window name

- scrot doesn't accept a window id as argument

- maim and xwd don't take the screenshot if the window is not visible (it's on
another workspace, not the active one, i'm using vanilla dwm)

Note: I take window id and name from the output of wmctrl -l

Maybe make window sticky, then unstick it with wmctrl?
Not tested (wmctrl not installed here)

I can get this to work with my dual monitor setup with separate screens on Monitor0 and Monitor1.
From a terminal on Monitor1, I can capture an image from a window displayed on Monitor0 with
As 'man import' states:
If you have only one screen, then the window to be captured and the terminal where the command is issued will both need to be visible on the screen, otherwise the errors reported will occur.

What are the implications of this and what exactly is a sticky window? I don't want this to interfere into my workflow that happens in other windows (which are in other workspaces).

Bummer. Definitely missed it when reading the manpage.

I do have just one screen indeed. But import from imagemagick is not a mandatory requirement. I'd be happy to use any other CLI tool that will allow me to take screens of windows that are not visible.

You can't take a screenshot of a window that does not exist.
If the window is not visible then there is no window. Maybe you should explain further what you are wanting. To capture the output form a running program/process? Screenshot is just that, a picture of something that is on the screen. Maybe you are wanting something else.

I'm trying to figure out what you are doing. A shot of a minimized window? Or do you have a dual monitor setup with one monitor unplugged? Why isn't the window visible? Or a window that is behind another window? What?

A sticky window is a window visible on all workspaces

If you are wanting to capture a window on another work space, then give yourself a pause so you can make it active.
https://askubuntu.com/questions/2117...ces-or-windows
https://askubuntu.com/questions/3030...nactive-window
https://unix.stackexchange.com/quest...tive-workspace

I want to take a screenshot of a window that is identified by an id, but is not visible on screen - it's on another workspace (dwm calls these workspaces tags and I switch between them using Alt+1, Alt+2 and so on).

That's what I'm trying to avoid: I don't want the window I'm trying to take a screenshot of to appear on the active workspace.

That would defeat the point of what I'm trying to achieve. I can just stick to the workspace where the window in question is, but then
I can't do anything else, because I need to take lots of screens for hours. That's why I want to run that window in the background (another workspace) and I need a way to take screenshots of it.

My manpage for scrot has a -d option, but no -u uption. I'm using scrot-0.8

The idea was to make the window appear just the time to do the screenshot and then put it back in workspace where it belongs...

The idea is not good, because dwm is a tiling wm, and the window might change size/position while appearing on another workspace.

Technically changing window state to sticky does not move it. On the contrary, it's a flag that tells to window manager to let the window stay in place (stick on screen) while other element can move (viewports...)

Maybe dwm doesn't support this feature though (I never used it)

This is the command that I use to take window snapshots.
If that is run in a terminal in one work space then you can use keyboard shortcuts to get to another workspace before clicking the mouse to select the window for the snapshot.

I actually usually use it from a script behind a right click menu entry.

PS - The conversion of the window id from hex to decimal does not appear to be necessary for 'import' any more.

Sorry - The last post is a manual technique, but the OP appears to want an unattended scriptable solution.

Yes, exactly. I don't want to perform any mouse clicks on a window to take the screenshot of it, I just want to pass its id to a screenshot taking tool. Again, it should happen in another workspace, not the active one, fully in background. And it should not interfere with the currently active workspace or any windows from it.

The problem is that when window is in another workspace, it's not displayed so its pixels are not in current display memory. At this point no screenshot can be made until you switch to the workspace when window resides and the pixel are drawn to the screen

I can understand this. But since the window is still alive, its content must be somewhere in memory, no?

Data content yes but to get a graphical view you have to draw lines, colors, points etc on screen
I mean screenshot programs don't draw from evaluated data, they copy screen pixels in a file

Screen capture programs assume that they need to access the active buffer.
So in my dual monitor setup I can access the active buffer on the alternate display.
With a single screen, the only method that I can conceive that could create an alternative active buffer would be to use Xnest to create a second Xserver.
I have played with Xnest, but cannot offer any advice for this use case.

Another idea would be to put the window temporarly in the same workspace but under a background image which would give the illusion of a non visible window

Just got this to work on my little netbook.
I started a nested session running Windowmaker with
and then I could capture a screenshot from that session from a terminal in another workspace with

Very interesting, could you please test if it works the opposite way? I mean, run the screenshot software in Xephyr and see if you can capture a screen from main session. I will definitely test this too soon, but I'm concerned since I've read that running apps like OpenGL ones in Xnest/Xephyr may have performance penalties. So perhaps it's possible to run the screenshot software in another session, not the app that generates window that needs to be screenshotted.

From my quick testing, it does not work the opposite way unless the window to be captured is in the same workspace.
I can do
from a terminal in a separate workspace on the primary display to capture a window in the Xephyr session
but
from a terminal in the Xephyr session only works if the window to be captured from the primary display is in the same workspace as the Xephyr session.
The attached screenshot may clarify.

@FlinchX, just curious did you try the commands in post #2 ?

It's my highest priority pet project for this weekend, hopefully I will provide feedback until the weekend is over, on your suggestion and the one about using Xephyr. Sometimes it takes a few days, but I value the help I get in this forum and I always try to provide feedback to people who spend their time trying to help me. You can see it from my post history.

No problem, I was wondering if it could work (not having the possibility to test it myself)

second step throws an error, just like when I ran it before, without making the window sticky:

Ok, it's seems dwm doesn't support sticky feature. I was worth a try though

And what about (say window is on workspace 2 and you work on workspace 1
You may want to use wmctrl -d to verify workspaces numbers

IIRC there used to be a patch for dwm that adds this feature, but I'm using vanilla dwm. I'm afraid patching dwm to get support for this feature goes out of the scope of my goal. For now at least.

I tried this, but with glxgears, it did not start:

What about open window in same workspace but put it out of screen view?

this doesn't seem to work at all with dwm, the window remains visible

Where you have used '/usr/bin/glxgears', change to the command to start a window manager. I do not use dwm, so I do not have that command.
Here:
'/usr/bin/wmaker' starts WindowMaker
'/usr/bin/startxfce4 starts XFCE
'usr/bin/startfluxbox' starts fluxbox
'/usr/bin/startfvwm2' starts FVWM.
From within the Xephyr session, glxgears works for me.

Running dwm inside the Xephyr session is not essential for me indeed. Since I need the wm just for running the command (glxgears) in this case.

After this command

fluxbox starts inside the Xephyr session. I right click to bring up the popup menu. Select rxvt to launch a terminal. Run glxgears from it. The error is exactly like above, when I start glxgears directly.

Are you being deliberately perverse?

If you want to break things then use rxvt (recently removed from Slackware-current). If you want to use the common denominator then use 'xterm'.
If you do not want to configure fluxbox, then start your preferred dwm.

This is now your problem. You have been offered two viable solutions that will work with a modicum of effort on your part.

Your posting history be damned!