Commit notifications for specs
nf2 at scheinwelt.at
Fri May 2 09:14:17 PDT 2008
Emmanuele Bassi wrote:
> On Wed, 2008-04-30 at 18:27 +0200, Pau Garcia i Quiles wrote:
>> - KIO, GIO and GnomeVFS. KIO is the I/O framework used by KDE since,
>> at least, 1999. But the Gtk+ developers decided to go on their own and
>> implement GIO without talking to KDE developers. GIO was developed
>> while KDE was developing the 4.0 version, a very good moment to break
>> compatibility. This has been a sad, missed opportunity to define a
>> common spec.
> the icon naming is a specification. the trash location and usage is a
> GIO, and KIO, are not "specifications": they are libraries exposing an
> API. making them work as a common low-level API would have required
> either GObject switch to QObject or vice-versa.
> the idea behind GIO was adding an virtual file system API into GLib and
> using GObjects; using something else would have completely defeated the
> whole point of it.
I guess it wouldn't be hard to wrap a GObject API like GIO with Qt/C++
language binding. Just put the GObject into the d-pointer, call
g_object_ref in the assignment operator and g_object_unref in the
destructor (similar QSharedDataPointer)... Regarding GIO i wouldn't be
surprised if Trolltech one day writes such a wrapper layer.
It would be cool if there finally were some kind of agreement on a
"lingua franca" for coding low-level X-Desktop libraries and API's. IMHO
such a decision has been postponed for too long already. Probably
GLib/GLib-Main-Loop plus GObject would be a good and pragmatic compromise.
And as GIO demonstrates, GInterfaces are a nice technique to separate
the interface from the implementation.
Perhaps it could as well work the other way round: Qt/C++ libraries
with GObject/GInterface APIs. Without Qt types leaking through the API,
even commercial apps could use such libraries (in case the library is
licensed in LGPL - but i'm not a licensing expert).
> by the way: GIO implements various fd.o specifications - the
> thumbnailing specification, the trash spec, the shared mime info spec,
Yeah - that's why i think that GIO makes Portland/DAPI pretty redundant
(at least partially). As lots of third party apps want
network-transparent file-management, they will likely link GIO anyway.
More information about the xdg