GLib/GObject+C as the lingua franca?
kevin.krammer at gmx.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...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel