Re: [Xnee-devel] [Fwd: AW: AW: [sr #103871] Verifying GUI-Testresults with xnee using theTool "xgrabsc"]

[Henrik Sandklef]

Hi,

 Finally, the "window position" code is released. During a nightly hack at
a hotell in Brusselles (FOSDEM) I merged some pieces of code into a fully
functional (but not regresssion tested) Xnee. The new functionality is
tested and since it (probably!) doesn't interfer with the rest of the
code I will release it "tested but not regression tested":

  ftp://alpha.gnu.org/gnu/xnee/Xnee-2.04.92.tar.gz

 Until regression test is done, it is a alpha release.


 How does it work?
 --------------------
 Xnee records data to move the move during replay but it is up to the user
to enable the actual moving of the window during replay. This is done by
using the "--recall-window-position" option.

 Xnee discards the information recorded if the "--recall-window-position"
option is not used.


/hesa


 ... next thing now is to do a code cleanup (including memory leak check,
profiling etc).







On Thu, February 16, 2006 11:58 pm, Henrik Sandklef said:
> NOooh,
>
> I missed to take the (ICCCM-compliant) WM's gravity into account. Will
> hack some more.
>
> Xnee can move (during replay) an xterm window launched like this (during
> recording):
>       xterm -geometry +10+10
>
> but not if started like this:
>       xterm -geometry -10-10
>
>
>
> /h
>
> On Tue, 2006-02-14 at 10:44 +0100, Henrik Sandklef wrote:
>> Yes!!
>>
>> I now have Xnee up and running with the new "move the window"
>> functionality. Just need to make sure Xnee can handle multiple new
>> windows before releasing it.
>>
>> In the meantime it would be great if you could think about:
>>
>>
>>      Should this funtionality be On by default?
>>
>>
>> /hesa
>>
>>
>>
>> .... if you dare to test it, check out the latest CVS ;)
>> Make sure you use the "--record-window-position" when recording.
>>
>>
>>
>>
>>
>> On Thu, 2006-02-09 at 21:27 +0100, Henrik Sandklef wrote:
>> > Hi all
>> >
>> > I think that the problem is solved (locally on my computer, not in
>> CVS).
>> > In short what has been done is as described in the previous email.
>> >
>> > One  problem though:
>> > -----------------------------------
>> >   1) Xnee (if secified to do soo) records X11 data
>> >      (an Event called ReparentNotify) to detect the
>> >      new window.
>> >
>> >   2) User wants to record ReparentNotify too.
>> >
>> > Solution:
>> >   Some new state variables Xnee :(
>> >
>> >
>> >
>> > .... and another one:
>> > -----------------------------------
>> > We have the following information
>> >    1) The "old" window position stored on file.
>> >
>> >    2) The new window position (using XGetWindowAttributes)
>> > What comes first? The read info (1) or the info from our current
>> session
>> > (2)?......
>> >
>> > Solution:
>> >  We store every (1) and (2) in two separate buffers. Once the buffers
>> > contain "the same" info we move the window (2) and remove the buffer
>> > entries.
>> >
>> >
>> >
>> > And why don't I release it NOW????
>> > ... needs some more testing!!! ... just wanted to let you know!
>> >
>> >
>> > /h
>> >
>> > On Mon, 2006-02-06 at 22:33 +0100, Henrik Sandklef wrote:
>> > > Thanks for your input Dirk :)
>> > >
>> > >
>> > >
>> > > On Mon, 2006-02-06 at 21:49 +0100, Henrik Sandklef wrote:
>> > > > email message attachment, "Forwarded message - AW: AW: [sr
>> #103871]
>> > > > Verifying GUI-Testresults with xnee using theTool "xgrabsc""
>> > > > > -------- Forwarded Message --------
>> > > > > From: Kaplick, Dirk <address@hidden>
>> > > > > I know, that in the X11-GUItest perl library is a function
>> integrated,
>> > > > > which can handle the windowposition on the screen. That means,
>> in X11
>> > > > > with XTEST-Extension is a chance to move windows to a
>> screenposition
>> > > > > automaticly.
>> > > > >
>> > > > > What will we need for this move?
>> > >
>> > > We need not use XTest for that. XMoveWindow will do fine :)
>> > >
>> > > > > Hm. I think, we should save the windowposition and the
>> windowname while
>> > > > > recording into the sessionfile.
>> > >
>> > > Good, it is already added in my local copy of the source.
>> > >
>> > > ...and yes, old Xnee can replay newer files and vice versa :)
>> > >
>> > > > > I don't really know the synchronisation functionality of xnee.
>> > > > > Maybe this is still integrated in xnee and I should record more
>> xevents
>> > > > > ?
>> > >
>> > > I am not sure what you mean here... can you pleasr state the
>> question
>> > > again.
>> > >
>> > >
>> > >
>> > > > > What is the effect of this ?
>> > > > >
>> > > > > We could change the windowposition automaticly, whenever we need
>> a given
>> > > > > position while replaying and taking ever the same screenshots of
>> our
>> > > > > application.
>> > > > >
>> > > > > How can we change the windowposition automaticly?
>> > > > >
>> > > > > Read the saved position of window and its name "xxx" from the
>> > > > > sessionfile.
>> > > > > Then make automaticly a mousemove (klick on the title of the
>> window
>> > > > > named "xxx" in the top left corner and drag the window)
>> > > > > to position x, y.
>> > >
>> > > This solution depends on the Window Manger used. We can't even be
>> sure
>> > > that the window manager uses borders.
>> > >
>> > > I'll go for XMoveWindow...
>> > >
>> > > > > So we can handle the recorded screenshots to ever and ever the
>> same
>> > > > > coordinates on the same window.
>> > > > >
>> > > > > I don't think, that the users should give the coordinates to
>> xnee with a
>> > > > > call-parameter (x,y offset).
>> > > > > I think, xnee should record coordinates and names of the windows
>> to
>> > > > > place windows on offset x,y while replaying.
>> > >
>> > > I agree. This is only useful (I think) when having a window that
>> covers
>> > > the entire screen being replayed to a screen (still covering the
>> whole
>> > > screen) with different resolution........
>> > >
>> > >
>> > > > > Should xnee integrate this functionality? I don't know.
>> > >
>> > > I will start hacking on a XMoveWindow.
>> > > During record this will happen:
>> > > - record as specified by user
>> > > - record ReparentNotify as well
>> > > - when getting a ReparentNotify, print new enrty containing name,x,y
>> of
>> > > the new window to session file
>> > >
>> > > During replay this will happen
>> > > - replay as usual
>> > > - when seeing the new printout, pause recording (we record during
>> replay
>> > > to sync)
>> > >  - move window to position as when recorded
>> > >  - resume recording (we record during replay to sync)
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Another solution would be to translate every Motion to the new
>> window's
>> > > coordinates. I (now) think this is a bad idea..... perhaps (upon
>> > > request) it will be implemented.... but not now!
>> > >
>> > >
>> > >
>> > > /h
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > Xnee-devel mailing list
>> > > address@hidden
>> > > http://lists.gnu.org/mailman/listinfo/xnee-devel
>> > >
>> >
>> >
>> >
>> > _______________________________________________
>> > Xnee-devel mailing list
>> > address@hidden
>> > http://lists.gnu.org/mailman/listinfo/xnee-devel
>>
>>
>>
>>
>> _______________________________________________
>> Xnee-devel mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/xnee-devel
>>
>
>
>
> _______________________________________________
> Xnee-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/xnee-devel
>
>