GLib/GObject+C as the lingua franca?

Kevin Krammer kevin.krammer at
Wed Jul 30 09:56:14 BST 2008

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

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.


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

More information about the kde-core-devel mailing list