Re: [Xnee-devel] possible use for debugging

[hollunder]

On Thu, 02 Apr 2009 20:23:58 +0200
Henrik Sandklef <address@hidden> wrote:

> Hi
> 
> wow, thanks for your lenghty input :)

Hi Henrik, sorry for the long delay, it's sometimes hard to get my ass
up..

> 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

This could work in some applications but totally leaves out the audio
aspect (which is relevant to me because I mostly test audio apps).

> Also check out:
>    http://www.andreasn.se/blog/?p=96

For what I have in mind no better than a normal screen capture.

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

There can always be some bug related to some part of the application,
don't think it's really different with video.

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

I don't really know which ones there are, but basically what's relevant
is the user input.

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

No idea why I adjourned that for so long, sorry again.

Best regards,
Philipp