Ted Gould wrote:
I think for most things switching to gio probably makes the most sense, but I do agree that would be best. std where gio doesn't make sense. Problem is that GIO is rather new to the Glib stack, so I'm not sure when we'll update to it.
I think the best thing to do is propose a patch. Less code in Inkscape is always a good thing.
I had a look at GIO, and it seems that it would be indeed the best choice. I thought about deriving char_traits and other stream classes and making them wrap the relevant Glib routines, but it seems that the design of the standard library makes this prohibitively laborious, if not downright impossible, specifically because of locale issues.
GIO is in Glib 2.16, and is required by Gnome 2.22, which had a stable release recently. I think we can move the Inkscape codebase to GIO when Ubuntu 8.04 and Fedora 9 hit the streets, because we won't be able to get the next Inkscape release into distributions before Ubuntu 8.10 and Fedora 10 anyway. Our only concern therefore is ensuring that people can develop on reasonably recent systems. The additional benefit of moving to GIO would be eliminating Gnome-VFS from the codebase (as GIO's primary objective is to provide a replacement of Gnome-VFS). Gnome-VFS is obsolete, doesn't work very well and suffers from design flaws as well as extreme dependency bloat, so it will be a relief to see it removed.
The mapping is as follows (same for output streams): Inkscape::IO::InputStream -> Gio::InputStream Inkscape::IO::BasicInputStream -> Gio::FilterInputStream Inkscape::IO::URIInputStream -> Gio::FileInputStream, can only be acquired from a Gio::File object Inkscape::IO::StringInputStream -> Gio::MemoryInputStream Inkscape::IO::StdInputStream -> special case of Gio::UnixInputStream, I suppose, but not sure how this would work on Windows. However, most Inkscape operations involving stdio I can think of are of relevance to Unix users only.
Writers are not addressed specifically, but reimplementing the current ones should be easy. UTF-8 is not specifically covered, but it should be easy to derive a specialized seekable text stream to handle UTF-8 encoded data if it's required.
Regards, Krzysztof (Chris) Kosiński