GLib/GObject+C as the lingua franca?

nf2 nf2 at scheinwelt.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
>>
>> http://library.gnome.org/devel/gio/stable/GFile.html#g-file-read-async
>> http://library.gnome.org/devel/gio/stable/GInputStream.html#g-input-stream-
>> 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 
operations.

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

http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-readfileasync-sample.h
http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-readfileasync-sample.cpp

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 &)));
     
     m_fileAsyncOperation.read();


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.

Cheers,
Norbert
















More information about the kde-core-devel mailing list