-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 3.1.12 regresses maim's screenshotting ability? #18
Comments
Unfortunately I'm doing everything I can to make slop get rid of its window before shutting down, but it's always at the mercy of X11 actually deciding to get rid of it. Here is slop's shutdown procedure:
I honestly don't know what else I can do to keep it from showing up in screenshots. It doesn't ever show up in mine, but I'm sure it depends on your window manager and compositor. If you want to help debug, you can change some of those lines I gave as links, you could perhaps increase the time it waits, or maybe add in an XSync() command in there somewhere. (But XSync() didn't seem to change its behavior whatsoever.) You could also try moving the window offscreen, or using XShapeCombineRectangles() to turn it into a 0x0 sized window. (I'm pretty sure both of these are still at the mercy of X11, I've tried the XShape trick before. It works great, but it causes some window managers to bug out when you actually make the window 0x0. You could possibly try sizing it to 1x1 and moving it offscreen?) As for the blotches of color/corruption: I have no idea what would cause that. I use Imlib2 to do all the image taking dirty work. Does it stay corrupted with --mask=off --hidecursor? |
@naelstrof: Don't worry about the blotches of color (the purply stuff). That's just due to an effect that takes place when certain windows are torn down. I'll see if this can be avoided by doing first that, then adding slop to the list of things to exclude from that effect, and both just to make sure. |
In a commit in the past, I would use XShape to make the window non-existant before shutting down. It actually worked great, and would probably keep any effects from being applied to it regardless: But it caused some window managers to bug out, thus it was patched out with cc21c2d Surely if you sized it to a 1x1 rectangle that's slightly offscreen ( x=-1 y=-1 w=1 h=1) it might work great for everyone. Could you test that for me? |
Haha. There's got to be a way to make slop convey to Compiz that there shouldn't ever be effects applied to it without configuration. I have a feeling that Compiz is making a mistake when applying effects to windows that specify CWOverrideRedirect. As that's supposed to keep the window manager from doing anything with the window. Perhaps you should go make a bug report to Compiz about it. |
These two pictures are taken with slop 3.1.12 and maim 2.3.31
test, taken with highlight
test2, taken with outline
And these two with slop 3.1.10 and maim 2.3.31
test3, taken with highlight
test4, taken with outline
And these two with slop 3.1.12 and maim 2.3.34
test5, taken with highlight
test6, taken with outline
And these two with slop 3.1.10 and maim 2.3.34
test7, taken with highlight
test8, taken with outline
I'm not sure if anyone else noticed this (I'm running Compiz 0.8.x here, is this noticeable with other window managers?), but it looks like that slop isn't tearing down its window properly.
Also of note is the fact that slop's highlight rectangle mode still shows up in these screenshots (as indicated by the dim color).
The text was updated successfully, but these errors were encountered: