Re: [Ekiga-devel-list] Win32 UTF-8 vs. Codepage or what so ever
- From: Michael Rickmann <mrickma gwdg de>
- To: Ekiga development mailing list <ekiga-devel-list gnome org>
- Subject: Re: [Ekiga-devel-list] Win32 UTF-8 vs. Codepage or what so ever
- Date: Tue, 21 Jul 2009 17:32:22 +0200
Am Samstag, den 18.07.2009, 21:54 +0200 schrieb Eugen Dedu:
> Michael Rickmann wrote:
> > Ekiga's handling of Windows file names and device names is done mostly
> > in UTF-8 which works as long as there are no national characters in the
> > names. I have a German Windows and a USB headset which in Ekiga shows up
> > as "USB-Ger" instead of "USB-Gerät" (USB device). Ok, I can click
> > Ekiga's update devices and then there is a "USB-Gerät" which I can
> > select thanks to the g_locale_to_utf8 support in
> > ekiga/lib/gui/gmpreferences.c. However, the next time Ekiga is started
> > it complains because it is unable to open the "USB-Ger".
>
> Hi Michael,
>
> Until one month ago, linux usb subsystem have gotten the device name,
> translated it from utf-16 to latin-1 and give device names as latin-1 to
> applications.
>
> The
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a853a3d4eb2edb066248a39f0634f6f5858816a0
> commit changes that, so starting with 2.6.31 my ekiga patch should be
> removed (or make #ifdef linuxversion <= 2.6.30...)
>
Hi Eugen,
I rechecked what I had done before and found that your patch with the
lib/engine/components/ptlib/utils.cpp and other files indeed works for
WIN32 as well, if you use g_locale_to_utf8 and g_locale_from_utf8. I
must have done some thing wrong the first time I tried. So my new second
patch even simplifies the code, it is tested for head and stable.
> In the original ubuntu bug report, someone with such a camera and under
> windows had no problem. In fact, I was told that windows gives device
> names already in utf-8.
>
> If I understand you correctly, this is not the case for you?!
That would make it really complicated then Windows would sometimes do
and sometimes not. Take the entry in ekiga.conf (WIN32 database)
<default>USB-Audiogerät (PTLIB/WindowsMultimedia)</default>
This is under a german XP - Win7 is slightly different but also contains
the ...gerät. This is Window's description for a generic USB audio
device. So the problem is not in the string returned by the device but
in Window's wording around it. And above is how Ekiga should handle it.
Without attached patch the string would get truncated to:
<default>USB-Audioger</default>.
Ptlib will never find it.
>
> > I tried a similar approach as Eugen did when fixing bug #575907 (git
> > c9aedde44825, 2009-04-21). But similar changes at the level of
> > lib/components/ptlib device managers using g_locale_to_utf8 and back
> > would not work for Windows. Presumably some library calls have been in
> > between. For Win32 Ekiga the separation of (UTF-8) vs. (Codepage) with
See above, I have been wrong here, it works!
> > respect to Ptlib's device names is
> > (GUI + gconf) vs. (C-library + device strings).
>
> In linux, it's the same to my knowledge.
Good to know, though I think that quite a lot locales for which the
C-library is generated are UTF-8.
>
> I think that in ekiga storing in locale in gconf entries was a very old
> code, which should now be removed, is that right (your third patch)?
>
I think that for Windows gconf entries were always stored as UTF-8. That
is what the database we use was made for. As the code is used when you
press the update button it should use device names freshly read from
ptlib. I interpret it as a punctual attempt to get things right. Without
my patch it is the only place where localized devices show up in
Windows. When the conversion has been done already as it has been done
for Linux and should be done for Windows, this code messes up special
characters and it should be removed
> > A good place to convert the device strings to UTF-8 is
> > gm_prefs_window_convert_string_list in ekiga/src/gui/preferences.cpp.
> > Conversion from UTF-8 can only be done where we know that it is a device
> > string, i. e. in the device gmconf-bridges. I have prepared three
> > patches and tested them under Windows and for adverse effects also Linux.
Still good places but leads to bulky code.
> >
> > ekiga01_filename.diff is not so important but easy. It allows special
> > characters in the sound files. It shows the principle of converting from
> > UTF-8, i.e having a specialized routine in lib/gmconf/gmconf-glib.c
> > which is called for WIN32 from audiooutput-gmconf-bridge.cpp.
Still a wish of mine, code is not too unelegant.
>
> > ekiga02_devstring.diff involves quite a few files. It does the device
> > string conversions summarized above.
Has been superseeded by ekiga02_codepage.diff now.
> >
> > ekiga03_isutf8.diff cleans up ekiga/lib/gui/gmpreferences.c. Linux is
> > completely UTF-8 and for Win32 we have done the conversion to UTF-8 with
> > the second patch earlier. Moreover double conversion to UTF-8 does not
> > work when there are any special characters.
Should be definetly applied to remove old code.
Michael
diff -ur ekiga-3.2.5.orig/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp
--- ekiga-3.2.5.orig/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp 2009-07-20 18:05:23.000000000 +0200
+++ ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp 2009-07-20 18:10:22.000000000 +0200
@@ -77,12 +77,9 @@
for (PINDEX j = 0; devices_array[j] != NULL; j++) {
-#ifdef WIN32
- device.name = devices_array[j];
-#else
- // linux USB subsystem uses latin-1 encoding, while ekiga uses utf-8
+ /* linux USB subsystem uses latin-1 encoding, Windows codepage,
+ while ekiga uses utf-8 */
device.name = latin2utf (devices_array[j]);
-#endif
devices.push_back(device);
}
free (devices_array);
@@ -113,11 +110,7 @@
current_state.bits_per_sample = bits_per_sample;
input_device = PSoundChannel::CreateOpenedChannel (current_state.device.source,
-#ifdef WIN32
- current_state.device.name,
-#else
- utf2latin (current_state.device.name), // reencode back to latin-1
-#endif
+ utf2latin (current_state.device.name), // reencode back to latin-1 or codepage
PSoundChannel::Recorder,
channels,
samplerate,
diff -ur ekiga-3.2.5.orig/lib/engine/components/ptlib/audiooutput-manager-ptlib.cpp ekiga-3.2.5/lib/engine/components/ptlib/audiooutput-manager-ptlib.cpp
--- ekiga-3.2.5.orig/lib/engine/components/ptlib/audiooutput-manager-ptlib.cpp 2009-07-20 18:05:23.000000000 +0200
+++ ekiga-3.2.5/lib/engine/components/ptlib/audiooutput-manager-ptlib.cpp 2009-07-20 18:09:52.000000000 +0200
@@ -77,12 +77,9 @@
for (PINDEX j = 0; devices_array[j] != NULL; j++) {
-#ifdef WIN32
- device.name = devices_array[j];
-#else
- // linux USB subsystem uses latin-1 encoding, while ekiga uses utf-8
+ /* linux USB subsystem uses latin-1 encoding, Windows codepage,
+ while ekiga uses utf-8 */
device.name = latin2utf (devices_array[j]);
-#endif
devices.push_back(device);
}
free (devices_array);
@@ -113,11 +110,7 @@
current_state[ps].bits_per_sample = bits_per_sample;
output_device[ps] = PSoundChannel::CreateOpenedChannel (current_state[ps].device.source,
-#ifdef WIN32
- current_state[ps].device.name,
-#else
- utf2latin (current_state[ps].device.name), // reencode back to latin-1
-#endif
+ utf2latin (current_state[ps].device.name), // reencode back to latin-1 or codepage
PSoundChannel::Player,
channels,
samplerate,
diff -ur ekiga-3.2.5.orig/lib/engine/components/ptlib/utils.cpp ekiga-3.2.5/lib/engine/components/ptlib/utils.cpp
--- ekiga-3.2.5.orig/lib/engine/components/ptlib/utils.cpp 2009-07-20 18:05:23.000000000 +0200
+++ ekiga-3.2.5/lib/engine/components/ptlib/utils.cpp 2009-07-20 18:12:01.000000000 +0200
@@ -43,10 +43,14 @@
{
gchar *utf8_str;
std::string result;
-
+#ifdef WIN32
+ utf8_str = g_locale_to_utf8 (str.c_str (), -1,
+ NULL, NULL, NULL);
+#else
utf8_str = g_convert (str.c_str (), -1,
"UTF-8", "ISO-8859-1",
NULL, NULL, NULL);
+#endif
result = std::string (utf8_str);
g_free (utf8_str);
return result;
@@ -60,9 +64,14 @@
std::string result;
g_warn_if_fail (g_utf8_validate (str.c_str (), -1, NULL));
+#ifdef WIN32
+ latin_str = g_locale_from_utf8 (str.c_str (), -1,
+ NULL, NULL, NULL);
+#else
latin_str = g_convert (str.c_str (), -1,
"ISO-8859-1", "UTF-8",
NULL, NULL, NULL);
+#endif
result = std::string (latin_str);
g_free (latin_str);
return result;
diff -ur ekiga-3.2.5.orig/lib/engine/components/ptlib/videoinput-manager-ptlib.cpp ekiga-3.2.5/lib/engine/components/ptlib/videoinput-manager-ptlib.cpp
--- ekiga-3.2.5.orig/lib/engine/components/ptlib/videoinput-manager-ptlib.cpp 2009-07-20 18:05:23.000000000 +0200
+++ ekiga-3.2.5/lib/engine/components/ptlib/videoinput-manager-ptlib.cpp 2009-07-20 18:11:22.000000000 +0200
@@ -79,12 +79,9 @@
for (PINDEX j = 0; devices_array[j] != NULL; j++) {
-#ifdef WIN32
- device.name = devices_array[j];
-#else
- // linux USB subsystem uses latin-1 encoding, while ekiga uses utf-8
+ /* linux USB subsystem uses latin-1 encoding, Windows codepage,
+ while ekiga uses utf-8 */
device.name = latin2utf (devices_array[j]);
-#endif
devices.push_back(device);
}
free (devices_array);
@@ -120,11 +117,7 @@
expectedFrameSize = (width * height * 3) >> 1;
pvideo_format = (PVideoDevice::VideoFormat)current_state.format;
-#ifdef WIN32
- input_device = PVideoInputDevice::CreateOpenedDevice (current_state.device.source, current_state.device.name, FALSE);
-#else
- input_device = PVideoInputDevice::CreateOpenedDevice (current_state.device.source, utf2latin (current_state.device.name), FALSE); // reencode back to latin-1
-#endif
+ input_device = PVideoInputDevice::CreateOpenedDevice (current_state.device.source, utf2latin (current_state.device.name), FALSE); // reencode back to latin-1 or codepage
Ekiga::VideoInputErrorCodes error_code = Ekiga::VI_ERROR_NONE;
if (!input_device)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
