On Oct 17, 2005, at 3:13 PM, muppet wrote:
squentin pointed out in irc that there is no bindings for g_filename_display_name()[1], or for its recommended brother, g_filename_display_basename()[2].Now, looking at this for a few minutes, there are several observations:
...
- g_filename_to_utf8() can fail if the filename is hosed, making filename_to_unicode() rather annoying to use. This is why the display* variants were introduced -- to try really hard to recover from those failures and make a reasonable conversion.- We can add bindings for g_filename_display_(base)?name(), but how would we add them? Glib::filename_display_name() looks wrong. Glib::Filename::display_name() looks alright, and may make more sense.- We could just change gperl_filename_from_sv() to use g_filename_display_name(). What would this mean for compatibility? You'd still have the problem of having a full path to truncate when you just wanted to display a basename.
On further reflection, this would not work.The attached patch adds Glib::filename_display_name() and Glib::filename_display_basename() as exportable functions in HEAD. There is no fallback implementation, so their presence is dependent upon the bindings being built against glib 2.6.0. I'm not very fond of this, but unless somebody has ideas about how to make a fallback that will work without significant code duplication, i'm out of ideas.
Attachment:
g_filename_display_name.patch
Description: Binary data
Thoughts?
Same question. Good idea? Bad idea?
[1] http://developer.gnome.org/doc/API/2.0/glib/glib-Character-Set- Conversion.html#id2810046 [2] http://developer.gnome.org/doc/API/2.0/glib/glib-Character-Set- Conversion.html#id2810157
--
Jolt is my co-pilot.
-- Slogan on a giant paper airplane hung in Lobby 7 at MIT.
http://hacks.mit.edu/