kio_giobridge IO slave
vladc6 at yahoo.com
Sat Jan 5 04:24:15 GMT 2008
--- Kevin Krammer <kevin.krammer at gmx.at> wrote:
> On Thursday 03 January 2008, Vlad Codrea wrote:
> > It links to glib and therefore introduces a compile-time
> dependency on
> > glib. This wastes memory because now KDE has two low-level
> > that have redundant functionality: QtCore and Glib.
> It is an IO slave, a separate helper process, so this is hardly a
> Avoiding unnessesary dependencies for application libraries is one
> of the
> advantages of doing things out-of-process, isn't it?
If a distro or user chooses to compile QtCore without linking to Glib,
it becomes impossible to compile or run the kio_giobridge IO slave.
That's OK because the existing KIO slaves already do everything that
Including kio_giobridge in kdelibs means that kdelibs will *not* be
compilable on a pure (Glib-less) QtCore, effectively mandating linking
to Glib by *all* Qt and KDE applications.
> > 2) File I/O is fundamental to nearly all KDE apps, and for a KDE
> > developer to fix or investigate bugs in GIO/GVFS they would have
> > code in C and learn the subtleties of GLib/GIO/GVFS.
> Since it is an additional/optional IO slave, it can just be
> deactivated/removed if it causes problems and the usual IO slave
> will be
Not really, because once distros are forced to link QtCore to Glib,
then all Qt and KDE apps will have to link to Glib and run on Glib's
non-native and slow event loop.
> > 3) This deviates from the way other kdelibs components like Solid
> > dealt with Glib apps, namely to communicate with them via dbus.
> Different situation. The IO slave is already out-of-process,
> with the application through the usual KIO channels.
> > 4) There already are mature and tested KIO slaves to handle all
> > protocols that GVFS handles, with less indirection and room for
> And, as I wrote above, they are still available and the default and
> doesn't have to use the bridge slave. It just adds another option.
Options are great, but let's not mandate the kio_giobridge option and
its dangerous Glib baggage by placing it in kdelibs. I would agree
with Kevin Ottens that kio_giobridge should reside where it is
available to but not forced upon users, like extragear.
Never miss a thing. Make Yahoo your home page.
More information about the kde-core-devel