By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 966 - ksnapshot fails to bring window to front before snapshot with 'window under cursor' selected
Summary: ksnapshot fails to bring window to front before snapshot with 'window under c...
Status: NEW
Alias: None
Product: TDE
Classification: Unclassified
Component: tdegraphics (show other bugs)
Version: R14.0.x [Trinity]
Hardware: All Linux
: P5 normal
Assignee: Timothy Pearson
URL:
Depends on:
Blocks: 2968
  Show dependency tree / graph
 
Reported: 2012-04-18 11:38 CDT by David C. Rankin
Modified: 2018-08-30 02:52 CDT (History)
1 user (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
ksnapshot grabbing part of incorrect window - example 1 (21.20 KB, image/jpeg)
2012-04-18 11:38 CDT, David C. Rankin 		Details
ksnapshot grabbing part of incorrect window - example 2 (79.45 KB, image/jpeg)
2012-04-18 11:39 CDT, David C. Rankin 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David C. Rankin 2012-04-18 11:38:32 CDT 
Created attachment 546 [details]
ksnapshot grabbing part of incorrect window - example 1

When using ksnapshot to take a screenshot of 'window under cursor', ksnapshot does not bring the window to the front before capturing the image resulting in the capture of the contents of any windows are 'on top' of the desired window within the geometry of the desired window. This is incorrect behavior and after 5 years of kde3.4-5 and tde 3.5.12, 13 & R14 -- this is the first time I have seen this behavior. ksnapshot should bring the desired window to the front before capturing the screenshot to prevent capture of extraneous information.

tdegraphics was built on gcc47 and the focus model set for the desktop is focus follows mouse. I don't know if either of those make any difference.

screenshots will be attached.
Comment 1 David C. Rankin 2012-04-18 11:39:03 CDT 
Created attachment 547 [details]
ksnapshot grabbing part of incorrect window - example 2
Comment 2 David C. Rankin 2012-04-18 11:58:10 CDT 
Also note in example 2, the right side of the window is not captured correctly. However, if the target window is already the top window, the screenshot is captured fine. So the incorrect capture of 1/2 the scrollbar on the right is caused by this bug as well.
Comment 3 Darrell 2012-04-22 15:36:53 CDT 
Could be Yet Another gcc 4.7 anomaly. :)

I tested this under my current GIT build, gcc 4.4.4. I fiddled a bit and noticed when the two timeouts are too close to one another then I could replicate the behavior you described.

For example, 0.75 seconds for focus and 1 second for ksnapshot. A 0.25 second difference is defeated by the pace at which I moved the mouse pointer to the window I wanted to capture. When I slowly moved the mouse pointer then I replicated the behavior. The two timeouts clashed and the window manager was in the process of raising the desired window, which sent the wrong momentary image to ksnapshot.

When I moved the mouse pointer as fast as possible over the desired windows then the window popped forward before the ksnapshot timeout expired.

When I adjusted the ksnapshot timeout to more than one full second longer than the focus timeout, which provided me sufficient time to move the pointer and allow for the focus timeout to take effect, then the behavior stopped. For example, 0.75 seconds for focus and 2 seconds for ksnapshot.

Would you test this again with an ample difference between the two timeouts?