GLib/GObject+C as the lingua franca?

[nf2]

Thiago Macieira wrote:
> nf2 wrote:
>   
>>
>>> If you want copiable things, use pointers. I'm implementing a generic
>>> pointer-holding class with atomic reference-counting for Qt 4.5, so
>>> you don't have to write anything.
>>>       
>> That's cool. Taking the above example, would something like this be
>> possible?
>>
>> QList<QRefCountedPointer<QMount>> VolumeMonitor::getMounts()
>>     
>
> Yes.
>
> But the current way Qt and KDE API is designed is that we divide things 
> into two main groups:
>
>  - "value type" classes: they are implicit shared, detach atomically on 
> write, never used as pointers, never use QObject. Can be implemented 
> using QSharedData/QSharedDataPointer.
>
>  - "object type" classes: cannot be copied, usually derive from QObject, 
> used both on the stack and as pointers to the heap.
>   

I wonder if i made a mistake when designing my API. Perhaps many of the 
async functions in my GFile and GInputStream wrappers

http://library.gnome.org/devel/gio/stable/GFile.html#g-file-read-async
http://library.gnome.org/devel/gio/stable/GInputStream.html#g-input-stream-read-async

shouldn't emit signals, but rather just take a slot as an argument?

In this case - do i still need to derive my wrapper classes from QObject?

Cheers,
Norbert