RFC: Adding zlib dependency to libgio

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC: Adding zlib dependency to libgio

Alexander Larsson
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?

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Martin Nordholts-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Shaun McCance-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

nf2.email
In reply to this post by Alexander Larsson
On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Cody Russell-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Alexander Larsson
In reply to this post by Martin Nordholts-2
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.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Alexander Larsson
In reply to this post by nf2.email
On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote:

> On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson <[hidden email]> 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.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Alexander Larsson
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Bastien Nocera
In reply to this post by Alexander Larsson
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

nf2.email
In reply to this post by Alexander Larsson
On Mon, Nov 9, 2009 at 12:23 PM, Alexander Larsson <[hidden email]> wrote:

> On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote:
>> On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Thiago Macieira
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

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Dan Winship-2
In reply to this post by Bastien Nocera
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Shaun McCance-2
In reply to this post by Alexander Larsson
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

nf2.email
In reply to this post by Thiago Macieira
On Mon, Nov 9, 2009 at 4:05 PM, Thiago Macieira <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Paul Davis
In reply to this post by Alexander Larsson
On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Alexander Larsson
In reply to this post by Shaun McCance-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Alexander Larsson
In reply to this post by Paul Davis
On Mon, 2009-11-09 at 23:03 -0500, Paul Davis wrote:

> On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson <[hidden email]> 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.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

nf2.email
On Tue, Nov 10, 2009 at 9:44 AM, Alexander Larsson <[hidden email]> wrote:

> On Mon, 2009-11-09 at 23:03 -0500, Paul Davis wrote:
>> On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Tim-Philipp Müller
In reply to this post by Alexander Larsson
On Sun, 2009-11-08 at 10:54 +0100, 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).
>
> (...)
>
> Anyone who thinks this is a bad idea?

I think that's a great idea.

Cheers
 -Tim


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Matthias Clasen-2
In reply to this post by nf2.email
On Tue, Nov 10, 2009 at 5:49 AM, nf2 <[hidden email]> wrote:
> On Tue, Nov 10, 2009 at 9:44 AM, Alexander Larsson <[hidden email]> wrote:
>> On Mon, 2009-11-09 at 23:03 -0500, Paul Davis wrote:
>>> On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
12