Re: [GnomeMeeting-devel-list] WIN32 report

[Alejandro Blanco Martín <alexb tid es>]

Hello Michael,

I have downloaded your Ekiga-win32 from your web page and it works 
perfectly!

I would like to prepare in my computer an enviroment in order to compile 
ekiga´s sources and get the executable binaries, I would like to see how 
to integrate audio/video recording. I have read in ekiga web page that 
opal and pwlib libraries are needed, so I have looked for information 
about these two libraries and I have found the next web page to compile 
them (http://www.voxgratia.org/docs/pwlib_windows.html and 
http://www.voxgratia.org/docs/opal_windows.html). I am trying to compile 
it using Ms Visual C++ .net.

I have seen that your scritps to build the windows release include 
makefile for opal and pwlib, do you think it would be better to use 
another enviroment instead of MS Visual C++ .net and use the makefile 
you provide? is it possible to use that makefiles and MS Visual C++? My 
question may be are nonsense, I`m sorry, I´m newbie with C++ enviroments..

Thanks in adavance,
Alex.

Michael Rickmann escribió:
> Hello everybody,
> here a short report on my work to bring Ekiga-Win32 to beta. Currently, I have 
> six patches on stock and I have a first version of an installer. Patches and 
> my Makefile you find attached to this mail, the rest at 
> http://wwwuser.gwdg.de/~mrickma/ekiga .
> As to the patches, 1 and 6 fix bugs, 2 to 4 add missing features. I really 
> made shure that there are no unbalanced #ifdef s this time.
>
> 1) adresses the hung SDL-Window. On Windows a window can only be destroyed by 
> the thread that created it. SDL-Video switching is done from 
> gm_main_window_update_video in src/gui/main.cpp which, however, is used by 
> two threads. So Julien suggested to append the video switching to the Glib 
> main loop using g_idle_add and to provide wrapper functions for the WIN32 
> case. I have named these functions when_idle_init_SDL_video and 
> when_idle_quit_SDL_video, they are idle-added from 
> gm_mw_init_fullscreen_video_window and gm_mw_destroy_fullscreen_video_window. 
> So video switching is done somewhen and gm_main_window_update_video has to 
> know when it may send output to the SDL screen. I used mv->screen for that 
> purpuse. It is set after the screen has been obtained in 
> when_idle_init_SDL_video, and it is cleared before the SDL video is shutdown 
> in when_idle_quit_SDL_video.
> How is this handled in gm_main_window_update_video? The local helper variable 
> fs_active becomes set from mv->screen in WIN32 and indicates a usable SDL 
> window, whereas display_type, an argument to the function, is used to 
> initiate switching if necessary. So there is a delay between display_type and 
> fs_active. On fullscreen init this is handled nicely if all SDL drawing 
> depends on fs_active / mv-screen - I had to add only one more if() to the 
> code. In case of shutdown, however, a high magnification frame appeared in 
> Ekiga`s Gtk window, which may not be safe. So I omit video output completely 
> for the case (display_type != FULLSCREEN) && fs_active.
> Three more points: SDL_WM_ToggleFullScreen is not available for WIN32. You 
> have to supply SDL_FULLSCREEN with the flags to SDL_SetVideoMode to get a 
> real hardware fullscreen. In my patch this can be enabled if you compile with 
> -DWIN32_FULLSCREEN. Since we are still in the debugging phase this is not so 
> desirable.
> For WIN32 the SDL-event queue is emptied completely during 
> gm_mw_poll_fullscreen_video_window. This makes the sluggish switching a bit 
> more responsive.
> I had to stick with SDL_InitSubSystem / SDL_QuitSubSystem. Freeing the surface 
> only was insufficient to remove that SDL_app window.
>
> 2) Because of readability this patch which only changes the WinMain function 
> is at second position. It adds a system wide mutex showing that Ekiga is 
> running. A second instance of Ekiga also tries to create this mutex and will 
> decide to shutdown when that mutex already exists. In addition, the installer 
> can query this mutex and ask the user to shutdown Ekiga before installing a 
> new version.
>
> 3) Adding more SDL initialisation and shutdown code from the WIN32 SDL sources 
> to WinMain. On Windows XP Ekiga runs without this. But it seems required for 
> a more generally usable minimal Win32 SDL app.
>
> 4) Add command line parsing and stdout/stderr redirection: We need the command 
> line to enable debug output and to have Ekiga open a sip: URL from a 
> different program. I have tried several approaches to get arguments into 
> **argv which are compatible with GOption and gtk_init. There seem to be two 
> requirements, UTF-8 and let Windows pathname backslashes pass. Currently, a 
> proper commandline is obtained by GetCommandLine () and parsed in a selfmade 
> routine which is actually a short form of that contained in the SDL sources.
> Output redirection works if Ekiga is started from a directory for which the 
> user has write access.
>
> 5) Enable Ekiga's help for the WIN32 case of DISABLE_GNOME. The contents entry 
> in the help popup had to be reenabled in src/gui/main.cpp. And in 
> src/gui/callbacks.cpp, function help_cb proper handling has to be supplied. 
> My patch assumes that the help can be found in 
> DATADIR\help\locale\index.xhtml. The routine tries to guess under which 
> locale Ekiga is running ( g_win32_getlocale () is supplied by Glib ), tries 
> to open DATADIR\help\en\index.xhtml e.g., fails and falls back to opening 
> DATADIR\help\C\index.xhtml. For for French it would have succeded 
> immediately. Opening is done with the Windows shell api function ShellExecute 
> which tries to open the index.xhtml with the program associated with the 
> xhtml extension. Internet Explorer refuses to decode XHTML if the file 
> doesn't have an html extension and its XHTML decoding seems buggy. So we have 
> to advise users to install Firefox which does a perfect job. How I create 
> Ekiga's help in xhtml format you can see in the attached Makefile. In brief, 
> make in ekiga/help and run the index.xml files through xsltproc using 
> db2html.xsl.
>
> 6) Stuttering audio in the audio test of the setup druid, i.e in 
> src/devices/audio.cpp: For the time being, and on the two XP Home machines I 
> have tried, Windows cannot cope with the 16000 Hz CreateOpenedChannel request 
> in function GMAudioRP::Main (). Changing this to 8000 fixes the stuttering 
> and increasing the buffers to 3 (Opal does that for WIN32 too) fixes the 
> clicks which otherwise become audible without stuttering.
> Perhaps this patch is a bit premature, since I have seen in pwlib-cvs and 
> opal-cvs ChangeLog that Craig Southeren is working on "media format changes", 
> whatever that means.
> By the way, there is some inconsistency in the code of src/devices/audio.cpp 
> for Linux too. GMAudioRP::Main () operates on 16000 Hz sampling frequency but 
> GMAudioTester::Main () allocates a buffer for 8000 Hz only. And - sorry for 
> this one, I dislike mutexes - the tester.buffer_ring_access_mutex.Wait () 
> and .Signal () are not necessary as only one thread writes to the 
> tester.buffer_ring and each holds its private buffer.
>
> Finally a Windows setup.exe for Ekiga: There seems to be only one free 
> installer available, Inno Setup at http://www.jrsoftware.org/isinfo.php. It 
> seems very good, is an open source Delphi program and runs flawlessly under 
> Linux Wine (requires X though). In my Windows registry I discovered that even 
> Skype uses Inno.
> The Gimp for Windows also uses Inno Setup for its installer 
> ( http://gimp-win.sourceforge.net/ ) and Jernej Simoncic has made the sources 
> for his Gimp and Gtk+ install scripts freely available.
> Importantly, the Gtk+ installer sets the Windows environment path for the Gtk+ 
> 2 dlls. I checked it on a Gtk+ free XP Home system - cleaned by hand. During 
> my earlier trials I came across a machine where that did not work. So our 
> milage may vary.
> I could adapt large parts of the Gimp installer script for Ekiga, i.e. all the 
> Gtk, CPU and stray DLL checks. Thanks to Jernej Simoncic work for The Gimp 
> the first version of Ekiga's Win32 installer is already fairly advanced. You 
> find it in the "iss" directory of 
> http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga_build.tgz. As Julien suggested, 
> the [Registry] section of ekiga.iss tries to make sip: URLs known to Windows 
> and to associate Ekiga with them. I do not know yet whether it works.
>
> As to my build process and to the principle differences to Kilian's current 
> Makefile:
> 1) I have created a rc subdirectory wich holds the program icon and a ekiga.rc 
> which includes versioning and copyright information for the executable and is 
> run through windres
> 2) for ekiga/src/ekiga.exe:
>    SDL is linked in dynamically
>   .... cd ekiga/help; $(MAKE)
> 3) for dist/zips: ...
>   install -m 755 bin/SDL.dll dist/Ekiga
>   ... generation of manuals ...
>   cd $$manu ; $(XSLTPROC) $(BUILDROOT)/ekiga/help/$$manu/ekiga.xml > index.
> $(MANUAL_EXT) ; \
>   ... generation of the setup executable ...
>   wine "c:\Programme/Inno Setup 5\Compil32.exe" /cc iss/ekiga.iss
>
> Still anybody reading ??
> Regards
> Michael
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
>