[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: GLib/GObject+C as the lingua franca?
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2008-07-30 8:56:14
Message-ID: 200807301056.23364.kevin.krammer () gmx ! at
[Download RAW message or body]


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

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]