[Top][All Lists]

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

Re: [Xnee-devel] possible use for debugging

From: Henrik Sandklef
Subject: Re: [Xnee-devel] possible use for debugging
Date: Thu, 02 Apr 2009 20:23:58 +0200
User-agent: Thunderbird (X11/20090105)


wow, thanks for your lenghty input :)

address@hidden wrote:
I'm doing a lot of bug hunting for mostly audio applications.
Some have a user interface that makes it difficult to reproduce the
steps taken to make a bug happen (example: http://traverso-daw.org/).

One way thing that can help are screen recording applications, like
recordmydesktop, but they are only a partial solution since keypresses
are missing, so I thought: wouldn't it be cool if I could somehow
capture all X input events in sync with the video.

The idea is that I as a user/tester have Xnee and some screen
capture application running when I test the application.
If I find strange/hard to reproduce bugs I make both the video
and the captured Xinput available to the developer.
The developer then watches the video to see the strange behaviour and
can look up the Xinput events at exactly that moment which allows him
to reproduce the bug.

Do you think that the following (much easier to get right) will do:

1. Record application and use some key bindings to exec programs/script every time you press the bound key. The script/program to launch could be a screen snapshot program (i've done a few tests and it works nice).

2. Replay the session. Xnee will now exec the same programs/scripts 'same time' as when recording.

3. compare the 'recorded' snapshots with the 'replayed' snapshots

Also check out:

Another possibility is that the tester just tells the developer the
events that led to the problem, either way, important is that the bug
or behaviour that is seen in the video can easily be associated with
the input events.

How the information is presented isn't too important I believe, it
could just be a matching timecode in both the video and the Xnee
output that one looks up manually.
Another idea is synchronous playback of the video and the events shown
in a terminal window.

Could this be a bit problematic ... what if the bug may (i am saying MAY) have something to do with the video. I don't think so though ... just want to see the problems in order to get rid of possible such.

A third idea is to embed the events in the video or use some kind of
subtitle format to show them.

hmmm ... interesting

what kind of events do you have in mind. Only the keyboardy and mousy ones.

This kind of debugging help would be most useful for applications with
complex input methods, like above mentioned traverso.
This application uses a combination of mouse and keyboard where the
action depends on the position of the mousepointer and the keys
pressed. In addition it matters how the key is pressed.
[ G ] means holding the G key, if one does that on an audio
clip and moves the pointer up or down one changes the volume of the
audio clip.
<< G >> means pressing G twice in fast succession, it resets the gain
for this clip.
< > consequently means a single key press.

This method allows a very fast workflow once you have memorised the
keys you need and it is despite it's complexity quite intuitive, but I
guess you can imagine that it's really hard to debug if things go
wrong. This is what spawned the idea of video in combination with
Xinput events.

wow, will have to think about it

Thanks for reading,

i did read it ;)

I hope you can see the use and have some ideas how this could be

sure can

Best regards,

Xnee-devel mailing list

reply via email to

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