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
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
Refactoring: moving these methods from GLib.Object to ClassInitializer
brings some benefits:
* We can mark OverrideHandlers as private instead of internal.
* We reduce the number of parameters to zero by making them use fields.
* We can make the god GLib.Object class a bit smaller.
* We can make the ClassInitializer.Idx counter private instead of internal.
GObject upstream has started disabling support for installing interfaces
in GTypes after they have already been initialized (class_init) [1], so
we need to add GInterfaces a bit earlier (*before* class_init starts).
As GLib.Object.OverrideProperty() cannot to be called before class_init
(because it receives a GObjectClass, not a GType) or after (because
otherwise class_init would complain about properties of an interface not
being defined), then we need to call it during class_init.
[1] http://bugzilla.gnome.org/687659
A good side-effect of this fix is that we no longer use the hacky uint
field 'idx' to track the properties count for each class; now it gets
moved to the ClassInitializer class, and thus can be non-static, which
makes a bit more sense (we leave the old OverrideProperty overload for
backwards compatibility).
Simplest way to test this is launching the sample/treemodeldemo.exe and
sample/custom-scrollable.exe in Ubuntu 13.04 beta (which has GLib 2.36).
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=11510
We switch the logic from DISABLE_GTHREAD_CHECK to ENABLE_GTHREAD_INIT
to make the define clearer, and so that it is actually needed when using
older versions of glib, not newer.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
If a GList or a GSList had its element type set to a GInterface, and if
the elements were marked as owned, it would end up freeing those
elements with g_free(), which would lead to a crash.
They need to be unreffed with g_object_unref, but the criteria for that
was whether the element type is assignable to GLib.Object. This is not
true for GInterface types.
We now first check if the element type is an opaque. If not, and if it's
assignable to GLib.IWrapper, we then use g_object_unref.
From what I can see, all GLib.IWrapper subclasses that not opaque can be
unreffed with g_object_unref.
GInterfaceInfo.Data was automatically set to be a GCHandle on the
interface adapter. But the generated GInterfaceInitHandlers were
not using it, just free'ing it.
But for the GInterface property support, the Data field is now used to
pass the class pointer, so casting it to a GCHandle to free it would
cause an exception.
We now don't assume anything about GInterfaceInfo.Data.
Create a GLibSynchronizationContext that sends code to be run on the
GLib main loop, and set it as the current SynchronizationContext in
Gtk.Init().
When you use the await keyword to do a task asynchronously, by default
the awaiter will capture the current SynchronizationContext, and if
there was one, when the task completes it’ll Post the supplied
continuation back to that context, rather than running it on whatever
thread it wants.
This means that if you use the async/await keywords in your Gtk# app,
things will now work as expected with the GTK main thread. For example:
static async void DoWork () // called in the GTK main thread
{
// Do some stuff with the UI...
label.Text = "Starting Work";
// Run something asynchronously, UI is not frozen
int res = await DoLongOperation ();
// Do some more UI stuff, it'll run on the GTK main thread
label.Text = "Work done";
}
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
When accessing the static Objects collection in GLib.Object
class, a lock was held in some places but not all of them.
Brought up by Alan McGovern.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
In slow systems this redundant call was causing the following CRITICAL:
GLib-GObject-CRITICAL **: g_object_remove_toggle_ref:
assertion `G_IS_OBJECT (object)' failed
The GLib.Object.Dispose(bool) method already calls this function at the
end so there is no need to check for duplicates in the PendingDestroys
static field of ToggleRef class (thanks to Alan McGorvern for helping
tracking down the root cause), the double unref call is just prevented.
Fixes BXC#4909.
We need to add inherited interface properties in the Properties hash, so
we remove the DeclaredOnly flag when looking for interface properties in
the type.
We also need to use the type itself as the hash key, and not the adapter
type.
Candidate patch provided by Andres in pull request #17.
* glib/Object.cs: use ToggleRef.Dispose.
* glib/ToggleRef.cs: implement IDisposable and expose former Free
functionality as Dispose(). Free is now private non-lock taking
called by Dispose and the idle queue handler.
Apparently the recent changes in gtk-sharp master that changed
the destroy/dispose strategy caused a bug about calling
g_object_remove_toggle_ref() twice because now Dispose(true)
could call ToggleRef.Free() directly bypassing
ToggleRef.QueueUnref(). This change makes sure that
the ref is removed from the PendingDestroys list.
When Gtk.Object was removed, most of the code was moved to Gtk.Widget.
But the part that deals with floating references actually belongs in
Glib.InitiallyUnowned.
This fixes various issues, in particular crashes in the TreeModelDemo
sample.
* generator/CallbackGen.cs: connect return value count parameters
* generator/ManagedCallString.cs: out count params aren't special
* generator/MethodBody.cs: don't finish hidden params
* generator/Parameters.cs: explicit IsCount setting support, with
Parameters.GetCountParameter(name) interface. Clear IsCount
values during validation if they have no associated array. Any
remaining count params must be associated with a retval, so
hide them.
* generator/ReturnValue.cs: support array_length_param attribute to
associate a return value with a "count" param. Use new helper
methods to marshal these array retvals to IntPtr and back.
* glib/Marshaller.cs: support for byte[] marshaling to and from
IntPtr using a count and type in the from native direction.
* gtk/Gtk.metadata: mark TextBufferSerializeFunc return type as
an array with the length specific in the length param.
The replaced code fails because sizeof(GValue) is 20 on 32 bit
linux but Marshal.SizeOf(GLib.Value) reported 24. If it aint broke,
don't fix it, and the long works on 32 and 64 in 2.12 and earlier.
