Commit notifications for specs

[nf2]

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.

Regards,
Norbert