GLib/GObject+C as the lingua franca?

[Kevin Krammer]

On Sunday 27 July 2008, nf2 wrote:
> Kevin Krammer wrote:

> > Not sure if you actually have to do all this, e.g. streams, having a GIO
> > data source/sink as a QIODevice will most likely be enough.
>
> I already got a simple QIODevice implementation called "FileDevice"
> which wraps FileInputStream.

What I meant is that it might not be necessary to wrap the GIO stream just to 
use it internally.
Might be easier to just access the API directly.

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

I guess this depends on the actual data source. If it cannot report sizes, 
your device implementation just returns true in isSequential().
bytesAvailable() can then also only report the amount of data you have already 
received, i.e. how much can be read without blocking.

See the behavior of Qt's sockets or QProcess

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

I'd say it make sense to wrap stuff that has no respective Qt API. As for the 
streams it might make more sense to keep this as a low priority later-on 
feature once all the needed work is in place.

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

QObject has copying disabled (Q_DISABLE_COPY macro), so nobody expects 
QObject's to be copyable anyway.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- 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/20080727/44fbd37b/attachment.sig>