Re: [Interest] Best practices for making a Qt facade for a C library
Hi Damian, the application itself is GPLv3, for PulseAudio parts see [1] (every file that starts with pulseaudio). I'm planning to release the library under LGPL but didn't upload anything for public availability yet. As soon as I port all the functionality from my app to the lib, I'll make a separate repo on github. Cheers Dmitriy [1] https://github.com/dpurgin/harbour-callrecorder/tree/master/daemon/src 2015-01-14 13:27 GMT+06:00 Damian Ivanov damianator...@gmail.com: Hi Dmitriy, Wanted to ask if your stuff is open source and is available on github? 2015-01-14 0:26 GMT+01:00 Ian Monroe i...@monroe.nu: On Tue, Jan 13, 2015 at 10:57 AM, Dmitriy Purgin dpur...@gmail.com wrote: Hello all, I'm developing a small Qt project for SailfishOS (a Linux distribution, Meego descendant, Qt 5 based) and had to use some of PulseAudio (a sound server for POSIX OSes) API functions which are pure C. I've wrapped them in a couple of classes but it's evolving to something bigger now and I'm trying to detach these into a shared library which seems to become a basic PulseAudio binding. It's my first facading of a C library and I'm kind of stuck on the architecture now and hope that someone can share ideas on that. Have you looked at the code generation done by QtGstreamer for glib stuff? Not sure if it's any good, just want to make sure you know of it: http://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/ So with the problem stated, my question is: does anyone know any good practices in designing this kind of relationships between classes or can share similar designs to look at? There's no technical problem for me to expose the inner parts of some classes to some other classes, I just wondered if there's a subtle way of doing this. I wrap a C library and had a similar situation. My solution in this case would be to give QtPulseAudioSource a new base class named something like PulseAudioInterface. That class defines pa_context, it could possibly just be a void pointer. It has a member variable for it and a setPulseAudioContext method. Then QtPulseAudioContext would have a class called something likeblessPulseAudioInterface. QtPulseAudioSource could call it in its constructor. In this way it is pretty hidden from users of the library, and QtPulseAudioContext has zero deps on AudioSource. Ian ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Best practices for making a Qt facade for a C library
Hello Ian, thanks for your reply. I think I can use some ideas from QtGstreamer, didn't really know about its existence. I'll try your approach, it feels to me so much better, but I'd prefer composition over inheritance. Thanks! Cheers Dmitriy 2015-01-14 5:26 GMT+06:00 Ian Monroe i...@monroe.nu: On Tue, Jan 13, 2015 at 10:57 AM, Dmitriy Purgin dpur...@gmail.com wrote: Hello all, I'm developing a small Qt project for SailfishOS (a Linux distribution, Meego descendant, Qt 5 based) and had to use some of PulseAudio (a sound server for POSIX OSes) API functions which are pure C. I've wrapped them in a couple of classes but it's evolving to something bigger now and I'm trying to detach these into a shared library which seems to become a basic PulseAudio binding. It's my first facading of a C library and I'm kind of stuck on the architecture now and hope that someone can share ideas on that. Have you looked at the code generation done by QtGstreamer for glib stuff? Not sure if it's any good, just want to make sure you know of it: http://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/ So with the problem stated, my question is: does anyone know any good practices in designing this kind of relationships between classes or can share similar designs to look at? There's no technical problem for me to expose the inner parts of some classes to some other classes, I just wondered if there's a subtle way of doing this. I wrap a C library and had a similar situation. My solution in this case would be to give QtPulseAudioSource a new base class named something like PulseAudioInterface. That class defines pa_context, it could possibly just be a void pointer. It has a member variable for it and a setPulseAudioContext method. Then QtPulseAudioContext would have a class called something likeblessPulseAudioInterface. QtPulseAudioSource could call it in its constructor. In this way it is pretty hidden from users of the library, and QtPulseAudioContext has zero deps on AudioSource. Ian ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Best practices for making a Qt facade for a C library
Hi Dmitriy, Wanted to ask if your stuff is open source and is available on github? 2015-01-14 0:26 GMT+01:00 Ian Monroe i...@monroe.nu: On Tue, Jan 13, 2015 at 10:57 AM, Dmitriy Purgin dpur...@gmail.com wrote: Hello all, I'm developing a small Qt project for SailfishOS (a Linux distribution, Meego descendant, Qt 5 based) and had to use some of PulseAudio (a sound server for POSIX OSes) API functions which are pure C. I've wrapped them in a couple of classes but it's evolving to something bigger now and I'm trying to detach these into a shared library which seems to become a basic PulseAudio binding. It's my first facading of a C library and I'm kind of stuck on the architecture now and hope that someone can share ideas on that. Have you looked at the code generation done by QtGstreamer for glib stuff? Not sure if it's any good, just want to make sure you know of it: http://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/ So with the problem stated, my question is: does anyone know any good practices in designing this kind of relationships between classes or can share similar designs to look at? There's no technical problem for me to expose the inner parts of some classes to some other classes, I just wondered if there's a subtle way of doing this. I wrap a C library and had a similar situation. My solution in this case would be to give QtPulseAudioSource a new base class named something like PulseAudioInterface. That class defines pa_context, it could possibly just be a void pointer. It has a member variable for it and a setPulseAudioContext method. Then QtPulseAudioContext would have a class called something likeblessPulseAudioInterface. QtPulseAudioSource could call it in its constructor. In this way it is pretty hidden from users of the library, and QtPulseAudioContext has zero deps on AudioSource. Ian ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Best practices for making a Qt facade for a C library
Hello all,
I'm developing a small Qt project for SailfishOS (a Linux distribution,
Meego descendant, Qt 5 based) and had to use some of PulseAudio (a sound
server for POSIX OSes) API functions which are pure C. I've wrapped them in
a couple of classes but it's evolving to something bigger now and I'm
trying to detach these into a shared library which seems to become a basic
PulseAudio binding. It's my first facading of a C library and I'm kind of
stuck on the architecture now and hope that someone can share ideas on
that.
Obviously, I'm looking forward to encapsulate all the C code in my library
and provide library users with Qt-style classes, signals and slots, thus
eliminating libpulse dependency for them. My basic architecture is quite
simple: for the Qt classes I use d-pointers containing relevant PulseAudio
data and static methods to use for PulseAudio callbacks which are called
for any kind of events. To emit Qt signals upon PulseAudio events I use
q-pointers in these static methods. So this goes like this:
// in pseudocode suspiciously resembling C++
class QtPulseAudioContext : public QObject
{
...
signals:
void connected();
private:
QtPulseAudioContextPrivate* d;
};
class QPulseAudioContextPrivate
{
pa_context* paContext; // PulseAudio C data
QtPulseAudioContext* q;
// callback for PulseAudio event
static void onContextCallback(..., void* userData)
{
QtPulseAudioContextPrivate* d = reinterpret_cast
QtPulseAudioContextPrivate* (userData);
// processed an event from PulseAudio, redo it Qt style
emit d-q-connected();
}
};
As for now I'm dealing with three PulseAudio objects: context
representing connection to PulseAudio server, sinks representing audio
outputs and sources representing audio inputs. Naturally, I've wrapped
them as three separate classes. Both sinks and sources operate within
single context and any PulseAudio API call involving sinks and sources must
provide the corresponding context. When these classes were bundled in my
application, I've passed PulseAudio's pa_context* to a ctor of my class,
used it internally and was pretty happy with that:
// in pseudocode suspiciously resembling C++
class QtPulseAudioContext
{
QtPulseAudioSource* getSource(...);
};
QtPulseAudioSource* QtPulseAudioContext::getSource(...)
{
...
new QtPulseAudioSource(d-paContext);
...
}
class QtPulseAudioSource
{
QtPulseAudioSource(pa_context* context); // pa_context is PulseAudio
stuff
// the implementation of the following would need to call
// PulseAudio API and use pa_context
void setDefaultPort(const QString name);
};
Now passing pa_context is a no-go since it exposes PulseAudio dependency to
a library user. So my first call is to somehow provide
QtPulseAudioContext's private data to a source or sink constructors or even
construct their private data in QtPulseAudioContext. I don't think any of
both is a good way. The former violates the incapsulation of
QtPulseAudioContext, the latter moves initialization of a private data
outside the class that owns this data.
So with the problem stated, my question is: does anyone know any good
practices in designing this kind of relationships between classes or can
share similar designs to look at? There's no technical problem for me to
expose the inner parts of some classes to some other classes, I just
wondered if there's a subtle way of doing this.
Thanks in advance.
Best regards,
Dmitriy
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Best practices for making a Qt facade for a C library
On Tue, Jan 13, 2015 at 10:57 AM, Dmitriy Purgin dpur...@gmail.com wrote: Hello all, I'm developing a small Qt project for SailfishOS (a Linux distribution, Meego descendant, Qt 5 based) and had to use some of PulseAudio (a sound server for POSIX OSes) API functions which are pure C. I've wrapped them in a couple of classes but it's evolving to something bigger now and I'm trying to detach these into a shared library which seems to become a basic PulseAudio binding. It's my first facading of a C library and I'm kind of stuck on the architecture now and hope that someone can share ideas on that. Have you looked at the code generation done by QtGstreamer for glib stuff? Not sure if it's any good, just want to make sure you know of it: http://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/ So with the problem stated, my question is: does anyone know any good practices in designing this kind of relationships between classes or can share similar designs to look at? There's no technical problem for me to expose the inner parts of some classes to some other classes, I just wondered if there's a subtle way of doing this. I wrap a C library and had a similar situation. My solution in this case would be to give QtPulseAudioSource a new base class named something like PulseAudioInterface. That class defines pa_context, it could possibly just be a void pointer. It has a member variable for it and a setPulseAudioContext method. Then QtPulseAudioContext would have a class called something likeblessPulseAudioInterface. QtPulseAudioSource could call it in its constructor. In this way it is pretty hidden from users of the library, and QtPulseAudioContext has zero deps on AudioSource. Ian ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
