Re: RFC: Adding zlib dependency to libgio

[nf2 <nf2 email gmail com>]

On Tue, Nov 10, 2009 at 9:44 AM, Alexander Larsson <alexl 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 <alexl 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