xnee-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xnee-devel] [Fwd: AW: AW: [sr #103871] Verifying GUI-Testresults wi


From: Henrik Sandklef
Subject: Re: [Xnee-devel] [Fwd: AW: AW: [sr #103871] Verifying GUI-Testresults with xnee using theTool "xgrabsc"]
Date: Thu, 16 Feb 2006 23:58:17 +0100

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
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]