I'm trying to write a gstreamer plugin in C++, using the GStreamermm bindings. Now, there's a good plugins writers guide (http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/), and on the web there's various examples and templates, but for gstreamermm, there's very little amount of documentation whatsoever.
I know I could just resort to using a mixture of C and C++, but using the C++ bindings seems so much more elegant.
Simply 'translating' the examples found in the gstreamer pwg to gstreamermm is kind of a dead end; gstreamer requires the use of quite a few macros for defining types, which I cannot see an immediate gstreamermm translation to. Additionally, I have only little experience with gstreamer, and absolutely no experience with gobj (so far).
Is anyone able to put me on the right track? Even the tiniest example or explanation would do.
Thanks
I've asked this on the gtkmm mailing list a couple of days ago, and got the following answer (from José Alburquerque):
Presently, the only plug-ins that have a (probably non-existent) possibility of being developed using gstreamermm are ones that are
private to applications. If that's possible, These plug-ins would be
registered using the Gst::Plugin::register_static()[1] method and not
the process that you've described above.
[1] http://developer.gnome.org/gstreamermm/unstable/classGst_1_1Plugin.html#ac0728bb285ae1bed9298c0f9ea522ad9
In theory, one would extend one of the gstreamermm base classes[2] and
call the Gst::ElementFactory::register_element()[3] method in the
Gst::Plugin::SlotInit slot (callback) so that an element factory that
generates these elements can be created. That factory can then be
added to the registry using Gst::Registry::add_feature()[4] in the
same Gst::Plugin::SlotInit slot.
[2] http://developer.gnome.org/gstreamermm/unstable/group__GstBaseClasses.html
[3] The Gst::ElementFactory::register_element() method is a method
that is not implemented yet but would wrap the gst_element_register()
function. That would be part of an upcoming release.
[4] http://developer.gnome.org/gstreamermm/unstable/classGst_1_1Registry.html#ae1f9a1ddd60ef5a7e1f8cddf14ec404f
I've not tested this and don't really know exactly how it would work
(or if it actually would) but it's how I'd try if I had to. However,
I think it's easier to write the plug-in in C presently, but that's
just a matter of making things easier.
Related
Can I use the WRL library in C++ as a replacement for ATL to write a COM component? And if yes, would I be able to use it on older desktop Windows systems, like Windows XP?
I'm pretty sure that the answer to the first question is positive as I found this tutorial on MSDN:
http://msdn.microsoft.com/en-us/library/jj822931.aspx
but what about non-Windows 8 systems?
Well, sure you can. You can write a COM server in pure C++ code without any helper classes at all. You can write one in C if you really want to, although that's a violation of the Geneva Convention on Programmer's Rights in most jurisdictions.
What is probably not so visible is what is missing. WRL just doesn't make it any easier to write a server. Or maintain it. What you'll miss out on:
No help whatsoever to implement IDispatch. Obsoleted in WinRT but still quite important in regular servers. The only way to consume the server from a scripting language, IDispatch provides the late binding support.
No help whatsoever for registration. Obsoleted in WinRT, required for regular servers. Note how the DllRegisterServer() entrypoint is missing. The page you linked patches around the problem by requiring you to write a registry script by hand. That works, it is not exactly something you'd want to maintain or document so IT staff can get it right.
No wrappers for Automation types like BSTR, VARIANT and SAFEARRAY. Obsoleted in WinRT along with IDispatch. You can still fall back to <comutil.h> however.
No help whatsoever from the wizards that are built into Visual Studio that help you get it right. COM servers are awkward because definitions appear in multiple places in your code. And need to be an exact match. You get no help to ensure that CalculatorComponent is an exact match with the IDL, it is entirely up to you. Compiler errors you get from making small mistakes, particularly when maintaining it, can be painful.
And a whole bunch if smaller stuff not worth mentioning, like apartments, ActiveX, aggregation, error info, etc. Hurts pretty bad when you need it though. A possible advantage of WRL is that there's less mystical glue, ATL has a fair amount of it that considerably raises the abstraction level. That was intentional but it has to be learned. There's none at all when you use pure C++ of course, albeit that you have to write too much of it yourself.
Yes. You can write a standard COM component.
There is a sample for this directly in the docs.
And no: Such a COM component will only run on Windows 8 and later...
Hey so for one of my c++ projects I need to develop a 4-5 window application.Now the issue is that currently all of my programs tasks are divided into classes, and I have tested them by passing 'dummy' values and returning print results. That's all fine and working, however now as I want to introduce a GUI interface it presents me with the problem of how my processing should communicate with the front end, since winAPI is initially meant for c and not object oriented language.
What I am thinking of doing, and have a feeling is going to be a tedious task, to make a class which does the win api's registrations and methods for me. Is there any other alternative to this ???
I was looking at integrating Qt into eclipse but I think they stopped providing the library for eclipse, because I couldn't find a download for the library anywhere, not even on the Qt download page.
Well, if you want to use Win32, then you have to do all the stuff that Win32 needs you to do. It's a rather low level API, so you just have to take care of a lot of details.
However, don't over-engineer things. You don't have to write a generic C++ wrapper for Win32... you just have to make a GUI for your program.
If your problem is only that classes are not supported by C, then simply replace the keyword class with the keyword struct. Just make sure to declare the access types of all variables (private, public, protected), that way it becomes interchangeable (Works for both). The only difference between them is the default access type, which for classes is private. In case you used other syntax that is unique to C++, then this wouldn't work.
There are code generators from C++ to C as well. The optimal solution would be to create a GUI using an IDE specifically for that purpose which uses C++ as its base language. MFC works well, but it is not open-source and you will need a considerable knowledge on inheritance and comfort with "class typecasting". Using the included wizards in Visual Studio will help.
Try the first option; it will possibly work the same way.
I recently asked this question https://softwareengineering.stackexchange.com/questions/129076/go-instead-of-c-c-with-cgo and got some very interesting input. However there's a mistake in my question: I assumed cgo could also be used to access c++ code but that's not possible. Instead you need to use SWIG.
The go faq says "The cgo program provides the mechanism for a “foreign function interface” to allow safe calling of C libraries from Go code. SWIG extends this capability to C++ libraries. "
my question:
Is it possible to access high-level c++ frameworks such as QT with SWIG + Go and get productive? I'd like to use Go as a "scripting language" to utilize c++ libraries.
Have you any experience with go and swig? Are there pitfalls I have to be aware of?
Update/Answer: I've asked this over IRC too and I think the question is solved:
SWIG is a rather clean way of interfacing c++ code from other languages. Sadly matching the types of c++ to something like go can be very complex and in most cases you have to specify the mapping yourself. That means that SWIG is a good way to leverage an existing codebase to reuse already written algorithms. However mapping a library like Qt to go will take you ages. Mind it's surely possible but you don't want to do it.
Those of you that came here for gui programming with go might want try go-gtk or the go version of wxWidgets.
Is it possible? Yes.
Can it be done in a reasonably short period of time? No.
If you go back and look at other projects that have taken large frameworks and tried to put an abstraction layer on it, you'll find most are "incomplete". You can probably make a fairly good start and get some initial wrappers in place, but generally even the work to get the simple cases solved takes time when there is a lot of underlying code to wrap, even with automated tools (which help, but are never a complete solution). And then... you get to the nasty remaining 10% that will take you forever (ok, a really really long time at least). And then think about how it's a changing target in the first place. Qt, for example, is about to release the next major rewrite.
Generally, it's safest to stick to the framework language that the framework was designed for. Though many have language extensions within the project itself. For example, for Qt you should check out QML, which provides (among many other things) a javascript binding to Qt. Sort of. But it might meet your "scripting" requirement.
A relevant update on this issue: it is now possible to interact with C++ using cgo with this CL, which is merged for Go 1.2. It is limited, however, to C-like functions calls, and classes, methods and C++ goodies are not supported (yet, I hope).
I currently have two separate programs: (1) a GTK GUI; (2) a Glut application with openGL 3D graphics. However, I'd like to have the openGL part as some widget embedded in the GUI I have.
I have noticed GtkGlExt is exactly what I need, but unfortunately there are no OCaml bindings mentioned on its web pages.
My questions are:
(1) Do you know if there are any such bindings lost somewhere in cyberspace? (I have found a similar discussion from 2008 so I would hope after 3 years something would have happened.)
(2) If there aren't any bindings, how difficult would it be to produce these bindings and where would it be a good place to start? How much of the original C libraries would I have to undestand? (I haven't done any C calls from OCaml so far.)
(3) Alternatively, do you know of any other out-of-the-box package I could use? (I have attempted to install gtkglarea on OSX but I had errors which I couldn't solve and gave up. I've also tried to install lablgtk2-2.14.0+dfsg but got the errors described here.)
The standard solution is to use the LablGTK's OpenGL support. I know of no bindings to other solutions such as gtkglext. If you want to write your own bindings, in general it isn't overly difficult, does take some work and thought. You'll at least need to understand enough of the underlying C library to safely bridge with OCaml, which varies greatly with the library's interface. Since GtkGLExt is Glib-based, so you'll have the blessing and curse of being able to build on existing experience in the community with binding GLib/GTK libraries, and needing to understand enough of how Lablgtk2 works to make your bindings integrate with it. This is possible, but not exactly trivial and I don't recall seeing any good documentation on binding new GTK libraries to help you get started.
Your error in the other question looks like you're trying to hand-compile - have you tried building the GODI package for lablgtk with OpenGL enabled? It may have patches and/or build options to make it work. Alternatively, does MacPorts, which it looks like you're using from the /opt/local path, have OCaml and lablgtk packages?
Another option: There's another option I commonly use when I need access to facilities from an unbound library. Rather than writing bindings for the library, I'll write the logic needing that library in C and expose a minimal interface back to my OCaml code. In the GtkGLExt case, it's probably just a matter of creating initialization, teardown, and start/stop context calls that do the underlying work with the C API and return the OpenGL context or whatever is necessary. You'll still need to do some work to figure out how to get the right GTK object from the OCaml object, and how to pass back whatever is needed for LablGL to work, but it's typically easier than creating real bindings.
I do have to say I'm fairly inexperienced when it comes to C++, don't be too harsh on me.
Recently stumbled unto the wonders of the win32 API and have chosen to practice using it (I'd rather not use MFC/wxWidgets/etc at this point, just for educational purposes).
Well, my real question is:
How do you properly code your win32 GUI stuff into classes. I mean, sure, you can make a class that saves individual window handles, allows for easier modification of window properties, has a more simplified version of CreateWindow(). But as I understand it you will need a messagepump and several callback functions for your created windows. How does that work when combining them with classes?
Could anyone point me in the right direction here? I don't mind reading (a lot of) example code as long as it is commented.
PS: I'm also having trouble finding good (read: easy) documentation on using 'resource files' for my window decorations. Bonuspoints for that! :)
I program in C++ for a living. I like C++.
That said, your life will be so much easier if you do your windows GUI in something .Net, e.g., C#. Win32 is very low-level and you will be building tons of stuff that you will get for free with the .Net libraries. Win32 is not a wonder, anymore. :-)
If you want to learn C++, pick something other than a GUI to do with it.
I personally would use MFC instead of reinventing the wheel here. However, if you insist you need to have an application object that is instantiated when the program is run and contains the message loop and a mechanism for forwarding messages to the correct window objects.
That's the way MFC does it, at least. I'm not sure if the MFC source code is available for download, but if you have access to Visual C++ install disks (any version) you should be able to install the source code on your computer to review.
The biggest problem I faced back when I used the Win32 API (have since moved on to Linux and cross-platform solutions) were the callbacks. Especially the winproc one, AKA the message pump. I found this, which should be a good hint. I did what that page suggests when I rolled my own wrapper.
Look at MFC or ATL/WFC. If you want to re-invent the wheel, the best reference source for how to do so is the wheel itself, especially since the source code is readily available.
I would suggest reading Windows++ by Paul Dilascia. It takes you through the whole process of building a class library in C++ on top of the Windows API. It's written for 16-bit Windows, but all of the concepts presented in the book still apply. Plus, you can get it really cheap since it's "out of date".
And make sure you learn about message crackers (#include <windowsx.h>), they will keep you from pulling out too much hair. ;-)
The best way to learn this is to go and readCharles Petzold's original book. He does a good job of showing how to set up the base message loop and how to build statements for routing the various events to handlers. The real problem here is that by reinventing everything you are going to be spending hours and hours writing and debugging windows event hanlding code instead of writing your own application.
Unless you have a compelling reason for doing this yourself, you woudl be far better served using someone else's construct like MFC.
The only reason I see for coding all this yourself is if you want a basic understanding of how it works before you switch over to MFC or something similar. At least this way you would see how it works under the covers before you can forget it forever.
Many years ago, I developed a set of classes to encapsulate the API (various reasons why we couldn't use MFC). I learned a lot from the MFC source code.
The big key is that every window has a UserInfo data member - you can use it for whatever you want. What you'll want to use it for is the class's this pointer.
Now, the other tricky thing is that the message handler callback function cannot be a normal class member function, as Windows uses C calls and not C++. So your callbacks must be statics. However, since you've saved the class's this pointer, its just a matter of getting the class's userinfo, casting it to your class's this pointer and then calling whatever (non-static) class functions you need.
If you plan it correctly, inheritance will work well, including all of the inheritance that the windows themselves exhibit (ie, an Edit is a Control is a Window).
The only reason I would recommend not reinventing the wheel is you are neither an expert at C++ nor the Win32 API. Trying to learn two unrelated subjects at once will not be productive. If you want to become better at C++, write a library for a subject you know a lot about. If you want to learn the Win32 API, program it raw to understand how it works before creating (or using) a wrapper for it.
There is a pretty good C++ Windows API tutorial on the Reliable Software site.