There's a branch done by Damein with some updates in this regard:

http://git.gnome.org/browse/ekiga/commit/?h=ds-gtk3

One of the problems of porting of Ekiga to GTK3 is the video image widget: the architecture of Ekiga depends on extracting the GC (graphic context) of the widget, which is used by x-videooutput for rendering the images using directly the X/XV API.

static gboolean
ekiga_call_window_expose_event (GtkWidget *widget,
                                GdkEventExpose *event)
{

  (...)

  if (!cw->priv->video_widget_gc) {
    cw->priv->video_widget_gc = gdk_gc_new (video_widget->window);
    g_return_val_if_fail (cw->priv->video_widget_gc != NULL, handled);
  }

  display_info.gc = GDK_GC_XGC (cw->priv->video_widget_gc);
  display_info.xdisplay = GDK_GC_XDISPLAY (cw->priv->video_widget_gc);
  display_info.window = GDK_WINDOW_XWINDOW (video_widget->window);

  g_return_val_if_fail (display_info.window != 0, handled);

  gdk_flush();

  display_info.widget_info_set = true;

  boost::shared_ptr<Ekiga::VideoOutputCore> videooutput_core = cw->priv->core->get<Ekiga::VideoOutputCore> ("videooutput-core");
  videooutput_core->set_display_info (display_info);

  return handled;
}

Nevertheless, GTK3 relies totally in Cairo, deprecating gdk_gc*() APIS, and Cairo, AFAIK, doesn't provide an API to export the graphics context. It is mandatory to use Cairo to draw in a GTK3 widget.

Is there a workaround for it?

We (ekiga devs) do not know for the moment, Damien noticed at the time this problem too, but not found the solution yet.

I would say that solving the issues with the gstreamer code would help, as we would then be able to completly change the video display code -- it would probably also simplify a lot of other features (current or future), like extended remote video streams or recording.

