Re: [Xnee-devel] possible use for debugging

[Henrik Sandklef]

Hi

wow, thanks for your lenghty input :)

address@hidden wrote:
> 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.


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:
  http://www.andreasn.se/blog/?p=96

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

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
> implemented.


sure can


> Best regards,
> Philipp
>
>
> _______________________________________________
> Xnee-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/xnee-devel