[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xnee-devel] [Fwd: Re: AW: [sr #103871] Verifying GUI-Testresults with x

From: Henrik Sandklef
Subject: [Xnee-devel] [Fwd: Re: AW: [sr #103871] Verifying GUI-Testresults with xnee using the Tool "xgrabsc"]
Date: Sat, 21 Jan 2006 10:37:00 +0100

--- Begin Message --- Subject: Re: AW: [sr #103871] Verifying GUI-Testresults with xnee using the Tool "xgrabsc" Date: Thu, 19 Jan 2006 14:43:49 +0200 Henrik, of course You can forward my previous emails to Xnee's devel mailing list.
You can even edit (cut-copy-paste) them if you like.

Here little is more about this subject:


when using xwd with option "-xy", captured file size seems to be almost
the same size compared to the file which imagemagic import did:

  $time xwd -xy -id 0x3c00057|tee /mnt/rd/made_by_xwd_xy.xwd | md5sum
  aec42721bb28ed2ee90c527496081921  -

  real    0m6.288s
  user    0m0.016s
  sys     0m0.029s

  $ls -la made_by*
  -rw-r--r--  1 ryhanvei pam 2534369 Jan 18 16:51 made_by_import.xwd
  -rw-r--r--  1 ryhanvei pam 3380144 Jan 18 16:51 made_by_xwd.xwd
  -rw-r--r--  1 ryhanvei pam 2578520 Jan 19 13:13 made_by_xwd_xy.xwd

Dirk wrote:

> ( sorry for my small english. i don't often use this language for
> speaking ore writing but most for reading.)

I can say the same words, too! Nice to see that I am not the only one! :-)

> If your are saving the screenshots, so you can verify a defect of your
> grafical interface by comparing the reference-screenshot against
> the actual taken screenshot while replaying the session.
> So you can see the differences between the pictures and verify, what
> your grafical interface has done.

I did both with the above command, because /mnt/rd is not a real disk, it
is a 16MB ramdisk which I did very quickly by following these instructions:
Only problem with ramdisk is that when creating it first time you must
have root privileges (but you must have root privileges anyway when
installing xnee library to standard location).

If test fails, file on the ramdisk should be copied to real disk and
rename it according to test name and/or number. Otherwise, next test
captured picture will overwrite the picture on the ramdisk.

There are already these interesting options available in cnee:

      --exec-key mod,key, -ek
              When pressing modifier mod and key key Xnee inserts a exec mark into the  session

      --exec-program s, -ep
              Program to start when replaying

How about this: When pressing exec-key (or pause-key or mark key, I don't know
which should be the best/right choice) then cnee will launch a program which
is defined by option "--launch-program", for example:


Above script should be in directory, wich is included in PATH -variable.
First row inside myScreenCaptureAndChecksum.sh should be a special comment:

#!/bin/bash    (or some other script command language interpreter)

...and after that your preferred screen capture command, which will use string (which
can be found on your program window title bar) to identify windows which should be captured:

$TITLE="DbVisualizer Free 4.0.4 - /home/ryhanvei/.dbvis.xml"
CHECKSUM=`xwd -name $TITLE | tee /mnt/rd/made_by_xwd_xy.xwd | md5sum`
CORNERS=`xwininfo -metric -name $TITLE|grep Corners`

...and then some code which check $CHECKSUM against checksum which was
saved when xnee script was recorded. If checksum fails, then maybe .xwd
file should be read in from ramdisk by some converting program (for example
imagemagic convert utility) and write out to real disk in compressed format.

If using external, fully independent "binary shell program" to define
used screen capture program name, then there is much more flexibility
compared to situation where screen capture program is built (or nested)
inside cnee.

Veijo Ryhänen, Finland

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]