new XVideo patch

Hi all,

enclosed a new version of my XVideo patch for ekiga I have
already posted a few month ago. The new
version supports the embedded video windos like the gdk
output. Also, in case Xvideo is not
supported a fallback to GDK should take place (I implemented
this by using a stub
videooutputdevice class that instanciates the XV
videoouputdevice and, in case it is not
available, a GDK videooutputdevice). This patch is against
the latest CVS version. In order to use
the XV extension, apply the patch with patch -p0, copy the
other files to src/devices, then run
autogen.sh.

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.

I would like to welcome feedback of any kind, 
Matthias




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen
Yahoo! Mail: http://mail.yahoo.de_________________________
______________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Hi,

Thanks for this patch!

I had quickly a first look at it.

I don't really have any comment (only the formatting of the
code needs
to change a bit), but it corresponds to what we discussed.

I just wonder, why did you add a new PIP in external window
mode?
(I think it is a great idea, when ekiga is hidden, so we'll
keep it for
course, but I wondered if there was some technical reason
behind it).

Some random thoughts: 
- Perhaps that SDL should become a new videooutput too, like
XV and GTK
- Perhaps the complexity of gm_main_window_update_video
should/could
move to one of the videooutput classes

I don't really know 

But the new code (mine, not yours), with the frames, is
actually quite
CPU intensive.

XV support will definitely be a great feature of 3.00!

Le dimanche 19 novembre 2006 à 22:28 +0100, Matthias
Schneider a écrit :
> Hi all,
> 
> enclosed a new version of my XVideo patch for ekiga I
have already posted a few month ago. The new
> version supports the embedded video windos like the gdk
output. Also, in case Xvideo is not
> supported a fallback to GDK should take place (I
implemented this by using a stub
> videooutputdevice class that instanciates the XV
videoouputdevice and, in case it is not
> available, a GDK videooutputdevice). This patch is
against the latest CVS version. In order to use
> the XV extension, apply the patch with patch -p0, copy
the other files to src/devices, then run
> autogen.sh.
> 
> 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.
> 
> I would like to welcome feedback of any kind, 
> Matthias
> 
> 
> 
> 
> 	
> 		
>
___________________________________________________________ 
> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum
neuen Yahoo! Mail: http://mail.yahoo.de
> _______________________________________________
Ekiga-devel-list mailing list Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
-- 
Damien Sandras

Ekiga Softphone : http://www.ekiga.org
NOVACOM                    : http://www.novacom.be
FOSDEM                      : http://www.fosdem.org
SIP Phone               : sip:dsandrasekiga.net

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

On Sun, 19 Nov 2006 22:28:49 +0100 (CET)
Matthias Schneider <ma30002000yahoo.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.
- 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.

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 


-- 
Live as if you were to die tomorrow.
Learn as if you were to live forever.
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

On Mon, 20 Nov 2006 22:43:23 +0100
Damien Sandras <dsandrasseconix.com> wrote:

> - Perhaps the complexity of gm_main_window_update_video
should/could
> move to one of the videooutput classes

ACK. It will take ages to read in again, but it's worth it.
That
function is too complex and too unflexible, and too
switch()ed.

J.

-- 
"Be liberal in what you accept, and conservative in
what you send."
- J. B. Postel, master of the net.
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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

> On Sun, 19 Nov 2006 22:28:49 +0100 (CET)
> Matthias Schneider <ma30002000yahoo.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-listgnome.org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
> 



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Hi Damien,

--- Damien Sandras <dsandrasseconix.com> schrieb:

> Hi,
> 
> Thanks for this patch!
> 
> I had quickly a first look at it.
> 
> I don't really have any comment (only the formatting of
the code needs
> to change a bit), but it corresponds to what we
discussed.

Yes, thats true, I planned tio work on that anyway...

> I just wonder, why did you add a new PIP in external
window mode?
> (I think it is a great idea, when ekiga is hidden, so
we'll keep it for
> course, but I wondered if there was some technical
reason behind it).

Hm, for me from the start on I onlky wanted an extra window
with Pip functionality since I usually
minimize the phone when in a video call. Also notice the
"d" key with which you can disable the
decorations and e.g. park it in the upper left corner of the
screen and continue working. Actually
also this is the idea on which I based my XVWindow class.

> Some random thoughts: 
> - Perhaps that SDL should become a new videooutput too,
like XV and GTK
The problem I see there is that a separate GTK and SDL class
would not cover all features (window
mode, fullscreen, etc), we would have a SDL class witout
window mode and GTK class without
fullscreen, I dont really know how to abstract this to the
videooutputclass.. 

