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
