Re: [Ekiga-devel-list] Win32 Ekiga painful

2009-05-01 Thread Peter Robinson
Hi Craig,

 If upstream means Opal, then I think this is being a bit unfair.

 I use Opal/PTLib on Windows and Linux every day. On both these operating
 systems, there is no problem.

 We are extremely busy maintaining support for these two operating systems
 using their native compilers (gcc and MSVC), as well as bringing in new code
 and features.

 I've tried to cross-compile Ekiga for Windows, but it requires a debian box
 with the latest dev code (Sid?) and I simply can't dedicate a whole machine
 for this purpose, northe time it would take to make it work.

 Now, if I could cross-compile ekiga on a Fedora box then I would be REALLY
 interested. :)

You should be able to use Fedora 11 for cross compiling for windows
[1]. It will have a complete mingw stack. I think the maintainer has
also pushed most of the stack to Fedora 10 as updates as well. If
there's any thing missing from it that you need let me know and I'll
see if I can't get it added.

Cheers,
Peter

[1] https://fedoraproject.org/wiki/Features/Windows_cross_compiler
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list


Re: [Ekiga-devel-list] Win32 Ekiga painful

2009-04-29 Thread Michael Cronenworth

Craig Southeren wrote:


Now, if I could cross-compile ekiga on a Fedora box then I would be 
REALLY interested. :)


The official build on ekiga.net is from a Fedora box. I made that build 
on Fedora 10.


yum install mingw32-gcc
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list


Re: [Ekiga-devel-list] Win32 Ekiga painful

2009-04-29 Thread Craig Southeren

Michael Cronenworth wrote:

Craig Southeren wrote:


Now, if I could cross-compile ekiga on a Fedora box then I would be 
REALLY interested. :)


The official build on ekiga.net is from a Fedora box. I made that build 
on Fedora 10.


yum install mingw32-gcc


Last time I tried the procedure at the following URL, it didn't even go 
close to working on Fedora:


http://wiki.ekiga.org/index.php/Cross-compile_Win32

Is that this what you did? Were any changes needed?

  Craig
--

---
 Craig Southeren  Post Increment – VoIP Consulting and Software
 cra...@postincrement.com.au   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: craig_southe...@hotmail.com
 Mobile: +61 417231046  Jabber: cra...@jabber.org

 Science is the poetry of reality. Richard Dawkins
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list


Re: [Ekiga-devel-list] Win32 Ekiga painful

2009-04-29 Thread Michael Cronenworth

Craig Southeren wrote:
Last time I tried the procedure at the following URL, it didn't even 
go close to working on Fedora:


http://wiki.ekiga.org/index.php/Cross-compile_Win32

Is that this what you did? Were any changes needed?


The Makefile in Gnome SVN/Git is not appropriate for Fedora MinGW. It 
was made by a guy using Debian. I was not sure how to handle a Fedora 
Makefile, but I think I will just submit it as Makefile.fedora and 
call it a day. Let me change it to use Gnome Git instead of SVN and I'll 
post it on this list.

___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list


Re: [Ekiga-devel-list] Win32 Ekiga painful

2009-04-25 Thread Julien Puydt

Michael Rickmann a écrit :

Building Win32 Ekiga from current heads is not straightforward. Ekiga,
Ptlib and Opal seem to have regressed in some aspects.
1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to
fix it with attached patch. There were two major issues: Where does
GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment.
My compiler wants the functions at the end, like device_error_in_main,
be explicitly made members of class GMVideoOutputManager_dx. Otherwise
it would not allow the signals to be inherited.


That one is normal : I did blind changes a few days ago (see the log 
commit).


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

Re: [Ekiga-devel-list] Win32 Ekiga painful

2009-04-25 Thread Julien Puydt

Julien Puydt a écrit :

Michael Rickmann a écrit :

Building Win32 Ekiga from current heads is not straightforward. Ekiga,
Ptlib and Opal seem to have regressed in some aspects.
1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to
fix it with attached patch. There were two major issues: Where does
GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment.
My compiler wants the functions at the end, like device_error_in_main,
be explicitly made members of class GMVideoOutputManager_dx. Otherwise
it would not allow the signals to be inherited.


That one is normal : I did blind changes a few days ago (see the log 
commit).


Your patch is in!

Sorry for the inconvenience,

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

Re: [Ekiga-devel-list] Win32 Ekiga painful

2009-04-25 Thread Eugen Dedu

Michael Rickmann wrote:

Building Win32 Ekiga from current heads is not straightforward. Ekiga,
Ptlib and Opal seem to have regressed in some aspects.
1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to
fix it with attached patch. There were two major issues: Where does
GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment.
My compiler wants the functions at the end, like device_error_in_main,
be explicitly made members of class GMVideoOutputManager_dx. Otherwise
it would not allow the signals to be inherited.
2) Ekiga with current Ptlib head is unable to detect any audio or video
devices - all silence. This seems to be due to the changes introduced
with Replaced PWLibStupidLinkerHacks. I had to go back to revision
22442.


I created a bug report for this: 
https://sourceforge.net/tracker/?func=detailaid=2781050group_id=204472atid=989748


Thanks!
--
Eugen
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list


