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

[Mads Lindstrøm]

Hi Henrik

> hi, and thanks for your report
> 
> Mads Lindstrøm wrote:
> > Hi all
> > 
> > I have tried to use Xnee for recording and replaying events. But if the
> > window is not in the same position when I record events, as when I
> > replay the events, then the replay do not go as expected. I tried using
> > the --recall-window-position option, but it did not help.
> 
> 
> That's strange. Is the window created during recording/replying or does
> it exist before?
It is created after starting cnee.

> 
> if not, use:
>    --xnee_replay_offset
>    (will be renamed to '--replay-offset' in coming 3.0.2)
That would require specifying the positions manually. That is what I am
trying to avoid. I would like Xnee to be as adaptive as possible.

> > It seems that Xnee is recording absolute mouse positions. If Xnee
> > recorded them relative to the window that the mouse pointer was located
> > within, it would not matter if a window did not have the same position
> > when recording and replaying the events. E.g. I would like Xnee to store
> > both the mouse position relative to the window which the mouse pointer
> > is located within and the title of this window. Then when the events are
> > replayed, Xnee should search for a window with the recorded title, make
> > it active, and move the mouse pointer relative to the window which it
> > had just made active. This would eliminate the problem mentioned above.
> 
> It would be hard to implement and I am not sure it's worth it. What
> window events should belong to what windows. Let's say that we move the
> mouse over a window while recording. During replay you say we make the
> window active (by clicking?). Then we interfere with the recorded session.
> 
> 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. 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.

> 
> - Wouldn't he same thing will happen with --recall-window-position?
> Yes :(

You are right. The right solution is properly not my suggestion, but to
figure out why --recall-window-position do not do as expected on my
computer.

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

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 &
        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
        xset r on


Greetings,

Mads Lindstrøm