This allows you to avoid ugly calls like "NewArray (null, some_array)"
when you want the child type to be determined by the first element of
the children array.
Also throw specific exceptions when both type and children parameters
would be null.
On Windows with MinGW, csc.exe is confused by paths like
"../AssemblyInfo.cs", so we need some trickery to have something that
works on both Linux and Windows.
This isn't pretty, but it's the best solution I could find right now.
The other approach would have been to go back to copying AssemblyInfo.cs
around, but that has it's own set of issues.
On Windows, gacutil.exe is often installed in a path with spaces, like
"C:\Program Files...". This causes problem when trying to call it during
"make install". Enclosing in double quotes fixes this, and has no impact
on Linux.
This way there's less redundancy, and if the library name changes in the
future, it will be changed only in one place.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
Recently glib started to warn about the future deprecation of adding
interfaces after class_init, which we fixed here [1].
Now, a similar warning has started to happen for the addition of
properties, example:
(Nereid:23225): GLib-GObject-WARNING **: Attempt to add property __gtksharp_33_Banshee_Widgets_TileView::gtk-sharp-managed-instance after class was initialised
So we need to add them before class_init finishes too, and this
change makes it this way.
[1] 9ff7ec8b2c
There is no null check after these casts so if they fail they would
generate a NullReferenceException. By changing them to static casts
we would get a InvalidCastException which are much less misleading.
In the same way all GLib.Object-derived classes provided by the
generator have a GType static property (i.e. Gtk.Widget), we need
the same for the *Adapter classes, to access their GType without having
an instance of it. (The first use case would be GStreamerSharp's
Gst.Bin.IterateAllByInterface ().)
For this, we cannot simply add the property to all adapter classes
and be done, because it would clash with a property which is already
there, but is non-static, that has the same name and same value
(this property is needed for complying GInterfaceAdapter abstract
class), so we rename this property to GInterfaceGType because
using this name for the static one would not be consistent with the
rest of the classes generated which already provide the static one
with the name "GType".
The implementation of FindClassProperty() was the same as the
implementation of FindInterfaceProperty(), both receiving an iface
instead of a GObjectClass* [1].
The reason of this oversight can well be explained by the fact that
FindClassProperty() is private and not used, actually. However, we
may need it soonish as a good bind to g_object_class_find_property.
[1] https://developer.gnome.org/gobject/unstable/gobject-The-Base-Object-Type.html#g-object-class-find-property
GSource type was already there (but was not mapped by
the generator yet) so then the autogenerated methods
have been added manually inside the class after the
custom methods.
Other Source-related class are also generated and added
(but not mapped in the SymbolTable) to glib.
This means that we're modifying the generated code that
we checked in, so then we increase the future TODO about
more information about what we need to fix later.
The changes to Cond are a consequence of the changes to
Mutex because the former uses the latter.
Add GDate and GDateTime classes to glib, and map
them in the generator's SymbolTable.
(The types TimeZone and TimeVal are also added because
the Date* types depend on them, but there is no need
to map them in the generator.)
Also move the TODOs of other auto-generated classes
to a single TODO in the Makefile
The pointer from native is stored inside of a class which
wraps the structure. Fields can be accessed by marshalling
from and to the pointer. glib: Value.Update does now invoke
a private Update() method which is needed to update the new
structures.
glib.csproj needs to reference System.Core from .NET 3.5 because
glib-sharp now[1] uses System.Action [2] delegate (not to confuse
with System.Action<T>) which was not available in .NET 2.0's System
reference. This way MonoDevelop stops marking "Action" in red color.
[1] 8e07e7d225
[2] http://msdn.microsoft.com/en-us/library/system.action%28v=vs.90%29.aspx
The only autogenerated AssemblyInfo files are in cairo and in
gtk-sharp's root, not inside other libraries like atk, glib, etc.
Removing them will make MonoDevelop stop rendering a red element
underneath each project.
ListBase was throwing a NullReferenceException in DataMarshal() due
to the fact that Reflection was being used to find the adapter name
of the interface generated by the bindings, which has recently
changed [1].
[1] 6cb03440c1
