GLib/GObject+C as the lingua franca?

[nf2]

Thiago Macieira wrote:
> nf2 wrote:
>   
>> But i'm not really satisfied yet. Don't know how to implement the
>> QIODevice::atEnd() and bytesAvailable () functions. GIO is a pull API so
>> i can't really "answer" those methods. Perhaps with some read-ahead, but
>> then seeking is difficult.
>>     
>
> Implement it in sequential mode then, instead of random access:
>
> bytesAvailable() returns the number of bytes you have buffered, the 
> maximum amount that calling read() can return. In other words, if you try 
> to read more than bytesAvailable(), you will get bytesAvailable() bytes.
>
> atEnd() = true ←→ bytesAvailable() = 0
>   

Thanks for the help - i'll try sequential mode with buffering and 
read-ahead then. :-) If people want random access (which is a rare case 
i guess) they can still use the GIO streams.

>   
>   
>> Perhaps Qt/GIO bindings should provide both - a QIODevice implementation
>> - and a thin wrapper for all the GIO classes: Directory listings,
>> file-info, drive/mount management, launching apps, and also the GIO
>> streams (maybe useful for the advanced users, dunno).
>>     
>
> That makes sense. Those other functionalities aren't streams, so they 
> don't make sense as QIODevice, clearly. That functionality is also 
> present in KIO: the directory listings, mount requests, etc., are not 
> descendants of KIO::TransferJob.
>
> It should be possible to write an abstracted layer of I/O, one that can 
> use KIO as well as GIO (and even QNetworkAccessManager, but that's a lot 
> more limited in scope). It could, in the future, replace KIO -- i.e., be 
> the cleanup of KIO that didn't happen for KDE 4.
>   

Yeah - that would be cool. I wonder how i could make my KGIO API more 
abstract, that you don't necessarily have to plug GIO.

Some thoughts:

* Should a next-generation KIO be simplified, only providing the 
convenience-, high-level APIs (like KIO::Netaccess) and GUI related 
functions (password, file dialogs, progress bars), backed with a more 
GIO style library for the basic types (File, FileInfo, Errors), advanced 
operations (streaming, seeking) and low-level features? I guess the 
second library could sit below KDE - on the same layer as Phonon, QtDBus...

* Aligning some things with GIO (FileInfo/UDS fields and error codes) 
would be good probably...

* Should all calls go through GIO - at least on Unixes? Because then all 
apps get access to the same IO system. If so, i wonder which of the 
current KIO protocols/features can not be provided through the GIO 
interface and what to do with them? This seems pretty delicate.

* Would there still be need for the Slaves system, cause GVFS will 
handle most of the protocols anyway?


> As for launching apps... there's klauncher. Or are you talking about 
> launching applications in a remote host?
>   

Launching apps. As GIO provides that feature - why hide it. Might still 
be useful for Qt-only apps.

>   
>>>> Another problem is copy-constructors/operators. Passing around
>>>> wrapped GObjects that way works quite nicely, cause you don't need to
>>>> care about garbage collection, but Qt Signal connections are lost
>>>> when copying the object.
>>>>         
>>> Assuming you mean connections of some internal object (since QObjects
>>> themselves can't be copied anyway), why not just have this shared
>>> object in a shared (reference counted) private?
>>>       
>> Well - actually most of the public KGIO classes can be copied. And they
>> do derive from QObject.
>>     
>
> That's not possible.
>
> Either they are copiable, or they derive from QObject. Doing both is not 
> possible.
>   

I guess it's technically possible, but if it's not the common Qt style i 
agree that it shouldn't be done. Probably i need to think over the KGIO 
design. Either i need to split off lots of little job-classes for the 
async operations, or make the classes non-copyable. Kind of sad, because 
things like

QList<Mount> VolumeMonitor::getMounts()

have to become

QList<Mount*> VolumeMonitor::getMounts()

which seems less convenient.

>
> 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()


Cheers,
Norbert