GLib/GObject+C as the lingua franca?

[Kevin Krammer]

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

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.

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/20080730/c741e14a/attachment.sig>