GLib/GObject+C as the lingua franca?

nf2 nf2 at
Wed Jul 30 12:40:07 BST 2008

Kevin Krammer wrote:
> On Wednesday 30 July 2008, nf2 wrote:
>> I wonder if i made a mistake when designing my API. Perhaps many of the
>> async functions in my GFile and GInputStream wrappers
>> read-async
>> shouldn't emit signals, but rather just take a slot as an argument?
>> In this case - do i still need to derive my wrapper classes from QObject?
> From the description of GFile it looks like it is not an active object in GIO 
> either, just a collection of information about a file
> "...It is necessary to understand that GFile objects do not represent files, 
> merely an identifier for a file..."
> Probably more like a QFileInfo

Perhaps also a bit like KUrl, but with methods to start various file 

> Which would put all the data related operations into a QFile/QIODevice like 
> class which does not need to be copied.
> As for the stream: if you really need that in your top level API, signals 
> should be OK but you can of course also use a call back interface.
> I don't think there will be any use case where you need to copy a stream 
> object, so inheriting from QObject should be no problem.
It's quite tricky. Have a look at my "readfileasync" example:

The first async operation read() (Actually it's an "open") is started 
from File (i have split off the async operations from File to 
FileasyncOperation, but that doesn't matter).

     m_fileAsyncOperation = FileAsyncOperation(file);
     connect(&m_fileAsyncOperation, SIGNAL(inputStreamReady(*const* File&, *const* FileInputStream &, *const* Error &)),
                  *this*, SLOT(inputStreamReady(*const* File&, *const* FileInputStream &, *const* Error &)));

On sucess a FileInputStream will be returned by the signal. Then i 
connect signals to the inputstream and start reading.  The problem is 
that here i'm saving the FileInputStream to a member variable of my 
application object. Perhaps it's not necessary to keep a reference to 
the FileInputStream - Hmm...

*void* *MyDemoApplication::inputStreamReady*(*const* File & file, *const* FileInputStream & inputStream, *const* Error & error)
        m_fileInputStream = inputStream;


        connect(&m_fileInputStream, SIGNAL(readAsyncReady(InputStream * , *const* qint64, *const* Error &)),
                     *this*, SLOT(readAsyncReady(InputStream * , *const* qint64, *const* Error &)));
        connect(&m_fileInputStream, SIGNAL(closeAsyncReady(InputStream *, *const* Error &)),
                     *this*, SLOT(closeAsyncReady(InputStream *, *const* Error &)));
        m_fileInputStream.readAsync(buffer, 80, 100, m_cancellable);


If FileInputStream wasn't a copyable explicitly sharing wrapper this 
would be difficult. Storing the pointer somewhere else doesn't increment 
the reference count.


More information about the kde-core-devel mailing list