[kaarna]

Slow on the forums, but I see from the SVN version that Duit has gone forward alot. Keep up the good work you're doing!

I just tested some stuff with the GtkWrapper, and I've started trying to make GstreamerD with it. The wrapper stuff seems to work pretty well for Gstreamer as it's GObject based and the html docs are of the same format as with Gtk.

I got a helloworld kind of thing working that makes a gst_init, and then asks the gst_version, and prints that out. It's the first example in the Gstreamer manual.

For those who don't know, Gstreamer is supposed to be the best ever multimedia framework (the default for Gnome), although it's not yet 1.0 (it's pretty close though 0.10.10) and you can't do everything yet. The structure of Gstreamer seems great for writing any kind of app, that uses audio or video. And they've already made lots of plugins (which some of them use existing work).

So the question is, if and when a GstreamerD binding is working, should it be part of Duit, or should it be a separate libgstreamerd.a so you could leave it out as a dependancy if you don't need it? And even if it would be separate lib, should it be in the Duit svn, as it uses the same GtkWrapper (with it's own APILookUpGstreamer.txt)? Or should it be a separate project hosted in dsource.org, and just follow the development of Duit from close?

One more thing about Duit is that there should be some checking somewhere for D:s reserved words, as there are some interface and debug words in the original Gstreamer C source code. And at the moment those have to be removed by hand from lib/gstreamer.d, which get's generated everytime. I looked a bit, but didn't find the obvious and easy way to add that feature to the GtkWrapper.d.

Anybody interested in helping with GstreamerD...?

[kaarna]

Ok, I already found the way to change the interface and debug to intrface and dbug. All I had to do was to add them to wrap/utils/DuitClass.d in a function called idsToDuit().

There's alot of things to be done for Gstreamer, but it's all coming clearer, the more I look into /wrap.

[Ant]

[kaarna]

Ok. Another small success in the gstreamerD front. I've managed to get a very hackish version working, and I've made the first example app, that plays back an .ogg file.
I've made some changes to the GtkWrapper utilities and it automatically creates some code, that I then handtuned just to get it compile. I've looked at the way you create duitgl, and made a similar additional libgstreamerd.a and a source path called srcgstreamer. And also the necessary compd scripts.

I think I should put my gstreamer wrapper code in Duit svn, but I'm unsure about the way to do it. Is the trunk/gtkD/ tree identical to the Duit version? Should all new development be done in gtkD tree? And another problem for me is that I'm quite unfamiliar with subversion, so I might have some learning to do there...

GStreamer should make a nice addition to the gtkD libraries, as it offers a multimedia library to the D programming language with just little changes to the GtkWrapper utilities.

One particular problem is that some of the GStreamer functions seem to use libxml2 and it's xmlNodePtr. At the moment I have just hand removed all the methods that use it, but there's propably some better way doing that automatically, and hopefully someday wrapping also libxml2...

[BLS]