Planning, of course, but not sure when. Unfortunately, I'm the only one who touches that code :/

So, let me briefly explain the situation here. QtGStreamer is currently implmented as static bindings. It was done like this because g-i did not work very well with 0.10 and also my time was limited to research creating a g-i based generator. Also, despite being advertised as Qt bindings, it is not *really* Qt bindings, it is rather C++ bindings with a Qt-style API, utilizing a minimal set of Qt's classes, just to provide some minimal integration with Qt.

Also, QtGStreamer consists of two parts: QtGLib, which is the base layer that binds GObject, and QtGStreamer, which is the static GStreamer bindings built on top of QtGLib. In the beggining, QtGLib was meant to be used only by QtGStreamer and it was designed to contain only the features that QtGStreamer would need. However, other projects popped up later, such as telepathy-logger-qt, which use QtGLib but not QtGStreamer.

To add to all this, together with GStreamer breaking its API/ABI, there is also Qt doing that in parallel with Qt5.

Picking up the pieces now... The target is of course to port QtGStreamer to 0.11/1.0, but by doing that we have the opportunity to break the API/ABI. So, I am hoping to be able to use this opportunity to do as much as possible of the following:

- Create an automatic g-i based generator, now that 0.11/1.0 works better with g-i (or at least, it is supposed to; I haven't checked its status since January).
- Integrate certain things better with Qt. The smoke-gobject project has provided a lot of interesting ideas and I have collected some notes at [1].
- Split QtGLib out of QtGStreamer.
- Port to Qt5 and ensure that the codebase builds with both Qt4 and Qt5 (they are mostly API-compatible, so maintaining a single codebase is not impossible and many projects, including QtCreator itself, are doing this). This may actually just require build system adjustments.

I hope I will be able to start this work during the summer, but of course I can't guarantee that I will be free of other work and I can't estimate when this work will be finished. Any help is obviously welcome.

[1]. http://gstreamer.freedesktop.org/wiki/QtGStreamer/QtGLibResearch

Thanks for the detailed explanation, it seems like your plan is very sound in the long term. I'd be happy to help, however I'm not familiar enough with the technologies employed (especially g-i) to get this effort started. 0.11/1.0 is more important to us than anything else right now, and we will be getting started sooner rather than later, so we'll likely either forgo using QtGStreamer or do a naive port using the current design.

I've done a rudimentary port following the current static binding method. I'll attach it here at a later point. If anyone's especially interested let me know and I'll do so sooner than I would otherwise. The exercise definitely leads me to believe a dynamic approach would be better.

Created attachment 216135 [details]
patch serial to partially port qtgstreamer to 0.11

All manual and some auto tests run fine, but any subclasses of MiniObject throw an assertion regarding a missing wrapper constructor. I'll have to come back to this later, or hopefully George or someone else can enlighten me as to what I'm doing wrong (probably many things!). Most of these commits should be squashed into one, but it's probably more informative to leave them separate for now.

https://bugzilla.gnome.org/show_bug.cgi?id=695934

Is this still relevant, master is 1.0 already, no?

Correct, this is "fixed"