GNOME.org
 

[gtkmm] Gtkmm-forge digest, Vol 1 #254 - 7 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 95606] Changed - Warning when removing child Gtk::VSeparator (bugzilla-daemon widget gnome org)
   3. [Bug 95606] Changed - Warning when removing child Gtk::VSeparator (bugzilla-daemon widget gnome org)
   4. [Bug 95606] Changed - Warning when removing child Gtk::VSeparator (bugzilla-daemon widget gnome org)
   5. [Bug 95651] New - radiobuttons' get_group and set_group don't match (bugzilla-daemon widget gnome org)
   6. [Bug 95651] Changed - radiobuttons' get_group and set_group don't match (bugzilla-daemon widget gnome org)
   7. [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, olau hardworking dk
Cc: 
Date: Sat, 12 Oct 2002 17:12:30 -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 Oct 12 11:20:08 2002
+++ shadow/93787.tmp.1415	Sat Oct 12 17:12:29 2002
@@ -287,6 +287,57 @@
 
 
 If I've not managed to convince you, I think it would be better to
 remove the implicit std::string conversion completely and introduce
 something like string_from_utf8 and string_from_locale instead. This
 would at least force one to think about the issue.
+
+------- Additional Comments From daniel elstner gmx net  2002-10-12 17:12 -------
+No, you didn't manage to convince me ;)
+
+You completely ignored my filenames example.  Even if I would agree
+with all your other points this would still be a show stopper.
+
+Regarding the use of std::string for UTF-8 strings:  This is a) often
+absolutely unavoidable e.g. when reading from a standard stream
+without using operator>>() (which isn't approriate most of the time).
+ And b) it's useful for optimization purposes.  A lot of generic
+string operations work just fine with UTF-8 since it was designed to
+be as compatible as possible.
+
+Further:
+"Thing is, you can't convert much to a string without going through a
+stringstream. So in effect the standard already does enforce a
+particular encoding on strings [...]"
+
+This is actually not true.  A stream doesn't have a locale assigned by
+default.  The reasons why I decided to convert to the current locale
+in operator<<() are a) because libstdc++-v2 (the one delivered with
+gcc-2.95.x) is broken and uses the current C locale for all streams.
+And b) even if you have proper locale support (as in libstdc++-v3)
+there's no portable way to say "use the current locale but replace its
+charset with UTF-8".  Which means you kinda have to use the charset
+dictated by the current locale in i18nized apps.
+
+Next point: "If I've not managed to convince you, I think it would be
+better to remove the implicit std::string conversion completely and
+introduce something like string_from_utf8 and string_from_locale
+instead. This would at least force one to think about the issue."
+
+While forcing users to think about the issue would be nice, we just
+can't do that.  There are several places in the gtkmm API where the
+compiler cannot know the encoding of a string but the programmer can.
+ Take Glib::convert() for instance.  It's using std::string as
+arguments because the encoding is *unknown* to the compiler, even
+though the programmer might know it.
+
+Now one could argue "why don't you use Glib::locale_{to,from}_utf8()
+instead".  Well, because I might want to acquire a persistent
+Glib::IConv handle and use Glib::IConv::convert().  Even if I use it
+only to convert to/from UTF-8 it has to support arbitrary conversions
+as well.
+
+Convinced? ;)
+
+Cheers,
+--Daniel
+



--__--__--

Message: 2
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sat, 12 Oct 2002 17:38:31 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 95606] Changed - Warning when removing child Gtk::VSeparator

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

Changed by murrayc usa net 

--- shadow/95606	Sat Oct 12 09:51:53 2002
+++ shadow/95606.tmp.5832	Sat Oct 12 17:38:31 2002
@@ -9,13 +9,13 @@
 Priority: Normal
 Component: general
 AssignedTo: gtkmm-forge lists sourceforge net                            
 ReportedBy: matty chariot net au               
 TargetMilestone: ---
 URL: 
