Re: [Xnee-devel] Xnee and relative mouse positions

[Henrik Sandklef]

Mads Lindstrøm wrote:
>> That's strange. Is the window created during recording/replying or does
>> it exist before?
> It is created after starting cnee.

Hmmm....... Xnee is now trying to move the window 3 times before it
stops trying. Locally on my computer Xnee tries 10 times. Will try to
release asap. Hopefully that solves it.

What application are you recording. I want to be able to test the recall
window position thing with the same app.

What do I mean with trying to move?
I cannot force the window to put the window at (x,y) since the WM wants
his saying. So what Xnee does is trying to move it... depending on how
it failed to move the window Xnee retries with a new position (x,y) to
fool the WM ;)

>> I think there's another problem with your proposal (correct if I am
>> wrong!!!). Let's say we have two windows there were created during
>> recording, A and B. Window A was created first and B second. So when we
>> replay Window B is created first since something strange happened that
>> slowed down A. Now, we'll end up with A's events being replayed to B and
>> vice versa.
> 
> If you are synchronizing with CreateNotify I do not really think you
> would have a problem.

Will think about it some more :)
.. and of course test ;)

> You might argue that sometimes A will have focus
> and sometimes B will have focus. You might be able to ask X to give
> either A or B focus, depending on who had focus when recording. However,
> I do not think it is necessary. If a program opens two windows, it
> should and usually does, make the same one have focus each time.

But there's no way we can predict that window A is created before window
B when replaying. If window B is created first (when replaying) window A
will get focus (since being the last created window). So window B has
focus while during recording window A had focus.

> Do you have any suggestions as to how we track down the problem?

If you provide me with the name of the application you want to test I
may be able to help you by testing here locally.

> Some information which might help you: I am using the stable version of
> Debian Linux. I am using using these to scripts to run record/replay
> (note that grep in the scripts are a GUI app. - not the usual grep):




> Grep.record:
>       #!/bin/bash
>       
>       cnee --recall-window-position --record  -o grep.xnr 
> --device-event-range KeyPress-MotionNotify,CreateNotify --time 1 --stop-key 
> F3 &

CreateNotify is a delivered event so, try this instead:
 --device-event-range KeyPress-MotionNotify
 --delivered-event-range CreateNotify

I think an option such as "--event-range" should be added to solve the
confusion between device events and delivered events. Have had it in
mind for a while. So in the next(?) release it should be possible to do:

  --event-range KeyPress-MotionNotify,CreateNotify

which is a lot easier to get.

>       sleep 3
>       ../Examples/Grep
>       xset r on
> 
> Grep.play:
>       #!/bin/bash
>       
>       ../Examples/Grep &
>       cnee --time 3 --replay --file grep.xnr --speed-percent 50 
> --recall-window-position

Just a side note:
Sometimes the timing is crucial. Think of double clicks, if you slow
down the speed the double click will turn in to two clicks.

>       xset r on


/hesa