glib-sharp will only get a new release with the new API that we need for
3.0 in a year or something. Instead of waiting a year before we can release
something we now have our own internal copy of glib-sharp trunk that will
be dropped once glib-sharp 3.0 is released.
Everything is now compilable and working without any additional patches.
There are three types of solution used: adding the new keyword to the member
in the subclass, renaming the subclass member to avoid name collision and
removing the subclass member if the functionality is the same.
The custom properties that return a IEnumerable are replaced by generated
properties that return an Iterator. Most of the code in Iterator.cs has
moved to Iterator.custom to implement IEnumerable.
- Use automake --foreign to silence warnings about gnu extensions.
- Add gstreamer-api.xml as prerequisite for gstreamer-sharp/*plugins/generated/%.cs
- Avoid executing $(MAKE) -C {core,base}plugins multiple times when gstreamer-api.xml is changed.
- Only generate xml for elements with changed metadata
We don't have any ways to store them in a persitant way anyway,
for example the content will disappear if the managed mini object
is unreffed and later the same native instance is used again in
managed code.
The warnings where mainly about usage of ellipsis type arguments.
For most of the functions hidden by this patch there was already an
alternative, for the params[] Caps constructor custom code is added.
Fixes bug #584913.
Among other things, remove the SetCallbacks methods. It's easier
in the managed world to use the signals instead of the callbacks.
Also hide the action signals as there are methods for them
already.
The perl script should accept nested namespaces, like N1.N2, for outputting
xml. Making a Global class for static methods didn't work for functions like
n1_n2_function. Another change is that N1 is stripped from the cname for the
element name.
Partially fixes bug #584744.
They're not used in any Index implementation and we can't use them
in C# either. This should work without problems because according to
C calling conventions the caller is responsible for preparing
the function arguments and cleaning up later. This only means that
func and user_data will contain invalid data now.