-Summary: Warning and crash when removing and readding widgets.
+Summary: Warning when removing child Gtk::VSeparator
 
 I get the following warning on my code:
 
 Gtk-CRITICAL **: file gtkcontainer.c: line 878 (gtk_container_remove):
 assertion `GTK_IS_CONTAINER (container)' failed
 
@@ -82,6 +82,11 @@
 You could probably remove button and box, these are primarily used to
 perform the removal action.  However, you'd need some alternate means
 of triggering the removal action, like on a timer or close event.
 
 danielk suggested attempting to remove sep from frame before deletion,
 and this seems to work OK as a workaround.
+
+------- Additional Comments From murrayc usa net  2002-10-12 17:38 -------
+Here is a simplified version of the test code. I noticed that the
+problem happens with a child VSeparator, but not with a child Button,
+so it doesn't seem to be a general lifetime problem.



--__--__--

Message: 3
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sat, 12 Oct 2002 17:39:38 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 95606] Changed - Warning when removing child Gtk::VSeparator

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

Changed by murrayc usa net 

--- shadow/95606	Sat Oct 12 17:38:31 2002
+++ shadow/95606.tmp.6032	Sat Oct 12 17:39:38 2002
@@ -87,6 +87,11 @@
 and this seems to work OK as a workaround.
 
 ------- Additional Comments From murrayc usa net  2002-10-12 17:38 -------
 Here is a simplified version of the test code. I noticed that the
 problem happens with a child VSeparator, but not with a child Button,
 so it doesn't seem to be a general lifetime problem.
+
+------- Additional Comments From murrayc usa net  2002-10-12 17:39 -------
+Created an attachment (id=11514)
+test_child_separator.cc
+



--__--__--

Message: 4
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sat, 12 Oct 2002 17:40:41 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 95606] Changed - Warning when removing child Gtk::VSeparator

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

Changed by murrayc usa net 

--- shadow/95606	Sat Oct 12 17:39:38 2002
+++ shadow/95606.tmp.6345	Sat Oct 12 17:40:41 2002
@@ -92,6 +92,9 @@
 so it doesn't seem to be a general lifetime problem.
 
 ------- Additional Comments From murrayc usa net  2002-10-12 17:39 -------
 Created an attachment (id=11514)
 test_child_separator.cc
 
+
+------- Additional Comments From murrayc usa net  2002-10-12 17:40 -------
+Actually, it's  an HSeparator, but I doubt that it makes any difference.



--__--__--

Message: 5
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sat, 12 Oct 2002 21:44:07 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 95651] New - 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	Sat Oct 12 21:44:07 2002
+++ shadow/95651.tmp.14004	Sat Oct 12 21:44:07 2002
@@ -0,0 +1,35 @@
+Bug#: 95651
+Product: gtkmm
+Version: 2.0
+OS: All
+OS Details: Debian Woody, testing
+Status: NEW   
+Resolution: 
+Severity: normal
+Priority: Normal
+Component: general
+AssignedTo: gtkmm-forge lists sourceforge net                            
+ReportedBy: jpakkane yahoo com               
+TargetMilestone: ---
+URL: 
+Summary: radiobuttons' get_group and set_group don't match
+
+Currently radiobuttons' get_group method is defined like this:
+
+Group get_group ();
+
+However, group assigning functions expect a reference to the group, not the
+group itself. Currently you can't do this:
+
+rb1.set_group(rb2.get_group());
+
+They lead to this error:
+
+from rvalue of type `Gtk::RadioButton_Helpers::Group'
+/usr/include/gtkmm-2.0/gtkmm/radiobutton.h:158: in passing argument 1 of
+`Gtk::RadioButton::set_group(Gtk::RadioButton_Helpers::Group &)'
+
+Radiobutton's documentation says that this should be possible, but the
+current implementation seems not to allow this.
+
+GTKMM 1.2 did not use references as arguments.



--__--__--

Message: 6
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, jpakkane yahoo com
Cc: 
Date: Sun, 13 Oct 2002 06:41:31 -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	Sat Oct 12 21:44:07 2002
+++ shadow/95651.tmp.26480	Sun Oct 13 06:41:31 2002
@@ -30,6 +30,10 @@
 `Gtk::RadioButton::set_group(Gtk::RadioButton_Helpers::Group &)'
 
 Radiobutton's documentation says that this should be possible, but the
 current implementation seems not to allow this.
 
 GTKMM 1.2 did not use references as arguments.
+
+------- Additional Comments From murrayc usa net  2002-10-13 06:41 -------
+I think that this is just how it is. Please tell us what part of the
+documentation needs to be corrected, or provide a patch.



--__--__--

Message: 7
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Sun, 13 Oct 2002 09:15:12 -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	Sun Oct 13 06:41:31 2002
+++ shadow/95651.tmp.20235	Sun Oct 13 09:15:12 2002
@@ -34,6 +34,29 @@
 
 GTKMM 1.2 did not use references as arguments.
 
 ------- Additional Comments From murrayc usa net  2002-10-13 06:41 -------
 I think that this is just how it is. Please tell us what part of the
 documentation needs to be corrected, or provide a patch.
+
+------- Additional Comments From jpakkane yahoo com  2002-10-13 09:15 -------
+The radiobuttons' doc I used was this:
+
+http://gtkmm.sourceforge.net/gtkmm2/reference/html/classGtk_1_1RadioButton.html
+
+It says: "After constructing the first RadioButton in a group, use
+get_group() and provide this Group to the constructors ot the other
+RadioButtons in the same group." You can't do this directly because it
+returns an object and the constructor wants a reference. Instead you
+have to declare your own RadioButton_Helpers::Group object and give
+that as an argument to all radio buttons.
+
+I can think of three ways to fix this (in decreasing order of personal
+preference):
+
+1. make get_group return a reference
+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.




--__--__--

_______________________________________________
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]