GNOME.org
 

[gtkmm] Gtkmm-forge digest, Vol 1 #235 - 10 msgs

Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-admin lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  A daily digest is sent to gtkmm-main, to encourage people to help fixing the bugs.


Today's Topics:

   1. [Bug 93787] Changed - Outputting ustring with operator << converts implicitly (bugzilla-daemon widget gnome org)
   2. [Bug 93694] Changed - Glib::Dispatcher and arbitrary MainContext (bugzilla-daemon widget gnome org)
   3. [Bug 93787] Changed - Outputting ustring with operator << converts implicitly (bugzilla-daemon widget gnome org)
   4. [Bug 93787] Changed - Outputting ustring with operator << converts implicitly (bugzilla-daemon widget gnome org)
   5. [Bug 93787] Changed - Outputting ustring with operator << converts implicitly (bugzilla-daemon widget gnome org)
   6. [Bug 93787] Changed - Outputting ustring with operator << converts implicitly (bugzilla-daemon widget gnome org)
   7. [Bug 93787] Changed - Outputting ustring with operator << converts implicitly (bugzilla-daemon widget gnome org)
   8. [Bug 93694] Changed - Glib::Dispatcher and arbitrary MainContext (bugzilla-daemon widget gnome org)
   9. [Bug 93787] Changed - Outputting ustring with operator << converts implicitly (bugzilla-daemon widget gnome org)
  10. [Bug 93694] Changed - Glib::Dispatcher and arbitrary MainContext (bugzilla-daemon widget gnome org)

--__--__--

Message: 1
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, olau hardworking dk
Cc: 
Date: Sat, 21 Sep 2002 15:27:14 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93787] Changed - Outputting ustring with operator << converts implicitly

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93787

Changed by daniel elstner gmx net 

--- shadow/93787	Sat Sep 21 14:45:25 2002
+++ shadow/93787.tmp.7696	Sat Sep 21 15:27:14 2002
@@ -54,6 +54,41 @@
 operator <<. I've changed the subject line to match this.
 
 IMHO this is too clever. Another scenario where this might silently
 break things is outputting to files. What about refrain from doing the
 conversion and instead emphasizing that output to console must be
 converted?
+
+------- Additional Comments From daniel elstner gmx net  2002-09-21 15:27 -------
+Yes, I wasn't entirely happy with it either -- but it seemed to be the
+sanest solution.  The original implementation of operator<< for
+Glib::ustring actually did the conversion for cout/cerr/clog only. 
+Apart from being even more confusing it causes trouble with string
+streams. If you do:
+
+out << 123 << ustring;
+
+then the stream converts the locale's string representation of 123
+into an encoding that isn't necessarily UTF-8.  For libstdc++-v2 with
+setlocale() called, that will always be the locale's encoding.  This
+behaviour is broken -- libstdc++-v3 does it right and allows you to
+setup a global default std::locale object, and you can also assign a
+different locale setting to single streams.
+
+But even then you're lost because it's impossible to retrieve the name
+of the encoding the stream is using (if there should be a way I've
+overlooked please tell me!).  Since the most probable stream encoding
+is the locale's default encoding, I decided to always do the conversion.
+
+Yes, file output is an issue.  I'm using ustring::raw() in my programs
+to make clear I want to write the raw data, i.e. UTF-8 to the stream.
+ I understand this isn't pleasant either -- both ways seem to be
+flawed somehow.
+
+It's almost unbelievable:  the darn std::locale concept is immensely
+powerful and allows stuff I'm never going to use -- but simply
+retrieving a stream's encoding doesn't seem possible :(
+
+Any ideas?
+
+--Daniel
+



--__--__--

Message: 2
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, puchs ap univie ac at
Cc: 
Date: Sat, 21 Sep 2002 15:55:37 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93694] Changed - Glib::Dispatcher and arbitrary MainContext

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93694

Changed by daniel elstner gmx net 

--- shadow/93694	Sat Sep 21 07:55:54 2002
+++ shadow/93694.tmp.11194	Sat Sep 21 15:55:37 2002
@@ -81,6 +81,17 @@
 I just applied your first patch with some modifications (mostly
 reducing code duplication).  Thanks.  I'm going to look at your
 example now.
 
 Erm, try cvs update -Pd to get new directories.
 
+
+------- Additional Comments From daniel elstner gmx net  2002-09-21 15:55 -------
+OK, the example is in CVS now.  Thanks for your work.
+
+There were some memory visibility problems in the code which I
+(hopefully) fixed, apart from a few stylistic issues.  Could you
+please have a look at my changes in case I did something that wasn't
+intended?
+
+--Daniel
+



--__--__--

Message: 3
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sat, 21 Sep 2002 16:22:53 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93787] Changed - Outputting ustring with operator << converts implicitly

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93787

Changed by olau hardworking dk 

