GLib/GObject+C as the lingua franca?

[Thiago Macieira]

nf2 wrote:
>> 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.

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.
>
>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...

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 
transparent.

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

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.

The use of automatic pointers has never been an issue for us: 
QObject-based objects' lifetimes can be tracked using the parent-child 
relationship.

-- 
  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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080729/96975680/attachment.sig>