[gtkmm] Gtkmm-forge digest, Vol 1 #255 - 4 msgs

[gtkmm-forge-request lists sourceforge net]

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 95651] Changed - radiobuttons' get_group and set_group don't match (bugzilla-daemon widget gnome org)
   2. [Bug 95651] Changed - radiobuttons' get_group and set_group don't match (bugzilla-daemon widget gnome org)
   3. [Bug 93787] Changed - Outputting ustring with operator << converts implicitly (bugzilla-daemon widget gnome org)
   4. [Bug 95651] Changed - radiobuttons' get_group and set_group don't match (bugzilla-daemon widget gnome org)

--__--__--

Message: 1
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, jpakkane yahoo com
Cc: 
Date: Mon, 14 Oct 2002 08:50:50 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 95651] Changed - radiobuttons' get_group and set_group don't match

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=95651

Changed by murrayc usa net 

--- shadow/95651	Sun Oct 13 09:15:12 2002
+++ shadow/95651.tmp.8937	Mon Oct 14 08:50:50 2002
@@ -57,6 +57,12 @@
 2. add a new function to radiobuttons, such as
 same_group_as(Gtk::Rediobutton &rb)
 3. explicitly say in the docs that you need your own Group object
 
 I liked the way this worked in GTKMM 1.2. You could assign buttons to
 same groups without having to fiddle with Radiobutton_Helpers.
+
+------- Additional Comments From murrayc usa net  2002-10-14 08:50 -------
+It's not ideal, but there was some reason for the change - you might
+look in the ChangeLog for an explanation.
+
+The documentation doesn't sound incorrect.



--__--__--

Message: 2
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 14 Oct 2002 09:39:03 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 95651] Changed - radiobuttons' get_group and set_group don't match

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=95651

Changed by jpakkane yahoo com 

--- shadow/95651	Mon Oct 14 08:50:50 2002
+++ shadow/95651.tmp.18252	Mon Oct 14 09:39:03 2002
@@ -63,6 +63,21 @@
 
 ------- Additional Comments From murrayc usa net  2002-10-14 08:50 -------
 It's not ideal, but there was some reason for the change - you might
 look in the ChangeLog for an explanation.
 
 The documentation doesn't sound incorrect.
+
+------- Additional Comments From jpakkane yahoo com  2002-10-14 09:39 -------
+I looked at the changelog and it seems to be some hairy gtk/glib thing.
+
+There's nothing actually incorrect with the documentation. It just
+doesn't tell the whole story. This is bad for people who read the
+reference documentation but don't read the examples thoroughly (such
+as me).
+
+The documentation only needs a small change. Possibly something like
+this (change is for the clip above):
+
+" ... RadioButton in a group, use get_group() to store the group to a
+Radiobutton_Helpers::Group object. Then you provide this Group object
+to the constructors ..."



--__--__--

Message: 3
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 14 Oct 2002 11:09:38 -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 Oct 12 17:12:29 2002
+++ shadow/93787.tmp.4461	Mon Oct 14 11:09:38 2002
@@ -338,6 +338,75 @@
 
 Convinced? ;)
 
 Cheers,
 --Daniel
 
+
+------- Additional Comments From olau hardworking dk  2002-10-14 11:09 -------
+Regarding the filenames: I apologise, but the reason I didn't
+comment on that is that I didn't quite understand the problem
+- I still don't. :-)
+
+Does the situation change? If you're relying on using
+std::strings from Gtkmm file names together with ustrings,
+your program is buggy, right? Since you will create invalid
+ustrings if G_BROKEN_FILENAMES is set? And noone ever check
+that, do they? I've never heard of this problem before now.
+
+Unless there's more to it, it sounds like a separate issue
+that should either be fixed by adding documentation or by
+shielding users of Gtkmm from it by replacing std::string with
+ustring and automatically converting to UTF-8 if
+G_BROKEN_FILENAMES is set.
+
+
+You're somewhat right about reading from a standard (e.g.
+file) stream - but you wouldn't go through std::string, would
+you? The members return char *'s - so by default interpret
+these as locale-encoded, unless you explicitly say what
+encoding to use with e.g. a "ustring from_raw(char *)" helper.
+
+It's true that this is more work than it is now, but OTOH lazy
+coding still works; only if it's important to output UTF-8 is
+it necessary to think a little.
+
+About the generic string operations - is this a big problem? I
+myself have 1-2 I use regularly, and it's no big deal to
+templatize them if they really need to work on both
+std::string and ustring (this also works for all string
+algorithms, not just those that don't examine individual
+characters):
+
+  template <String> String strip(const String &s);
+
+If you don't have access to source code, there's always a
+"std::string raw()" method in ustring. I don't want to ban
+other std::string encodings, just change the default
+assumption of Gtkmm.
+
+
+I don't quite understand what you write about streams not
+having a locale assigned by default. Are you saying that my
+point is wrong from the Standard point of view, but right from
+the practical point of view? If so, the point, though not the
+wording, is still valid, isn't it?
+
+
+I'm trying to understand what you're saying about banning the
+implicit conversions of ustring to std::string and std::string
+to ustring. If I get your point, the problem is that you might
+change the encoding to UTF-8 with IConv::convert but still get
+a std::string. But then you could just pass it through a
+"ustring from_raw(std::string)" that didn't perform any
+conversions except from changing the type of the C++ object,
+couldn't you?
+
+
+I personally like the implicit locale-encoded std::strings
+best since it changes the current behaviour least, except for
+when you're interacting with the outside (as with file I/O). I
+have a feeling that banning implicit conversions may change
+quite a lot more.
+
+Have I missed any points?
+



--__--__--

Message: 4
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, jpakkane yahoo com
Cc: 
Date: Mon, 14 Oct 2002 14:22:07 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 95651] Changed - radiobuttons' get_group and set_group don't match

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=95651

Changed by murrayc usa net 

--- shadow/95651	Mon Oct 14 09:39:03 2002
+++ shadow/95651.tmp.11866	Mon Oct 14 14:22:07 2002
@@ -1,13 +1,13 @@
 Bug#: 95651
 Product: gtkmm
 Version: 2.0
 OS: All
 OS Details: Debian Woody, testing
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: NOTABUG
 Severity: normal
 Priority: Normal
 Component: general
 AssignedTo: gtkmm-forge lists sourceforge net                            
 ReportedBy: jpakkane yahoo com               
 TargetMilestone: ---
@@ -78,6 +78,14 @@
 The documentation only needs a small change. Possibly something like
 this (change is for the clip above):
 
 " ... RadioButton in a group, use get_group() to store the group to a
 Radiobutton_Helpers::Group object. Then you provide this Group object
 to the constructors ..."
+
+------- Additional Comments From murrayc usa net  2002-10-14 14:22 -------
+Yes, we just wrap the GTK+ behaviour as best we can.
+
+Actually, RadioButton::Group is fine, and more obvious.
+
+I just corrected the book chapter on RadioButtons (not yet online -
+it's  in CVS) but feel free to add to the reference documentation too.




--__--__--

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


End of Gtkmm-forge Digest