[gtkmm] Gtkmm-forge digest, Vol 1 #693 - 4 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. Do not try to unsubscribe gtkmm-forge from gtkmm-list.


Today's Topics:

   1. [Bug 109966]  - Dispatcher does not work on win32 (bugzilla-daemon bugzilla gnome org)
   2. [Bug 142138]  - Gtk::FileChooser::get_filename() should return std::string (bugzilla-daemon bugzilla gnome org)
   3. [Bug 142138]  - Gtk::FileChooser::get_filename() should return std::string (bugzilla-daemon bugzilla gnome org)
   4. [Bug 142138]  - Gtk::FileChooser::get_filename() should return std::string (bugzilla-daemon bugzilla gnome org)

--__--__--

Message: 1
From: bugzilla-daemon bugzilla gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 24 May 2004 09:36:46 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 109966]  - Dispatcher does not work on win32

http://bugzilla.gnome.org/show_bug.cgi?id=109966
glibmm | threads | Ver: 2.4.x





------- Additional Comments From cgustin ibelgique com  2004-05-24 09:36 -------
I tried the new dispatcher against the current glibmm CVS on win32 (mingw-gcc 
2.3.2). dispatcher.cc and the two dispatcher examples compile fine. The 
dispatcher2.exe example runs as expected. The other example (dispatcher.exe) 
crashes with a segmentation fault when the last (5th) thread reaches 100% 
(finished).

I'm investigating...

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


--__--__--

Message: 2
From: bugzilla-daemon bugzilla gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 24 May 2004 15:03:42 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 142138]  - Gtk::FileChooser::get_filename() should return std::string

http://bugzilla.gnome.org/show_bug.cgi?id=142138
gtkmm | general | Ver: 2.4





------- Additional Comments From chris cvine freeserve co uk  2004-05-24 15:03 -------
Gtk::FileChooser::get_filenames returns a container of Glib::ustring objects
(Glib::SListHandle<Glib::ustring>).  Should it in fact return a container of
std::string objects (as does Gtk::FileSelection::get_selection())?  It would be
awkward if Gtk::FileChooser::get_filename() returned std::string and
Gtk::FileChooser::get_filenames returned a container of Glib::ustring.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


--__--__--

Message: 3
From: bugzilla-daemon bugzilla gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 24 May 2004 18:45:16 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 142138]  - Gtk::FileChooser::get_filename() should return std::string

http://bugzilla.gnome.org/show_bug.cgi?id=142138
gtkmm | general | Ver: 2.4





------- Additional Comments From daniel elstner gmx net  2004-05-24 18:45 -------
Exactly, it should return a container of std::string just like the old
FileSelection did.  Unfortunately the GTK+ documentation is a bit vague on the
other FileChooser methods that return URIs or folder names etc.  I still have to
investigate those.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


--__--__--

Message: 4
From: bugzilla-daemon bugzilla gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 24 May 2004 18:51:23 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 142138]  - Gtk::FileChooser::get_filename() should return std::string

http://bugzilla.gnome.org/show_bug.cgi?id=142138
gtkmm | general | Ver: 2.4





------- Additional Comments From chris cvine freeserve co uk  2004-05-24 18:51 -------
For what it is worth, I see that gtk_file_chooser_get_filenames() derives its
return value from file_paths_to_strings(), and file_paths_to_strings() is passed
a pointer to function gtk_file_system_path_to_filename() as its third parameter.
 As its name suggests, gtk_file_system_path_to_filename() converts a GtkFilePath
object  to a gchar* string, but I do not know enough about the GTK+ internals to
know what codeset the resulting string is in.

gtk_file_chooser_get_filename() also calls gtk_file_system_path_to_filename() to
obtain its return value.  

As you say, it appears therefore that either both
Gtk::FileChooser::get_filename() and Gtk::FileChooser::get_filename()
incorrectly specify Glib::ustring as their return type/contained return type
(which appears to be the outcome), or both specify it correctly, depending on
what gtk_file_system_path_to_filename() delivers.

GtkFileSelection doesn't appear to use gtk_file_system_path_to_filename() at all.

This is a nuisance.  I have just converted some code to expect a Glib::ustring
container instead of the old std::string container for Gtk::FileSelection.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



--__--__--

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