GLib/GObject+C as the lingua franca?
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
>> 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