GLib/GObject+C as the lingua franca?
nf2 at scheinwelt.at
Tue Jul 29 00:03:38 BST 2008
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.
* 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
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
have to become
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
More information about the kde-core-devel