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
Attachment:
ekiga-win32-patches.tar.gz
Description: application/tgz