Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 4:05 PM, Thiago Macieira thi...@kde.org wrote: As for your argument on living on the same apartment, I disagree a bit. I think we're still at the same building stage, where we share our piping, heating, electricity, we cooperate in the building council, but we haven't yet moved into the same unit. I'm afraid you are condemned to live in the same unit. At least if you want more applications to move in. :-) Another way to see it is from the Innovator's Solution book. The author expresses a theory in which companies and entities go through cycles of interdependency and modularity. I think that applies to us: we're still in the state of interdependency, where the product is not good enough yet and we need a high level of flexibility and the ability to make non-standard interfaces, in order to stay competitive. KDE and GNOME are definitely acting like companies, there are a lot of competitive feelings involved. The problem is, that you are not only trying to build different cars, but also your own roads. This won't turn out well. [...] uncoordinated markets driven by parties working in their own self interest are unable to provide these goods in desired quantities. (http://en.wikipedia.org/wiki/Public_good) Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
Em Segunda-feira 09 Novembro 2009, às 15:09:36, nf2 escreveu: * Just compare this to libdbus: The IPC protocol is standardized, but almost everyone uses the libdbus as the real interface. And that library links to libc, libpthread and libexpat (statically). That's one of its strengths, since it can be integrated into any event loop, not just Qt's and glib's. (And trust me, integrating that into the event loop is NOT an easy task) And yet I've considered more than once dumping the libdbus-1 library and writing the protocol myself. The marshalling and demarshalling is basically the only code that I use from that library. The reason being that the performance bottlenecks left now in D-Bus code are all inside that library. And I, as a C++ coder, don't have the motivation to go into it and fix it. Nothing against C -- and if I put my mind to it, I'd probably manage to do it. But the fact is that, when it's my spare time we're talking about, if it just too difficult, I will find something else to do. Besides, glib is only a dependency of Qt on the X11 platform. I can justify a VFS API that requires D-Bus to work properly (with some effort, on some platforms other IPC mechanisms would be preferable), but I cannot do it if it requires using glib gobject in platforms that its own maintainers currently don't support. Think of it this way too: it's possible to port the KDE ioslaves to speak on D-Bus by just modifying libkio. I've investigated that possibility already. So we could bring all of the current ioslaves into the party too. As for your argument on living on the same apartment, I disagree a bit. I think we're still at the same building stage, where we share our piping, heating, electricity, we cooperate in the building council, but we haven't yet moved into the same unit. Another way to see it is from the Innovator's Solution book. The author expresses a theory in which companies and entities go through cycles of interdependency and modularity. I think that applies to us: we're still in the state of interdependency, where the product is not good enough yet and we need a high level of flexibility and the ability to make non-standard interfaces, in order to stay competitive. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
Em Quarta-feira 11. Novembro 2009, às 03.54.53, nf2 escreveu: On my system, Gtk+ links 44 libraries. I guess one less or more won't make any difference. Or, for instance a gvfs-ls / , which probably has to load about 15 libraries, takes 0.03 seconds. Therfore - I reckon - gathering unrelated APIs into a single *.so won't have any significant performance benefit. But maybe i'm wrong. Actually, it does. There's a performance penalty in loading each library, plus a combined penalty of symbol resolution. Remember that each library has a different symbol resolution search order, so the dynamic linker needs to keep the map for each library. And the more libraries you have, the more libraries you have to walk through with failed resolutions before you reach the library that provides the symbol you're searching for. Moreover, inter-library symbol dependency requires expensive relocations. When it's inside the same library, a cheaper absolute relocation is possible. This affects more C++ code (the vtables) than C code (which would go through lazy- binding PLT), but still affects enough to be relevant. There used to be some tools to measure the ELF hashing performance, as well as the average number of lookups to reach the conclusion of undefined symbol. I'm sure Ulrich Drepper's DSO Howto paper has some more information. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 09:33 -0600, Shaun McCance wrote: How do you envision the optional extra support being provided? Would there be extension points that GVFS could plug into? Or compile-time optional modules like the GdkPixbuf loaders? Or would applications be expected to provide the extra juice? I'm willing to do the grunt work to add these. It's work I'd have to do in Yelp anyway to fully transition to GIO. Thanks for tackling the hard part of the problem. Any of these will work. I have not gotten that far yet in the design though. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Tue, Nov 10, 2009 at 9:44 AM, Alexander Larsson al...@redhat.com wrote: On Mon, 2009-11-09 at 23:03 -0500, Paul Davis wrote: On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson al...@redhat.com wrote: I know you're really interested in cross-desktop VFS support, and I don't disagree with having something like that. However, the fact is that libGIO is an important part of the Gtk development stack, that contains all the stuff that developers that want to write Gtk+ apps want. i've written some relatively big GTK apps. i've never wanted to use any of the facilities that GIO offers me. how is it central to GTK? maybe to GNOME apps? i don't know - I don't target GNOME at all. Its file access is whats used to implement the file selector, its got the core interfaces for implementing failable object construction, the standard async method call patterns, cancellable method call support, stream abstractions, file change notification, etc. Its clearly possible to write applications without using any of these. But its also pretty common that applications/libraries want to use these. Just like Qt contains all that Qt developers want/need. This was one of the primary reasons I chose GTK over Qt. I'll make my own choices about libraries for IPC, sockets, UUIDs and the like, thank you very much. I was looking for a widget-based GUI toolkit, not MFC Nothing is forcing you to use the APIs that are availible. If you want to use another library for some part of typical application functionality that's clearly possible. However, it is very helpful to have the most common application development APIs in the platform as that gives you: * better platform independency by abstracting out the implementations (for instance, we have a single content type/application launching API but with different implementations on unix and windows) * similar kinds of APIs * better integration between the APIs (i.e. they can use each other as needed) * Less memory use by more apps using the same libs * Easier to handle security fixes and bugfixes if more apps use the same libs So, while Gtk+ started as a widget library, its now focusing on being more of a graphical user interface application development library. QtDBus is a separate *.so And the GIO manual still says: GIO is striving to provide a modern, easy-to-use VFS API that sits at the right level in the library stack. :-) http://library.gnome.org/devel/gio/unstable/ch01.html As I'm reading the word Gtk+ here more often: I still believe that a VFS API shoudn't be tied to a certain UI toolkit. That would be repeating the mistake KIO did. What about Mozilla, OpenOffice, VLC and many many others. They should all link GIO (as a VFS API). If libgio dupulicates too many things they already have, they might be put off. Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Tue, Nov 10, 2009 at 5:49 AM, nf2 nf2.em...@gmail.com wrote: On Tue, Nov 10, 2009 at 9:44 AM, Alexander Larsson al...@redhat.com wrote: On Mon, 2009-11-09 at 23:03 -0500, Paul Davis wrote: On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson al...@redhat.com wrote: As I'm reading the word Gtk+ here more often: I still believe that a VFS API shoudn't be tied to a certain UI toolkit. That would be repeating the mistake KIO did. What about Mozilla, OpenOffice, VLC and many many others. They should all link GIO (as a VFS API). If libgio dupulicates too many things they already have, they might be put off. Whether GIO contains DBus support or not has probably minimal influence on whether or not Mozilla or OpenOffice use it. They make their own decisions about what platform to build on and don't care if you think they 'should' use anything in particular. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Tue, Nov 10, 2009 at 1:41 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Tue, Nov 10, 2009 at 5:49 AM, nf2 nf2.em...@gmail.com wrote: On Tue, Nov 10, 2009 at 9:44 AM, Alexander Larsson al...@redhat.com wrote: On Mon, 2009-11-09 at 23:03 -0500, Paul Davis wrote: On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson al...@redhat.com wrote: As I'm reading the word Gtk+ here more often: I still believe that a VFS API shoudn't be tied to a certain UI toolkit. That would be repeating the mistake KIO did. What about Mozilla, OpenOffice, VLC and many many others. They should all link GIO (as a VFS API). If libgio dupulicates too many things they already have, they might be put off. Whether GIO contains DBus support or not has probably minimal influence on whether or not Mozilla or OpenOffice use it. They make their own decisions about what platform to build on and don't care if you think they 'should' use anything in particular. The modularity of the GLib stack is a nice feature. A lot of things which are built with it, might be very useful far outside Gtk+ and Gnome. Let's take for instance libsoup: It already links GIO. But for what sake would a HTTP client library always need to carry D-Bus around? On my system, Gtk+ links 44 libraries. I guess one less or more won't make any difference. Or, for instance a gvfs-ls / , which probably has to load about 15 libraries, takes 0.03 seconds. Therfore - I reckon - gathering unrelated APIs into a single *.so won't have any significant performance benefit. But maybe i'm wrong. Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:23 +0100, Alexander Larsson wrote: On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: Obviously some could could be shared, but a straight dependency on libgio isn't necessary. Eh, some code could be shared is what i meant. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:17 +0100, Alexander Larsson wrote: On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. The API in question includes compression and decompression as streams (among other things), and is pluggable. Code to do automatic detection of compression type could easily be added. However, having some level of support being guaranteed (i.e. a mandatory dependency) has additional value that something being pluggable doesn't. For instance you could distribute zlib compressed data (as file or linked into your app) and depend on all glib installations being able to decompress that data. It also means you can e.g. design file formats based on a specific compression algorithm and never run into issues with some platform not having what is needed to read the file. Plugin-based optional compression support is basically only useful for best-effort decompression of unimportant document files. Thats obviously nice to have, but not as important as reliable compression support. Could this be used by libsoup for websites that zlib-compress their data? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 12:23 PM, Alexander Larsson al...@redhat.com wrote: On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson al...@redhat.com wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). We already have a dependency on zlib from gdk-pixbuf, so all Gtk+ apps already pull this in, however there could be non-gtk+ using glib apps that now get an additional dependency. Its a very small (74K .so) and very widely availible/used library though, so I don't think this is a huge deal. Anyone who thinks this is a bad idea? Well - as I already said earlier, I think GIO - in the long run - has a potential of becomming *the* free desktop API for file-management. Simply because it's design is modern, universal and reminiscent of IO APIs, which people already know from other programming languages (i.e. Java). And it's sitting very low in the stack. Such an API is hard to design and takes long to consolidate. I know you're really interested in cross-desktop VFS support, and I don't disagree with having something like that. However, the fact is that libGIO is an important part of the Gtk development stack, that contains all the stuff that developers that want to write Gtk+ apps want. Just like Qt contains all that Qt developers want/need. We will never artificially limit our platform just because of cross-desktop compatibility. And additionally, I don't see GIO as the thing that should really be shared between glib and Qt, but rather GVFS. I'd much rather see some cooperation between the gvfs and Qt people to stabilize the gvfs protocols such that Qt could directly talk to gvfs mounts. Obviously some could could be shared, but a straight dependency on libgio isn't necessary. Hmm... I don't really understand the neccessity to rewrite the entire GVFS client in Qt/C++. All the other programming languages use bindings, therefore why should Qt/C++ be different? * While writing a pure Qt/C++ client would certainly be possible (apart from the issue with the UriMappers), it would be a huge effort. * With one disadvantage: Standardizing all the D-Bus mechanics inside GVFS would probably make it harder to move forward. My feeling is that it's always the best approach to define the stable public interface at the narrowest part of the chain. Which not neccessarily has to be the IPC part. * Just compare this to libdbus: The IPC protocol is standardized, but almost everyone uses the libdbus as the real interface. * libGIO is an important part of the Gtk development stack. Yes, but - at least at the moment - it doesn't carry a lot of things in it, which are Gnome/Gtk specific. Most of the things are either the implementation of freedesktop-standards, or GVFS related. So it just looks like the all you need for file-management API, I just can't help it. And in my opinion it's a really cool one. Sorry, Alexander, that i'm asking to put a different label on it. I think GIO deserves to be more than a detail in the Gtk stack. :-) * I think if GIO/GVFS can pull Qt and KDE into their boat, this would be an important signal for all the 3rd party applications to link a proper VFS interface. Because at the moment many of them won't, as this implies deciding for a certain desktop environment. * Hopefully, one day people will realize, that KDE, Gnome and Qt are kind of living in the same appartment. There is no way to escape from that - independence is a dream. For one simple reason: applications, applications, applications. They are the most important desktop feature, the primary reason to buy a computer. So what's the point of having all the infrastructure duplicated: The toaster, the dish-washer, the washing-machine... ;-) This duplication just causes an enormous amount of chaos. However, i think a pure Qt implementation of GVFS would definitely be a very important move into the right direction. Cheers, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On 11/09/2009 07:53 AM, Bastien Nocera wrote: Could this be used by libsoup for websites that zlib-compress their data? It could (and eventually would), but passing data to zlib isn't the hard part of the problem there. (And this will actually be working in libsoup in 2.28.2.) -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:17 +0100, Alexander Larsson wrote: On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. The API in question includes compression and decompression as streams (among other things), and is pluggable. Code to do automatic detection of compression type could easily be added. However, having some level of support being guaranteed (i.e. a mandatory dependency) has additional value that something being pluggable doesn't. For instance you could distribute zlib compressed data (as file or linked into your app) and depend on all glib installations being able to decompress that data. It also means you can e.g. design file formats based on a specific compression algorithm and never run into issues with some platform not having what is needed to read the file. Plugin-based optional compression support is basically only useful for best-effort decompression of unimportant document files. Thats obviously nice to have, but not as important as reliable compression support. That sounds fair. Right now, Yelp will happily build without bzip2 and lzma support if you don't have them. I consider it a distro problem: if distros want to ship man and info pages compressed with bzip2 or lzma, then they need to make sure their Yelp is built right. I have no problems pushing that policy decision lower. How do you envision the optional extra support being provided? Would there be extension points that GVFS could plug into? Or compile-time optional modules like the GdkPixbuf loaders? Or would applications be expected to provide the extra juice? I'm willing to do the grunt work to add these. It's work I'd have to do in Yelp anyway to fully transition to GIO. Thanks for tackling the hard part of the problem. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 4:05 PM, Thiago Macieira thi...@kde.org wrote: Besides, glib is only a dependency of Qt on the X11 platform. I can justify a VFS API that requires D-Bus to work properly (with some effort, on some platforms other IPC mechanisms would be preferable), but I cannot do it if it requires using glib gobject in platforms that its own maintainers currently don't support. Hmm ... I think a VFS API shouldn't even require D-Bus to work. Just like GIO only uses D-Bus/GVFS on X11. I agree that a QtVFS shouldn't depend on GIO in the API. But perhaps it would make sense to design it close to GIO so that it can act as a thin binding when GIO is available. My feeling is that the tough part of a new QtVFS is designing and consolidating the API. Therefore my thought was: If GIO has proven to be portable, an API which is designed to wrap GIO should be portable itself. Without necessarly depending on GIO. So this approach might save lot's of time. Cloning GIO in QObject/C++ style should save months racking one's brain about little details like which virtual methods and signals are required in which class. And if such an API moves towards a pure QDBus implementation later, why not. But starting with that might be putting the cart before the horse. Because I'm a bit worried that a complete rewrite of GVFS in Qt/C++ is just a too ambitios undertaking to get started. Regards, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson al...@redhat.com wrote: I know you're really interested in cross-desktop VFS support, and I don't disagree with having something like that. However, the fact is that libGIO is an important part of the Gtk development stack, that contains all the stuff that developers that want to write Gtk+ apps want. i've written some relatively big GTK apps. i've never wanted to use any of the facilities that GIO offers me. how is it central to GTK? maybe to GNOME apps? i don't know - I don't target GNOME at all. Just like Qt contains all that Qt developers want/need. This was one of the primary reasons I chose GTK over Qt. I'll make my own choices about libraries for IPC, sockets, UUIDs and the like, thank you very much. I was looking for a widget-based GUI toolkit, not MFC ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. GIMP currently has bad hacks to support transparent loading of .xcf.gz and .xcf.bz2 files and it would be nice to let this be handled at a lower level. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. GIMP currently has bad hacks to support transparent loading of .xcf.gz and .xcf.bz2 files and it would be nice to let this be handled at a lower level. Yelp has a custom GIOChannel for transparent loading of gzip-, bzip2-, and lzma-compressed man and info files. I'd also be very interested in a GInputStream that handles this for me. There was a thread about this in July: http://mail.gnome.org/archives/gtk-devel-list/2009-July/msg00133.html Alex, I'm not sure what your plan is, but if you're planning some sort of GFilterInputStream to do automatic decompression, I think making it zlib-only would miss the mark for what most people would want to use it for. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson al...@redhat.com wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). We already have a dependency on zlib from gdk-pixbuf, so all Gtk+ apps already pull this in, however there could be non-gtk+ using glib apps that now get an additional dependency. Its a very small (74K .so) and very widely availible/used library though, so I don't think this is a huge deal. Anyone who thinks this is a bad idea? Well - as I already said earlier, I think GIO - in the long run - has a potential of becomming *the* free desktop API for file-management. Simply because it's design is modern, universal and reminiscent of IO APIs, which people already know from other programming languages (i.e. Java). And it's sitting very low in the stack. Such an API is hard to design and takes long to consolidate. Therefore i'm a bit worried when too many features get added to this API (like bookmarks, gdbus,...), which make it less attractive as a basic free desktop commodity. For instance Qt lacks such a VFS API, Thiago Macieira said that he would like to see a QtVFS. Qt is a very good thing to get more applications written for the free desktop, IMHO GIO/GVFS developers should see it as one of their potential customers. Qt can already link GLib for the main-loop, provide Gtk+ filechoosers, thus moving forward to full VFS support seems natural. Perhaps QtVFS could be thin bindings for GIO, designing another VFS API from grounds up doesn't sound like a good idea, and i guess GIO is portable to the same OSs like Qt. But i don't know whether there are main-loop issues on Non-Unixes. KDE can also use GIO with my KIO-GioBridge ioslave. Not very popular though :-( I can't really comment on this (de)compression API, sounds like a good feature. But wouldn't it be sufficient to include some zlib compression/decompression code in libgio.so itself? I also put Thiago Macieira on CC. Regards, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: Qt can already link GLib for the main-loop, provide Gtk+ filechoosers, thus moving forward to full VFS support seems natural. Perhaps QtVFS could be thin bindings for GIO, designing another VFS API from grounds up doesn't sound like a good idea, and i guess GIO is portable to the same OSs like Qt. My understanding was that they will link to GLib, but not to GObject. And since GIO depends upon GObject, what you're suggesting doesn't sound very likely to happen. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
