GLib/GObject+C as the lingua franca?
thiago at kde.org
Tue Jul 29 07:43:14 BST 2008
>> 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()
>> 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.
Don't forget to add the QIODevice buffer size too:
qint64 MyClass::bytesAvailable() const
return QIODevice::bytesAvailable() + sizeOfMyBuffer;
>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,
KIO::NetAccess is definitely not enough. The API we provide must be
asynchronous. Just like today, there's a convenience API on top of it for
synchronous operation (KIO::NetAccess is it).
I don't understand the GIO basic types are. Are those filesystem-local? Or
are they like KIO::mimetype()? The API should be fully network
Seeking and streaming are only used today in a few places.
>* Aligning some things with GIO (FileInfo/UDS fields and error codes)
>would be good probably...
If it's an abstraction layer on top of GIO, I don't see why.
It has to have concepts that map to GIO concepts, but it shouldn't use GIO
names or expose GIO API at all.
>* 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.
If possible, the backend should be changeable.
I don't know which KIO features cannot be provided, but you can also
wonder if those slaves should be there in the first place. For example,
KMail is having problems today with its old structure of using pop3,
imap4 and smtp as ioslaves -- when they are clearly not.
>> 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.
Because we shouldn't complicate the API.
If the recommended way of launching apps is klauncher, then that's what
people should use.
>> 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.
No, it's not possible at all. You can fake it, but it's not a real copy in
the C++ sense of it.
>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
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
- "object type" classes: cannot be copied, usually derive from QObject,
used both on the stack and as pointers to the heap.
The use of automatic pointers has never been an issue for us:
QObject-based objects' lifetimes can be tracked using the parent-child
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel