GConf integration needs some additional thought and community input before deciding whether to have it or not, so I have a question about another good technology, GIO.
Milestone 0.47 in the roadmap has GTK 2.12 listed in the dependencies. GTK 2.12 in turn depends on Glib 2.16 (at least on Ubuntu Hardy), which includes GIO. In fact with the next version, GTK 2.14, the build fails if giomm-2.4 is not added to configure.ac, because gtkmm-2.4 depends on it. So it looks like everything is in place to use it.
Can we start making use of GIO now, or do we have to wait some more until it's more commonplace in Linux distributions?
Regards, Krzysztof Kosiński.
On Thu, Oct 23, 2008 at 10:17:48AM -0700, Krzysztof Kosi??ski wrote:
GConf integration needs some additional thought and community input before deciding whether to have it or not, so I have a question about another good technology, GIO.
Milestone 0.47 in the roadmap has GTK 2.12 listed in the dependencies. GTK 2.12 in turn depends on Glib 2.16 (at least on Ubuntu Hardy), which includes GIO. In fact with the next version, GTK 2.14, the build fails if giomm-2.4 is not added to configure.ac, because gtkmm-2.4 depends on it. So it looks like everything is in place to use it.
Can we start making use of GIO now, or do we have to wait some more until it's more commonplace in Linux distributions?
Should be fine. We're not close to releasing 0.47 so probably by the time we are, it will be there.
Bryce
On Oct 23, 2008, at 10:30 AM, Bryce Harrington wrote:
On Thu, Oct 23, 2008 at 10:17:48AM -0700, Krzysztof Kosi??ski wrote:
Can we start making use of GIO now, or do we have to wait some more until it's more commonplace in Linux distributions?
Should be fine. We're not close to releasing 0.47 so probably by the time we are, it will be there.
I'm not quite sure, since we do want to still keep compatible with non-bleeding-edge where possible.
Krzysztof, it would be good if you could go through the wiki page and add gio as a tracked item, so we can see who we'd be leaving behind.
Also a few questions had come up about its use in the past, but it really wasn't bringing in more that we needed off-hand. It's more like the java nio packages and other higher level functions.
Jon A. Cruz wrote:
Krzysztof, it would be good if you could go through the wiki page and add gio as a tracked item, so we can see who we'd be leaving behind.
I could use a link to the relevant page because I'm not 100% sure what you want me to do.
Jon A. Cruz wrote:
Also a few questions had come up about its use in the past, but it really wasn't bringing in more that we needed off-hand. It's more like the java nio packages and other higher level functions.
I read the description of Java nio here: http://java.sun.com/j2se/1.4.2/docs/api/java/nio/package-summary.html and it doesn't look like it's similar to GIO. GIO is also a filesystem abstraction library and includes transparent support for many protocols like FTP, SFTP, OBEX, SMB, etc. through the gvfs daemon. nio seems more like buffer abstraction.
Regards, Krzysztof Kosiński
On Oct 24, 2008, at 5:30 PM, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
Krzysztof, it would be good if you could go through the wiki page and add gio as a tracked item, so we can see who we'd be leaving behind.
I could use a link to the relevant page because I'm not 100% sure what you want me to do.
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies
Jon A. Cruz wrote:
Also a few questions had come up about its use in the past, but it really wasn't bringing in more that we needed off-hand. It's more like the java nio packages and other higher level functions.
I read the description of Java nio here: http://java.sun.com/j2se/1.4.2/docs/api/java/nio/package-summary.html and it doesn't look like it's similar to GIO. GIO is also a filesystem abstraction library and includes transparent support for many protocols like FTP, SFTP, OBEX, SMB, etc. through the gvfs daemon. nio seems more like buffer abstraction.
There are a few different things GIO brings. Some that were asked about previously were items that either were similar to the nio changes or were more items for C and not C++ and gtkmm.
Which specific aspects of GIO were you looking at?
Oh, and remember one *huge* issue is that bytes != characters. Glib::ustring handles that, but most of other C-based libs do not. That's a big problem for us, since among other things GTK+ apps have to deal with three different encodings simultaneously: UTF-8, locale encoding, and filesystem encoding.
OK, added some info to the tracking page. GIO is part of Glib 2.16, so I just specified the version required for 0.47.
Jon A. Cruz wrote:
Oh, and remember one *huge* issue is that bytes != characters. Glib::ustring handles that, but most of other C-based libs do not. That's a big problem for us, since among other things GTK+ apps have to deal with three different encodings simultaneously: UTF-8, locale encoding, and filesystem encoding.
Yes, I know about the UTF-8 issue. The problem is that Inkscape uses UTF-8 filenames thorought the codebase rather than filenames in filename encoding, as required by Glib conventions. This causes a lot of fuss when working with Glib APIs - e.g. Inkscape::IO::file_test. When it comes to file contents the only problematic part is incremental reading of UTF-8 data, but it seems Inkscape doesn't do this.
I'll delve into the IO code some more and then I'll come up with what changes are necessary to transition to GIO, and what are the possible caveats. One I have identified so far is that MemoryOutputStream, needed to sanitize the import / export code, is only present in Glib 2.18 and not yet present in C++ bindings, but it's easy to reimplement.
Regards, Krzysztof Kosiński.
On Oct 25, 2008, at 1:16 PM, Krzysztof Kosiński wrote:
Yes, I know about the UTF-8 issue. The problem is that Inkscape uses UTF-8 filenames thorought the codebase rather than filenames in filename encoding, as required by Glib conventions. This causes a lot of fuss when working with Glib APIs - e.g. Inkscape::IO::file_test. When it comes to file contents the only problematic part is incremental reading of UTF-8 data, but it seems Inkscape doesn't do this.
The problem is not really that it uses UTF-8 filenames exactly. The data inside the program should be UTF-8 so that all the stock API's will work.
The problem is that as filenames enter the program they need to be converted from filename encoding to UTF-8. And when locale data comes it, it must be converted from locale encoding to UTF-8. And when data goes out to a filename, it needs to be converted from UTF-8 to filename encoding, etc.
So we need to normalize on UTF-8 data as it comes in, and convert to the precise encoding needed as it goes out. And which encoding is needed depends on where the data is going out to. It's very common for the same data item to go out to one call that needs filename encoding, and also to a different call that needs locale encoding.
On Oct 25, 2008, at 1:16 PM, Krzysztof Kosiński wrote:
I'll delve into the IO code some more and then I'll come up with what changes are necessary to transition to GIO, and what are the possible caveats. One I have identified so far is that MemoryOutputStream, needed to sanitize the import / export code, is only present in Glib 2.18 and not yet present in C++ bindings, but it's easy to reimplement.
Probably the first question that needs to be answered is what exactly switching to GIO will bring as a benefit.
The second question is what is the cost.
As I've mentioned, in the past people have suggested using it, but for things that we wouldn't really benefit from.
Jon A. Cruz wrote:
Probably the first question that needs to be answered is what exactly switching to GIO will bring as a benefit.
- Transparent support for remote filesystems in Gnome - Ability to automatically determine the mimetype of the opened file using the MIME database on Unix and registry settings on Windows (http://library.gnome.org/devel/gio/stable/gio-GContentType.html) - The ability to remove several hacks from the clipboard code - currently to copy SVG data we write it to a temporary file and then read it back (!) - enabled by the GIO streams API - Reading / writing files to / from standard output - Sane filename conventions = better maintainability - Slightly smaller memory footprint - Removal of lots of cruft
I think that's sufficient to consider the migration.
Regards, Krzysztof Kosiński
On Sun, 2008-10-26 at 10:17 -0700, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
Probably the first question that needs to be answered is what exactly switching to GIO will bring as a benefit.
- Transparent support for remote filesystems in Gnome
- Ability to automatically determine the mimetype of the opened file using
the MIME database on Unix and registry settings on Windows (http://library.gnome.org/devel/gio/stable/gio-GContentType.html)
- The ability to remove several hacks from the clipboard code - currently to
copy SVG data we write it to a temporary file and then read it back (!) - enabled by the GIO streams API
- Reading / writing files to / from standard output
- Sane filename conventions = better maintainability
- Slightly smaller memory footprint
- Removal of lots of cruft
- Cross platform files are GTK's problem not ours - Ability to start to move the file handling code over to all async read/write - Integration with the glib main loop for above - Reasonable ability to use extensions and remote files (GIO does a FUSE mount and can hand back a "local file" for extensions to use)
== Cost ==
- Updated dependencies - Effort to migrate
OK, I have one question. How do I derive something meaningful from a glibmm or gtkmm class? In particular, how do I override virtual methods of Gio::OutputStream? In raw GOject, the methods write, flush, splice, close and their asynchronous versions are virtual and can be set in the class constructor, but in the C++ wrappers they are not. Is there a way to do this in C++ or do I have to write my own GObject, and then wrap it in a C++ API? (The second part is trickier, since it requires meddling with glibmm internals).
Regards, Krzysztof Kosiński
On Tue, 2008-10-28 at 18:54 -0700, Krzysztof Kosiński wrote:
OK, I have one question. How do I derive something meaningful from a glibmm or gtkmm class? In particular, how do I override virtual methods of Gio::OutputStream? In raw GOject, the methods write, flush, splice, close and their asynchronous versions are virtual and can be set in the class constructor, but in the C++ wrappers they are not. Is there a way to do this in C++ or do I have to write my own GObject, and then wrap it in a C++ API? (The second part is trickier, since it requires meddling with glibmm internals).
I believe you can just subclass them. No more tricky than that. If you have a function in the subclass with the same prototype that one will get used.
--Ted
Ted Gould wrote:
I believe you can just subclass them. No more tricky than that. If you have a function in the subclass with the same prototype that one will get used.
This doesn't work if I want to do anything via the base pointer, because the functions are not virtual. http://www.vmc.org.pl/pliki/gio.cpp Compile with g++ gio.cpp $(pkg-config --cflags --libs giomm-2.4 glibmm-2.4) -o gio Instead of writing Z2ltcA== and a newline, it writes "gimp" and no newline. It looks like we would need to use raw GObject, or don't use any derived streams.
Regards, Krzysztof Kosiński
When I do this in raw GObject, it works very well. I think this is the way to go for now. Later we can propose our code for inclusion into Glib and glibmm (e.g. the base64-encoded streams are generic enough), or hack together our own C++ bindings.
Here is a sample app which base64-encodes the file given as the argument using a derived stream: http://tweenk.artfx.pl/gio-sample.zip
Regards, Krzysztof Kosiński
participants (4)
-
Bryce Harrington -
Jon A. Cruz -
Krzysztof Kosiński -
Ted Gould