> - Perhaps the complexity of gm_main_window_update_video
should/could
> move to one of the videooutput classes

I do concur on that, it should move to videoutput_gdk and
rely on main.cpp only for something like
I do with gm_main_window_get_video_widget(). However I do
not know yet how deeply it is interwoven
with the rest of main.cpp
> 
> I don't really know 
> 
> But the new code (mine, not yours), with the frames, is
actually quite
> CPU intensive.
> 
> XV support will definitely be a great feature of 3.00!

It would be great to see that code in ekiga!

> Le dimanche 19 novembre 2006 à 22:28 +0100, Matthias
Schneider a écrit :
> > Hi all,
> > 
> > enclosed a new version of my XVideo patch for
ekiga I have already posted a few month ago. The
> new
> > version supports the embedded video windos like
the gdk output. Also, in case Xvideo is not
> > supported a fallback to GDK should take place (I
implemented this by using a stub
> > videooutputdevice class that instanciates the XV
videoouputdevice and, in case it is not
> > available, a GDK videooutputdevice). This patch is
against the latest CVS version. In order to
> use
> > the XV extension, apply the patch with patch -p0,
copy the other files to src/devices, then
> run
> > autogen.sh.
> > 
> > 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.
> > 
> > I would like to welcome feedback of any kind, 
> > Matthias

> Damien Sandras
> 

Matthias




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen
Yahoo! Mail: http://mail.yahoo.de
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

On Sun, 19 Nov 2006 22:28:49 +0100 (CET)
Matthias Schneider <ma30002000yahoo.de> wrote:

> - The position of the embedded video window is not yet
correct. I
> have not yet found out how to calculate its position...

Hi Matthias!

When you calculate the coordinates out of the video widget
given by the
main, do you realize that video->allocation.{x,y} are
relative to the
parent allocation? It looks like you treat them as absolute.
I may be
wrong, anyways, it was a hard day.

J.

-- 
I know life sometimes can get tough! and I know life
sometimes can be a
drag! But people, we have been given a gift, we have been
given a road
And that roads name is... rock and roll!
KISS in "God gave Rock'n'Roll to you"
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Hi,

Le lundi 20 novembre 2006 à 23:50 +0100, Matthias Schneider
a écrit :
> > I just wonder, why did you add a new PIP in
external window mode?
> > (I think it is a great idea, when ekiga is hidden,
so we'll keep it for
> > course, but I wondered if there was some technical
reason behind it).
> 
> Hm, for me from the start on I onlky wanted an extra
window with Pip functionality since I usually
> minimize the phone when in a video call. Also notice
the "d" key with which you can disable the
> decorations and e.g. park it in the upper left corner
of the screen and continue working. Actually
> also this is the idea on which I based my XVWindow
class.
> 

That's right.

> > Some random thoughts: 
> > - Perhaps that SDL should become a new videooutput
too, like XV and GTK
> The problem I see there is that a separate GTK and SDL
class would not cover all features (window
> mode, fullscreen, etc), we would have a SDL class
witout window mode and GTK class without
> fullscreen, I dont really know how to abstract this to
the videooutputclass.. 
> 

That's right, it is not useful and not feasible easily.

> > - Perhaps the complexity of
gm_main_window_update_video should/could
> > move to one of the videooutput classes
> 
> I do concur on that, it should move to videoutput_gdk
and rely on main.cpp only for something like
> I do with gm_main_window_get_video_widget(). However I
do not know yet how deeply it is interwoven
> with the rest of main.cpp

It doesn't really interact, but let's postpone that for
later.

> > 
> > I don't really know 
> > 
> > But the new code (mine, not yours), with the
frames, is actually quite
> > CPU intensive.
> > 
> > XV support will definitely be a great feature of
3.00!
> 
> It would be great to see that code in ekiga!
> 

It will be integrated, no worries. That is a very nice
contribution,
thanks for it!
-- 
Damien Sandras

Ekiga Softphone : http://www.ekiga.org
NOVACOM                    : http://www.novacom.be
FOSDEM                      : http://www.fosdem.org
SIP Phone               : sip:dsandrasekiga.net

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Hello Jan, what you have seen was rather my last (not
serious) attempt for positioning the window.
Here is what I know: the video->allocation.{x,y} do mark
the upper left corner of the video
widget, it is perfectly ok that these are relative
coordinates since the XVWindows also treats its
coordinates relative to its parent window (rootWindow, in
this case the video-widget). ACtually I
also noticed that I do create the double-lined frame a
little bit two big...

