xnee-devel
[Top][All Lists]
Advanced

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

[Xnee-devel] possible use for debugging


From: hollunder
Subject: [Xnee-devel] possible use for debugging
Date: Thu, 2 Apr 2009 13:43:51 +0200

Hi,
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.

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.
A third idea is to embed the events in the video or use some kind of
subtitle format to show them.

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.
Example:
[ 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.

Thanks for reading,
I hope you can see the use and have some ideas how this could be
implemented.

Best regards,
Philipp




reply via email to

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