This commit makes it possible to build any project of the gtk-sharp.sln
from an IDE (except audit and sample projects, which require a bit more
work).
This doesn't mean that autotools is deprecated, but just that it is more
comfortable to use an IDE when working on gtk-sharp because it will
offer better auto-completion, and will stop highlight misleading
semantic errors, from now on.
Clarify the README thanks to the use of pkg-config, and add a
configure-time warning so people notice about the problem without having
to read the README.
At application shutdown, it's very likely to be spammed by
gui-thread-check with a river of:
*** GTK CALL NOT IN GUI THREAD: Widget.Dispose
*** GTK CALL NOT IN GUI THREAD: Widget.remove_InternalDestroyed
*** GTK CALL NOT IN GUI THREAD: Widget.Dispose
*** GTK CALL NOT IN GUI THREAD: Widget.remove_InternalDestroyed
...
From what I gather, these two methods (in gtk-sharp master[1]) could
be called by the finalizers, but do not call any unmanaged functions,
so it should be ok to not report them as violations.
[1] https://github.com/mono/gtk-sharp/blob/master/gtk/Widget.cs
Cherry-picked from 77a40599ca
Using fflush() right away after printf() calls avoids the buffers to
be written in an apparently complete-out-of-sync way from the point
of view of the developer. This problem would specially occur when
redirecting all output to a file this way:
mono Foo.exe > out.txt 2>&1
Without this fix, all the output from gui-thread-check would appear
at the end of the file, instead of in between the output generated by
the program.
Cherry-picked from 6988cd4cd2
There are two elements repeated in this expression:
(( ((A) || (B)) || (B)) && C)
We can simplify "(A || B) || B" to simply "A || B",
so the result is a bit more readable this way:
(A || B) && C
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
The ABI of ATK has been broken recently [1], so the best way
to deal with this is removing the pads from all the interfaces
found by GAPI in the atk namespace.
This avoids that some mono-based apps crash with new version
of Atk (i.e. 2.10.0, the one that Ubuntu 13.10 ships), and
still works for older versions (i.e. 2.8.0, the one that
Ubuntu 13.04 ships).
[1] https://git.gnome.org/browse/atk/commit/?id=b1f70e81ef1d7287dcb2cafa9a115ff5752ece55
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".
This "Implementor" suffix was refactored recently (in commit
6cb03440c1) to be accessed via the ImplementorName property. So we
eliminate now the last occurrence of it in hardcoded form.
The parser will be going away at some point in the future, but we
will still need the fixup step. And the fixup step is really more
of a preliminary step for the generator anyway.
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
As GtkTextIter has no public properties, the default generated Equals
implementation would be "return true;". We now suppress that and with a
fix-up now use the native gtk_text_iter_equal to implement the Equals
method.