However I do notice 2 points here:
- why is the main ekiga window resizable? it wasnt int 2.0.3
and also many of the icons do appear
sometimes in a rather strange fashion. also resizing this
window would mean that I have to catch
this event and reposition the XVWindow....

- I havent yet understood the reason for having the 2 frames
around the video widget in gdk. This
is calculated in gm_mw_create_pixbuf_with_frame. I could
redo this calculations in order to get
from the upper left edge of the video widget and get the
video window coordinates but I do not
know if this will be the final presentation. I also would
like to ask, isnt the 
  zframe = 
    gdk_pixbuf_scale_simple (frame,
                             (int) ((picture_width +
frame_border * 2) * (zoom * frame_ratio)),
                             (int) ((picture_height +
frame_border * 2) * (zoom * frame_ratio)),
                             GDK_INTERP_BILINEAR);
operation not a very  nasty (in means of cpu power) scaling
operation that gets done every frame
even if zoom = 1 when GDK performance shouldnt be hit that
much? I know from experience that every
scaling operation in software slows down more than the
complexest of all codec... I personally
dont like the double frame so much - however one effort to
mitigate the performance issue may be
to store a scaled version once the zoom factor/image size is
changed or use a non-scaling approach
for drawing the double-lined border... (Sorry I did not have
time to test this, this is only me
speaking from experience)

To sumarize: I think I could get the correct window position
calculated - however at first I would
like to raise the two mentioned issues and gain some more
knowledge about them.,..


Good night,
Matthias

--- Jan Schampera <jan.schamperaweb.de> schrieb:

> On Sun, 19 Nov 2006 22:28:49 +0100 (CET)
> Matthias Schneider <ma30002000yahoo.de> wrote:
> 
> > - The position of the embedded video window is not
yet correct. I
> > have not yet found out how to calculate its
position...
> 
> Hi Matthias!
> 
> When you calculate the coordinates out of the video
widget given by the
> main, do you realize that video->allocation.{x,y}
are relative to the
> parent allocation? It looks like you treat them as
absolute. I may be
> wrong, anyways, it was a hard day.
> 
> J.
> 
> -- 
> I know life sometimes can get tough! and I know life
sometimes can be a
> drag! But people, we have been given a gift, we have
been given a road
> And that roads name is... rock and roll!
> KISS in "God gave Rock'n'Roll to you"
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-listgnome.org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
> 



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Le mardi 21 novembre 2006 à 21:52 +0100, Matthias Schneider
a écrit :

[...]

> However I do notice 2 points here:
> - why is the main ekiga window resizable? it wasnt int
2.0.3 and also many of the icons do appear
> sometimes in a rather strange fashion. also resizing
this window would mean that I have to catch
> this event and reposition the XVWindow....
> 

Because now we have a contacts list. In 3.00 we will even
have status
information for the contacts in the list. So it was sort of
mandatory...

> - I havent yet understood the reason for having the 2
frames around the video widget in gdk. This
> is calculated in gm_mw_create_pixbuf_with_frame. I
could redo this calculations in order to get
> from the upper left edge of the video widget and get
the video window coordinates but I do not
> know if this will be the final presentation. I also
would like to ask, isnt the 
>   zframe = 
>     gdk_pixbuf_scale_simple (frame,
>                              (int) ((picture_width +
frame_border * 2) * (zoom * frame_ratio)),
>                              (int) ((picture_height +
frame_border * 2) * (zoom * frame_ratio)),
>                              GDK_INTERP_BILINEAR);
> operation not a very  nasty (in means of cpu power)
scaling operation that gets done every frame
> even if zoom = 1 when GDK performance shouldnt be hit
that much? I know from experience that every
> scaling operation in software slows down more than the
complexest of all codec... I personally
> dont like the double frame so much - however one effort
to mitigate the performance issue may be
> to store a scaled version once the zoom factor/image
size is changed or use a non-scaling approach
> for drawing the double-lined border... (Sorry I did not
have time to test this, this is only me
> speaking from experience)

This is more a proof concept. The look is there, but the
code needs to
be improved. I would display the frame on the first image,
then display
images inside that frame.

