The migration to generic collections [1] caused another regression: a
KeyNotFoundException was being thrown (instead of returning null like
HashTable did) when using the Destroyed event of the Gtk.Widget class.
[1] 6850b343ca
A particular example of this problem is Banshee's Import Media feature,
which was generating the following stacktrace:
[1 Debug 23:24:36.898] Starting - Importing Media
Marshaling activate signal
Exception in Gtk# callback delegate
Note: Applications can use GLib.ExceptionManager.UnhandledException
to handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown
by the target of an invocation. --->
System.Collections.Generic.KeyNotFoundException: The given key was not
present in the dictionary.
at System.Collections.Generic.Dictionary`2[System.IntPtr,System.Delegate].get_Item
(IntPtr key) [0x00000] in <filename unknown>:0
at Gtk.Widget.add_Destroyed (System.EventHandler value) [0x00000] in
/home/knocte/gtk-sharp/gtk/Widget.cs:333
at Hyena.Widgets.AnimatedWidget..ctor (Gtk.Widget widget, UInt32
duration, Easing easing, Blocking blocking, Boolean horizontal)
[0x0004d] in /home/knocte/banshee/src/Hyena/Hyena.Gui/Hyena.Widgets/AnimatedWidget.cs:78
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.
Autogen.sh was grepping for the obsolete macro AM_CONFIG_HEADER, which
was replaced by AC_CONFIG_HEADERS in configure.ac. As a consequence it
was not calling autoheader, and then causing automake to fail if
config.h.in was not already present.
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
This regression surfaced after 82a957bc9d [1],
when many collections were migrated to generic collections. HashTables
simply return null when queried for certain key, while Dictionary objects
throw KeyNotFoundException.
The regression could be noticed, more particularly, when trying to
compile the gtk3 branch of the gudevsharp project [2].
[1] 82a957bc9d
[2] https://github.com/mono/gudev-sharp/commits/gtk3
For example gtk_drag_start allows a null Gdk.Event so we need to marshal
it to IntPtr.Zero instead of throwing a NullReferenceException
Cherry-picked from the gtk-sharp-2.12 branch.
Also:
* improving naming consistency
* obsolete old/broken stuff
* clean up tabs/space mix
NOTE: this removes the wrapper caches for Pattern and Surface as
there was no reliable way to clear them.
This is a merge from changes in Mono.Cairo in mono 3.2.
To be able to do this, Name property of GenBase class is now virtual, so
that it can be overriden in InterfaceGen with the new name.
Adapters, however, are still classes and then need special care as such
(cannot use the 'Name' property anymore), but this improves a bit the
readability of some parts of the code as the *Implementor and *Adapter
suffixes are now concentrated in just two new properties of GenBase and
not repeated all over the place.
What seemed to be a race condition (because of not happenning 100% of
the times) ended up being an early garbage collection of a delegate that
was still referenced by an unmanaged struct without having a managed
counterpart [1].
The consequence of this was a NullReferenceException happening in a line
which didn't have a dereference of a null object. The way to reproduce it
deterministically 100% of the times was setting the env var MONO_NO_SMP.
[1] http://www.mono-project.com/Interop_with_Native_Libraries#Memory_Boundaries
With automake version 1.13.2 (which comes in debian testing/jessie),
we were starting to get these warnings by default:
...
Running automake --foreign ...
atk/glue/Makefile.am:16: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
gio/glue/Makefile.am:11: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
gtk/glue/Makefile.am:18: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
gtk/gui-thread-check/profiler/Makefile.am:8: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
pango/glue/Makefile.am:13: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
sample/opaquetest/Makefile.am:18: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
sample/valtest/Makefile.am:18: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
Running autoconf ...
...
We simply follow the warning's recommendation of using AM_CPPFLAGS instead
(CPP meaning C PreProcessor, not C Plus Plus), as explained in
http://www.gnu.org/software/automake/manual/html_node/Program-Variables.html
The deprecation of INCLUDES has been very long there already (since 2002,
therefore Automake 1.7), and we already depend on automake 1.10.