(In reply to comment #4)
> I would say that solving the issues with the gstreamer code would help

I do agree. A GStreamer pipeline for showing the video images would be the most sane and flexible way to deal with this.

Opal v3.12 Eridani has added a GStreamer end-point which can be used instead of PCSS end-point

http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/ptlib/trunk/include/ptclib/gstreamer.h

http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/ptlib/trunk/src/ptclib/gstreamer.cxx

http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/opal/trunk/include/ep/GstEndPoint.h

http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/opal/trunk/src/ep/GstEndPoint.cxx

Gst(In reply to comment #6)
> Opal v3.12 Eridani has added a GStreamer end-point which can be used instead of
> PCSS end-point

GStreamer 0.10 :(

> 
> http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/ptlib/trunk/include/ptclib/gstreamer.h
> 
> http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/ptlib/trunk/src/ptclib/gstreamer.cxx
> 
> http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/opal/trunk/include/ep/GstEndPoint.h
> 
> http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/opal/trunk/src/ep/GstEndPoint.cxx

Yes, I think currently the best course of action is:
(1) fix the gstreamer plugin in ekiga
(2) make that plugin non-plugin and use that for devices on all platforms
(3) rework the video output code to use gstreamer
(4) switch the rest to gtk+3

Created attachment 235458 [details] [review]
X: remove the graphic context handling

The main reason behind to keep depending on GTK+-2.0 is because the rendering
subsystem demanded the graphic context of the widget. But this is not
mandatory. You can create a graphic context and use it in your widget.

This patch removes the graphic context from the XWindow and XVWindow
constructors and creates a new one in their initializations. Now Ekiga is not
tied to GTK+-2.0, at least because of this.

This behavior is similar what GStreamer's xvimagesink does.

Wonderful!  I will test it very soon.

Champagne !

Tomorrow, I'll finish the porting work in a separate branch !!!

Thanks 1 million times !!!

hold the champagne! :(

Yesterday I forgot to test one thing: _fullscreen_    and this patch break it ... sorry...

Even more, this patch is not complete either: there are a couple things more to clean if the GC handling is removed.

I hope this weekend I could review this and I hope to be able to handle the fullscreen feature.

But, this situation makes me to question: "fullscreen feature is that important?"

(In reply to comment #12)
> But, this situation makes me to question: "fullscreen feature is that
> important?"

I would say that for users fullscreen is very interesting: when using a videoprojector, or simply to have the image as big as possible.

Victor, do you think you will be able to finish the GTK3 patch? I'd like to commit it and finish the GTK3 porting. Nice work btw, thanks a lot!

(In reply to comment #14)
> Victor, do you think you will be able to finish the GTK3 patch? I'd like to
> commit it and finish the GTK3 porting. Nice work btw, thanks a lot!

Hi Damien, sorry, I haven't work on this since then, and nowadays I have so little time and energy for this task. I can't make promises. Perhaps in a month, or so, I could retake this patch.

Hi,

I devoted this afternoon to figure out how the XVWindow and XWindow work, either in fullscreen or not.

I crafted a test that works with Gtk+-3 and Gtk+-2 

Here's the code:

https://github.com/ceyusa/bgo685404

Now we shall change the XWindow/XVWindow classes according to these findings.

Winderful, Victor!  I let Damien take care of it.

Wonderful Victor!

I have started working hard on the GTK3 port this afternoon too. 

Your first patch is already in.

If you want to play with it, the branch is now ds-gtk3-new. The other one has been deleted because it was too ancient.

So, if you generate a new patch, please do it (if possible) against this specific branch. You won't be able to test though, because it does not compile yet :(

It compiles up to Call-Window.cpp.

Next step is ExtWindow (which still contains GdkGC references too).

Created attachment 238637 [details] [review]
X: remove the GdkGC handling

The main reason behind to keep depending on GTK+-2.0 is because the
rendering subsystem demands the X graphic context of the widget, but
GTK+-3.0 remove the GdkGC handling in favor of Cairo.

Nevertheless, in order to keep the same functionality without
refactoring all the video output subsystem, we can create the X graphic
context of our widgets.

This patch creates our own GC, using the Xlib function XCreateGC directly.

(In reply to comment #18)
> Wonderful Victor!
> 
> I have started working hard on the GTK3 port this afternoon too. 
> 
> Your first patch is already in.

That patch is wrong. I've uploaded a new approach because the GC creation cannot be done in the XWindow/XVWindow classes.

> 
> If you want to play with it, the branch is now ds-gtk3-new. The other one has
> been deleted because it was too ancient.

I could rebase your patches with just a few simple conflicts. 

> 
> So, if you generate a new patch, please do it (if possible) against this
> specific branch. You won't be able to test though, because it does not compile
> yet :(

Right now it should compile.

Still this is a hack. A good refactoring imply much more work, such as removing the X calls and use cairo instead.

I would gladly propose another path to remove this dependence : add gstreamer as an ekiga dependence and use it for all our audio+video needs. It does everything we want and more ; see the following blog posts:
http://www.oz9aec.net/index.php/gstreamer/347-more-gstreamer-tips-picture-in-picture-compositing and http://tristanswork.blogspot.fr/2008/09/fullscreen-video-in-gstreamer-with-gtk.html ; of course the following documentation is useful too: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-videomixer.html for the video mixing, and http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstvideooverlay.html to display in a window or fullscreen.

That would help with porting to gtk+3, help with supporting other platforms, help add new features (play an audio+video message, record calls...).

(In reply to comment #22)
> I would gladly propose another path to remove this dependence : add gstreamer
> as an ekiga dependence and use it for all our audio+video needs. It does
> everything we want and more

I agree!!

I agree too. 

However, the first step is to apply your patch (thanks a lot), and then, if we have the time, we can use GStreamer. I don't feel the energy right now to do it, but I think clutter or GStreamer are the way to go on the long term.

Thanks to you (big big big, huge thanks!), the GTK3 port is over.

I have removed all deprecated methods and ported all the rest to GTK3. The changes have been merged into master.

Thanks a lot!

And where is the champagne? :)

So finally the fear was greater than the reality :)

Ah well, I hold the champagne until we replaced GCONF, HAL and son on ;-)