Re: [Ekiga-devel-list] new XVideo patch

[Matthias Schneider <ma30002000 yahoo de>]

Hi Jan,
my comments inline....
--- Jan Schampera <jan schampera web de> schrieb:

> On Sun, 19 Nov 2006 22:28:49 +0100 (CET)
> Matthias Schneider <ma30002000 yahoo de> wrote:
> 
> > Right now there are only two (minor) issues still in the
> > implementation:
> > - The position of the embedded video window is not yet correct. I
> > have not yet found out how to calculate its position...
> > - When switching from an external window to fullscreen and back the
> > window will move down. This is due to the decoration of the window
> > which isnt taken into account when backing up the state when going
> > into fullscreen. I am still investigating how to correct this.
> 
> Okay, some feedback. It took a while, sorry, seems we're all over-busy
> at the moment :-(
> 
> - I don't get video with the embedded XV windows. I didn't browse the
>   code that much, lack of time. I'm sure when I look closer, I'll find
>   it.
Write me when you know more. While I had the external windows running in about a week the embedded
windows took about two month to implement and debug because of some strange bugs... Also the
state-changes (zoom, presentation type, fullscreen) where non-trivial...

> - The "separate" XV windows and fullscreen works. Great! And it seems
>   more performant than GDK.
> 
> You see, I wasn't able to look very much into the code, but I proofed
> that it works. Thanks for it, and if you find the time, don't stop
> developing on it ;-) For the decorations, I read something about asking
> the WM or getting WM hints (I read it in another context, so I didn't
> take care that much). It looked like a common way.
>
Well, one way to mitigate this is by switching the decorations of before getting the window
coordinates. This is what the XVWindow class uses when going into the "internal" FS mode (when
pressing "f" when in the external window. The only problem I have when trying to use this
technique in the getWindow function is that it seems that it doesnt get applied in time before
getting the coordinates - if I put a sleep (1) between it works. In my understanding a XFlush or
an XSync should do the trick but still the result is not what I expect. 

About time to develop, until January I will be a little bit occupied, but as of mid of January I
will will be able to invest enough time to finalize this ( I think this will be quick, perhaps 2-3
weeks). I also would like to take some time for more extensive testing... Of course if any of you
has any smaller modifications or bugfixes I suppose I will be able to take them into account
earlier. 
> Jan
> 
> PS: Yes, I'll find the time for the code. From what I have seen so far,
> nothing critial, mostly I-had-too-less-coffee-bugs, we all make
> them ;-)

I am usually working on this project after my "primary" work (I suppose its something similar for
many of you out there) so usually I am not the freshest at that time. Any bugfixes are welcome....
> 
> -- 
> Live as if you were to die tomorrow.
> Learn as if you were to live forever.
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
> 



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de