Commit notifications for specs

nf2 nf2 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
> specification.
> 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 mailing list