Re: [Bug-xnee] xnee -rep leaves Control -modifier to pressed state after exiting xnee.

[Henrik Sandklef]

On Fri, 2006-01-13 at 11:49 +0200, Veijo Ryhänen wrote:

> 
>         2) Xnee does it
>         ------------------
>         This may sound easy. It is not. Cnee has to check how it hawas
>         started 
>         from a terminal and after that check what key combination
>         sends the
>         signal..... This is not something I think is something that
>         Xnee should
>         check.
>         
>         Another thing would be to hold the writing of pressing of
>         modifiers a 
>         bit to see if anything strange is happening (e.g Control C).
>         BUT, what
>         happens when user presses Alt + Button 1 + moves the mouse.
>         This moves
>         the window underneath the mouse. Then during replay we do want
>         the press 
>         of Alt to have been recorded, since otherwise the window isn't
>         moved as
>         when recording. So this is not a solution :(
> 
> I did not understand this part well. How about this solution:  cnee
> and
> gnee sends all recorded data to xneed, which is logging daemon. If
> there is
> no data available, then cnee or gnee sends "I am still alive" -message
> to
> the xneed -logging daemon. If xneed does not get any message after
> timeout
> xneed thinks: "cnee or gnee must be dead, propably user has pressed
> Ctrl+c

How do you know that?
The use may actually want to record "two hours of silence" (allthough a
stupid thing to do, I have to say).  This would be solved by an
adjustable timeout value, but then I figure that using the "--stop-key
F1" is much easier.

> si I must comment out the last Ctrl -press and close this log file".
> Ctrl+c does not terminate xneed, because it is daemon.


Hmm, I think this adds too much complexity to Xnee. One solution that (I
think) is easier is to add some code to the signal handler of Xnee to
make sure that the press of Control (or whatever modifier+key causes the
signal to be sent).


> 
>         3) use a stop key
>         ------------------
>         Invoke cnee with the stop key, like this: 
>            cnee -rec --verbose --keyboard -o a_and_ctrl_c.xnl -sk F1
>         
>         Then Xnee will stop recording when F1 is pressed. And F1 press
>         or
>         release will not be recorded*.
> 
> It does not work. These stop keys does not work either:
> -sk Alt,F1  
> -sk Ctrl,F1
> -sk Alt,n
> -sk Ctrl,n
> -sk n
> -sk Alt,s
> -sk Ctrl,s
> -sk s

You have stumbled on a (now fixed) bug in the help printout of cnee. Now
you can only use key to stop Xnee (and not modifer+key). So, "-sk n" and
"-sk s" should work. Can you send over the error printout and the
recorded sessions file, when using for example "-sk s".

I use --stop-key s when recording. No problems for me so far.

For a real example look at:

http://cvs.savannah.gnu.org/viewcvs/xnee/cnee/test/scripts/grab/p_r_s.sh?rev=1.1&root=xnee&view=markup


This is used to do regression test of Xnee. You probably can't execute
this script, since you have to have the swinput module inserted to Linux
(btw, Linux is a kernel not an OS). But you can see how to use grabbing
of keys to stop/pause/resume Xnee.

> I haven't enough time to try every combination, so I prefer Ctrl+c, it
> seems to work allways 
> perfectly with my script which comment out last Ctrl button press.

But then Ctrl+c isn't grabbed by Xnee but by the terminal (allthough the
word for it isn't grab).

> 
>         > So, it seems to be true that xnee leaves the modifier
>         Control to
>         > pressed state 
>         > after replay. I fixed this by pressing "Ctrl+c" in my
>         konsole and
>         > after that my
>         
>         Control alone would be OK to leave the state.
> 
> It does not work. When first pressing c  nothing happens. Second,
> third
> etc... 'c' press will do an empty new line without printing out 'c'
> character..

I am not sure I follow. Was it like this:

1) Xnee replays Ctrl press
2) Control press (by you)
2) Control release (by you)
3) c press/release (by you)
4) c press/release (by you)
5) c press/release (by you)


or do you mean 

1) Xnee replays Ctrl press
2) c press/release (by you)
3) c press/release (by you)
4) c press/release (by you)


>         
>         Don't know. The corrupt line is something the "xnee replayer"
>         says when 
>         it finds something strange in the recorded file, please send
>         over the
>         recorded file alone in an attachement.
> 
> There is no "Corrupt line" output when using cnee, so this is already
> fixed. 

Good to hear that :)

Thanks for your input.


/hesa