--- shadow/93787	Sat Sep 21 15:27:14 2002
+++ shadow/93787.tmp.28045	Sat Sep 21 16:22:53 2002
@@ -89,6 +89,26 @@
 retrieving a stream's encoding doesn't seem possible :(
 
 Any ideas?
 
 --Daniel
 
+
+------- Additional Comments From olau hardworking dk  2002-09-21 16:22 -------
+Ah, I see. I wasn't aware of the stringstream conversion of numbers,
+though it somehow makes sense once you think about it. I guess this
+leaves one with two possibilities:
+
+ 1. Construct ASCII or UTF-8 stringstreams and change the operator <<
+to never convert the output.
+
+ 2. Do all character manipulation involving streams with the locale's
+encoding and convert back using locale_to_utf8.
+
+My version of The C++ Programming Language didn't have the extra
+appendix with information about std::locale. Is it easy to construct
+streams in the C locale? If so, I think that's the cleanest solution.
+Perhaps it would even be possible to provide a few typedefs/templates
+such as Glib::ustringstream?
+
+In any case, it probably needs to be mentioned somewhere that ordinary
+stringstreams are incompatible with Glibmm, unlike std::string.



--__--__--

Message: 4
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sat, 21 Sep 2002 16:34:26 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93787] Changed - Outputting ustring with operator << converts implicitly

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93787

Changed by olau hardworking dk 

--- shadow/93787	Sat Sep 21 16:22:53 2002
+++ shadow/93787.tmp.29469	Sat Sep 21 16:34:26 2002
@@ -109,6 +109,10 @@
 streams in the C locale? If so, I think that's the cleanest solution.
 Perhaps it would even be possible to provide a few typedefs/templates
 such as Glib::ustringstream?
 
 In any case, it probably needs to be mentioned somewhere that ordinary
 stringstreams are incompatible with Glibmm, unlike std::string.
+
+------- Additional Comments From olau hardworking dk  2002-09-21 16:34 -------
+Oops, a C locale isn't good enough. Then floats wouldn't be localized.
+Question is whether it is possible to simply set the encoding to UTF-8?



--__--__--

Message: 5
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, olau hardworking dk
Cc: 
Date: Sat, 21 Sep 2002 16:50:00 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93787] Changed - Outputting ustring with operator << converts implicitly

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93787

Changed by daniel elstner gmx net 

--- shadow/93787	Sat Sep 21 16:34:26 2002
+++ shadow/93787.tmp.31285	Sat Sep 21 16:50:00 2002
@@ -113,6 +113,27 @@
 In any case, it probably needs to be mentioned somewhere that ordinary
 stringstreams are incompatible with Glibmm, unlike std::string.
 
 ------- Additional Comments From olau hardworking dk  2002-09-21 16:34 -------
 Oops, a C locale isn't good enough. Then floats wouldn't be localized.
 Question is whether it is possible to simply set the encoding to UTF-8?
+
+------- Additional Comments From daniel elstner gmx net  2002-09-21 16:49 -------
+Creating streams with an arbitrary locale object is easy, just do:
+
+stream.imbue(std::locale("C"));
+
+but that's not the issue.  You can't use a C locale stream because
+then you'd lose any i18n functionality.  Apart from decimal point
+differences in Western countries, an exotic language's numbers might
+not even be representable in ASCII.  I think this applies to some
+Arabian countries -- although they're using the decimal system (which
+they invented ;) the digits look different.
+
+So you've to go for option 2 -- at least until everyone has switched
+to a UTF-8 locale (which I've already done, by the way ;)
+
+What exactly do you mean by "ordinary stringstreams are incompatible
+with Glibmm"?  If we continue using option 2 (as gtkmm does now) you
+just have to pay attention to convert strstream.str() to UTF-8 before
+assigning the data to a ustring.  Did you mean just that or something
+else?



--__--__--

Message: 6
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, olau hardworking dk
Cc: 
Date: Sat, 21 Sep 2002 16:57:28 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93787] Changed - Outputting ustring with operator << converts implicitly

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93787

Changed by daniel elstner gmx net 

--- shadow/93787	Sat Sep 21 16:50:00 2002
+++ shadow/93787.tmp.32301	Sat Sep 21 16:57:28 2002
@@ -134,6 +134,23 @@
 
 What exactly do you mean by "ordinary stringstreams are incompatible
 with Glibmm"?  If we continue using option 2 (as gtkmm does now) you
 just have to pay attention to convert strstream.str() to UTF-8 before
 assigning the data to a ustring.  Did you mean just that or something
 else?
+
+------- Additional Comments From daniel elstner gmx net  2002-09-21 16:57 -------
+Mid-air collision ;)
+
+You can set the encoding to UTF-8 by doing e.g.:
+
+stream.imbue(std::locale("de_DE.UTF-8"));
+
+It's also possible to change the LC_CTYPE category only.  But as you
+can see from the example, you've to know a complete locale name which
+also has to actually *exist* on the system.  Even if you assume Linux,
+there are distros (e.g. Debian) that only generate the locales
+explicitely requested by the user.
+
+Probably even worse is that libstdc++-v2 doesn't support std::locale.
+ Which in practice means your code will require g++ 3.0 or newer.
+