[Ekiga-devel-list] Win32 Ekiga painful

2009-04-24 Thread Michael Rickmann
Building Win32 Ekiga from current heads is not straightforward. Ekiga,
Ptlib and Opal seem to have regressed in some aspects.
1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to
fix it with attached patch. There were two major issues: Where does
GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment.
My compiler wants the functions at the end, like device_error_in_main,
be explicitly made members of class GMVideoOutputManager_dx. Otherwise
it would not allow the signals to be inherited.
2) Ekiga with current Ptlib head is unable to detect any audio or video
devices - all silence. This seems to be due to the changes introduced
with Replaced PWLibStupidLinkerHacks. I had to go back to revision
22442.
3) Opal was also changed because of the PWLibStupidLinkerHacks and
depends on the changes in Ptlib. I had also to go back.
Regards
Michael

diff -ur ekiga.orig/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp ekiga/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp
--- ekiga.orig/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp	2009-04-24 21:31:18.654979488 +0200
+++ ekiga/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp	2009-04-24 21:33:13.205008765 +0200
@@ -92,14 +92,14 @@
 break;
   case Ekiga::VO_MODE_UNSET:
   default:
-PTRACE (1, GMVideoOutputManager_DX\tDisplay variable not set);
+PTRACE (1, GMVideoOutputManager_dx\tDisplay variable not set);
 return;
 break; 
   }
 
   if (   (!local_display_info.widget_info_set) || (!local_display_info.config_info_set) 
   || (local_display_info.mode == Ekiga::VO_MODE_UNSET) || (local_display_info.zoom == 0) || (current_frame.zoom == 0)) {
-PTRACE(4, GMVideoOutputManager_DX\tWidget not yet realized or gconf info not yet set, not opening display);
+PTRACE(4, GMVideoOutputManager_dx\tWidget not yet realized or gconf info not yet set, not opening display);
 return;
   }
 
@@ -109,7 +109,7 @@
 
   switch (current_frame.mode) {
   case Ekiga::VO_MODE_LOCAL:
-PTRACE(4, GMVideoOutputManager_DX\tOpening :VO_MODE_LOCAL display with image of   current_frame.local_width  x  current_frame.local_height);
+PTRACE(4, GMVideoOutputManager_dx\tOpening :VO_MODE_LOCAL display with image of   current_frame.local_width  x  current_frame.local_height);
 dxWindow = new DXWindow();
 video_disabled = !dxWindow-Init (local_display_info.hwnd,
   local_display_info.x,
@@ -129,7 +129,7 @@
 break;
 
   case Ekiga::VO_MODE_REMOTE:
-PTRACE(4, GMVideoOutputManager_DX\tOpening VO_MODE_REMOTE display with image of   current_frame.remote_width  x  current_frame.remote_height);
+PTRACE(4, GMVideoOutputManager_dx\tOpening VO_MODE_REMOTE display with image of   current_frame.remote_width  x  current_frame.remote_height);
 dxWindow = new DXWindow();
 video_disabled = !dxWindow-Init (local_display_info.hwnd,
   local_display_info.x,
@@ -151,7 +151,7 @@
   case Ekiga::VO_MODE_FULLSCREEN:
   case Ekiga::VO_MODE_PIP:
   case Ekiga::VO_MODE_PIP_WINDOW:
-PTRACE(4, GMVideoOutputManager_DX\tOpening display   current_frame.mode   with images of  
+PTRACE(4, GMVideoOutputManager_dx\tOpening display   current_frame.mode   with images of  
  current_frame.local_width  x  current_frame.local_height  (local) and  
 	 current_frame.remote_width  x  current_frame.remote_height  (remote));
 dxWindow = new DXWindow();
@@ -184,7 +184,7 @@
 return;
 break;
   }
-  PTRACE (4, GMVideoDisplay_DX\tSetup display   current_frame.mode   with zoom value of   current_frame.zoom );
+  PTRACE (4, GMVideoOutputManager_dx\tSetup display   current_frame.mode   with zoom value of   current_frame.zoom );
 
   if (local_display_info.on_top  dxWindow)
   dxWindow-ToggleOntop ();
@@ -197,11 +197,11 @@
   if (video_disabled) {
 delete dxWindow;
 dxWindow = NULL;
-Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, GMVideoDisplay_DX::device_error_in_main), Ekiga::VO_ERROR));
+Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, GMVideoOutputManager_dx::device_error_in_main), Ekiga::VO_ERROR));
   }
   else {
 current_frame.accel = Ekiga::VO_ACCEL_ALL; 
-Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, GMVideoDisplay_DX::device_opened_in_main), current_frame.accel, current_frame.mode, current_frame.zoom, current_frame.both_streams_active));
+Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, GMVideoOutputManager_dx::device_opened_in_main), current_frame.accel, current_frame.mode, current_frame.zoom, current_frame.both_streams_active));
   }
 }
 
@@ -261,14 +261,14 @@
 }
 
 void
-size_changed_in_main (unsigned width,
+GMVideoOutputManager_dx::size_changed_in_main (unsigned width,
 		  unsigned height)
 {
   size_changed.emit (width, height);
 }
 
 void
-device_opened_in_main (Ekiga::VideoOutputAccel