Post by nf2Post by Thiago MacieirabytesAvailable() 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;
}
Post by nf2Yeah - 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...
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.
Post by nf2* 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.
Post by nf2* 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.
Post by nf2Post by Thiago MacieiraAs 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.
Post by nf2Post by Thiago MacieiraThat'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.
Post by nf2Probably 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.
Post by Thiago MacieiraIf 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