--__--__--

Message: 7
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, olau hardworking dk
Cc: 
Date: Sat, 21 Sep 2002 17:18:27 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93787] Changed - Outputting ustring with operator << converts implicitly

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93787

Changed by daniel elstner gmx net 

--- shadow/93787	Sat Sep 21 16:57:28 2002
+++ shadow/93787.tmp.2403	Sat Sep 21 17:18:27 2002
@@ -151,6 +151,16 @@
 there are distros (e.g. Debian) that only generate the locales
 explicitely requested by the user.
 
 Probably even worse is that libstdc++-v2 doesn't support std::locale.
  Which in practice means your code will require g++ 3.0 or newer.
 
+
+------- Additional Comments From daniel elstner gmx net  2002-09-21 17:18 -------
+I just realized that it might be possible to detect a stream's
+encoding by retrieving the locale name, temporarily switching to this
+locale via setlocale(), and then calling nl_langinfo() to get the charset.
+
+That would only work on Unix with libstdc++-v3 though, and it doesn't
+solve the problem that the string returned by stringstream::str() is
+most probably not UTF-8.  Darn!
+



--__--__--

Message: 8
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sat, 21 Sep 2002 17:50:45 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93694] Changed - Glib::Dispatcher and arbitrary MainContext

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93694

Changed by puchs ap univie ac at 

--- shadow/93694	Sat Sep 21 15:55:37 2002
+++ shadow/93694.tmp.6210	Sat Sep 21 17:50:45 2002
@@ -92,6 +92,18 @@
 (hopefully) fixed, apart from a few stylistic issues.  Could you
 please have a look at my changes in case I did something that wasn't
 intended?
 
 --Daniel
 
+
+------- Additional Comments From puchs ap univie ac at  2002-09-21 17:50 -------
+Hej Daniel!
+
+Everything you did is perfect! And don't thank me - I am the one who
+should be (and who is) grateful.You are all doing a great job! Thanks
+for incorporating the patch and the example. I did learn a few things
+from the way you fixed it.
+
+Thanks a lot! Danke schön!
+
+Stephan



--__--__--

Message: 9
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sun, 22 Sep 2002 06:00:28 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93787] Changed - Outputting ustring with operator << converts implicitly

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93787

Changed by olau hardworking dk 

--- shadow/93787	Sat Sep 21 17:18:27 2002
+++ shadow/93787.tmp.22537	Sun Sep 22 06:00:28 2002
@@ -161,6 +161,27 @@
 locale via setlocale(), and then calling nl_langinfo() to get the charset.
 
 That would only work on Unix with libstdc++-v3 though, and it doesn't
 solve the problem that the string returned by stringstream::str() is
 most probably not UTF-8.  Darn!
 
+
+------- Additional Comments From olau hardworking dk  2002-09-22 06:00 -------
+Yes, by incompatible I was thinking of the conversion issue. They are
+not directly compatible unless you remember converting the strings. 
+
+One way out of some of the mess would perhaps be to set forth a
+convention that all std::strings be in the locale's encoding with
+automatic conversions back and forth? With that approach, I wouldn't
+have encountered my problem, and I think the semantics are easier to
+remember and comprehend then.
+
+I don't think you can be sure that all characters will survive the
+conversion back and forth unaltered, though. But I can't see we can do
+anything about that in any case. Also, if the strings are localised
+using the same language, chances are the locale's encoding will
+support all characters.
+
+At least if you know that std::strings are supposed to be locale
+dependent, you know that you can't count not loosing data at all. A
+raw() method may still provide a unchanged string for e.g. files or
+verbatim keys, then.



--__--__--

Message: 10
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, puchs ap univie ac at
Cc: 
Date: Sun, 22 Sep 2002 09:58:37 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93694] Changed - Glib::Dispatcher and arbitrary MainContext

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=93694

Changed by daniel elstner gmx net 

--- shadow/93694	Sat Sep 21 17:50:45 2002
+++ shadow/93694.tmp.18923	Sun Sep 22 09:58:37 2002
@@ -1,13 +1,13 @@
 Bug#: 93694
 Product: gtkmm
 Version: 2.0
 OS: All
 OS Details: 
-Status: ASSIGNED   
-Resolution: 
+Status: RESOLVED   
+Resolution: FIXED
 Severity: enhancement
 Priority: Normal
 Component: general
 AssignedTo: gtkmm-forge lists sourceforge net                            
 ReportedBy: puchs ap univie ac at               
 TargetMilestone: ---
@@ -104,6 +104,9 @@
 for incorporating the patch and the example. I did learn a few things
 from the way you fixed it.
 
 Thanks a lot! Danke schön!
 
 Stephan
+
+------- Additional Comments From daniel elstner gmx net  2002-09-22 09:58 -------
+Heh, kein Problem ;)




--__--__--

_______________________________________________
Gtkmm-forge mailing list
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]