Optimizing this is on my TODO since a long time (and on
Jan's TODO too),
but we have had no time until now :(
-- 
 _      Damien Sandras
(o-     
//   Ekiga Softphone : http://www.ekiga.org/
v_/_ NOVACOM         : http://www.novacom.be/
          FOSDEM          : http://www.fosdem.org/
          SIP Phone       : sip:dsandrasekiga.net
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Hi,

--- Damien Sandras <dsandrasseconix.com> schrieb:

> Le mardi 21 novembre 2006 à 21:52 +0100, Matthias
Schneider a écrit :
> 
> [...]
> 
> > However I do notice 2 points here:
> > - why is the main ekiga window resizable? it wasnt
int 2.0.3 and also many of the icons do
> appear
> > sometimes in a rather strange fashion. also
resizing this window would mean that I have to
> catch
> > this event and reposition the XVWindow....
> > 
> 
> Because now we have a contacts list. In 3.00 we will
even have status
> information for the contacts in the list. So it was
sort of mandatory...

Ok, no problem, so each frame we check the video-widgets
location and in case it is changed we
move the window. I also think  we can consider the embedded
XV window location issue as fixed (I
will implement it as soon as the appearance of ekiga is
final, see below)

> > - I havent yet understood the reason for having
the 2 frames around the video widget in gdk.
...delete...
> This is more a proof concept. The look is there, but
the code needs to
> be improved. I would display the frame on the first
image, then display
> images inside that frame.
> 
> Optimizing this is on my TODO since a long time (and on
Jan's TODO too),
> but we have had no time until now :(
> -- 
>  _      Damien Sandras

Ok, I think all the mentioned issues could be addressed at
once, i.e. 
- move the GDK/SDL code to videooutput_gdk
- fix the XV window location issue
- improve the performance by kickig out some of the
gdk_pixbuf_scale_simple (I personally would
consider any putput makeing use of them unworkable but its
nice to have the GDK stuff for fallback
and on windows until something better is available).

Do you think it is possible to draw the frame outside the
main_video_image and use it only for the
video image? My idea now would be to have 

GtkWidget* gm_get_main_video_image()   return GTK_WIDGET
(mw->main_video_image);
void gm_main_window_update_logo (GtkWidget *main_window)
void gm_main_window_update_frame (X)


made available from main.cpp to the videooutput plugin, so
it can get the location info for the
video image. These 3 functions could be used by
videooutput_xv and videooutput_gdk. Additionally 

void gm_main_window_update_video
gm_mw_destroy_fullscreen_video_window
gm_mw_poll_fullscreen_video_window
gm_mw_toggle_fullscreen
gm_mw_init_fullscreen_video_window
could be moved (more or less copy and paste) to
videooutput_gdk.cpp

For the GDK external windows ("BOTH") there are
two possibilities: leave the instanciation where
it is and implement a gm_get_local|remote_video_window()
function or move that into
videoutput_gdk.cpp as well. Do you think that would be a
proper approach?

Matthias

p.s.
Which of the gm_main_window_XXX and gm_mw_XXX notation is
the more recent?




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen
Yahoo! Mail: http://mail.yahoo.de
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Matthias Schneider a écrit :
> Ok, no problem, so each frame we check the
video-widgets location and in case it is changed we
> move the window. I also think  we can consider the
embedded XV window location issue as fixed (I
> will implement it as soon as the appearance of ekiga is
final, see below)

*each frame* !? Isn't it a little too much? Can't we be
notified of the 
main window moves/resizes which affect us?

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Hi Julien, 
actually I dont think that its a very big deal, its just two
if statements. The following checks
are already performed on each frame, so one check more wont
really make a difference...

- change of display mode (local, remote, incrusted, etc)
- multiple fullscreen state changes
- remote or local frame resolution
- change of zoom   level

Have a look at the lastfarme and beforefsswitch variables...

Matthias
--- Julien Puydt <jpuydtfree.fr> schrieb:

> Matthias Schneider a écrit :
> > Ok, no problem, so each frame we check the
video-widgets location and in case it is changed we
> > move the window. I also think  we can consider the
embedded XV window location issue as fixed
> (I
> > will implement it as soon as the appearance of
ekiga is final, see below)
> 
> *each frame* !? Isn't it a little too much? Can't we be
notified of the 
> main window moves/resizes which affect us?
> 
> Snark
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-listgnome.org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
> 



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Le mercredi 22 novembre 2006 à 20:01 +0100, Matthias
Schneider a écrit :
[...]

> 
> p.s.
> Which of the gm_main_window_XXX and gm_mw_XXX notation
is the more recent?

gm_mw_ is for static function.
gm_main_window is for public functions part of the API.
-- 
 _      Damien Sandras
(o-     
//   Ekiga Softphone : http://www.ekiga.org/
v_/_ NOVACOM         : http://www.novacom.be/
          FOSDEM          : http://www.fosdem.org/
          SIP Phone       : sip:dsandrasekiga.net
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list