This binds all the '*-set' properties. The properties are useful when one
wants to restore a previously set property to its initial value. For instance,
when setting the ForegroundRgba property the 'foreground-set' property is
automatically set to 'true' but when we assign 'Gdk.RGBA.Zero' to ForegroundRgba then the
'foreground-set' property is NOT set to false and the foreground becomes black instead
of the default one.
{List,Tree}Store.AppendValues overloads which take System.Array as their
'values' parameter incorrectly pass the array down to SetValues. The latter
expects a 'params object[]' array of parameters but passing an instance of
System.Array to such method will NOT pass the contents of System.Array instance
into the 'params' method as separate members of the parms array. It will instead
box System.Array and the params method will receive one parameter of type
System.Array instead of X parameters of various types. This affects the
following example code:
var store = new TreeStore (typeof (string), typeof (int));
store.AppendValues ("One", 1);
If the column configured to retrieve the 'string' value reads data from this
store it will instead get an instance of System.Array and the node displayed by
the TreeView will have no text, won't be clickable etc.
The fix implemented here is to "explode" the System.Array into a separate array
of the 'object[]' type.
The 'TreeStore.AppendValues (params object[] values)' overload no longer calls
the 'TreeStore.Appendvalues (Array values)' overload since the indirection only
wastes time and memory. It now directly calls `SetValues`.
Had to change gapi2xml.pl to use the new properties method/macro in gtkwindow.c
- Issue, "invisible-chars" and "inner-border" is generated twice in gtkentry.c
Made patch to gwin32registrykey to use little endian by default. So Windows om ARM may fail.
Gtk.Builder crashes when AddFromString(string) is called with a string
that contains a BOM. Hence, if the buffer contains a BOM, just skip it.
This fixes the crash with the Gtk# 3 project template in MonoDevelop
(robpvn/MonoDevelopGtkSharp3Template).
This allows consumers to specifically require gdk-sharp-3.0 without
having to pull in the full gtk-sharp-3.0.
Closes issue #101.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
Without that change, using ListStore.SetValue with a long would use the
float overload, which might not be expected and cause some issues.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
When dealing with several namespaces there might be classes with the same name
(especially Global which is autogenerated in g-i based bindings). On generation
the file would be overriden by the last occurence in the xml. To encounter
this every namespace has it's own directory now. This also improves structure
a lot when dealing with big libraries.
Also do the necessary adaption for the build and the csproj files.
In Windows builds of GTK+ 3.x, the dll filename is libgtk-3-0.dll.
We use this opportunity to use a common const in the DllImport
statement for all custom code.
This reverts commit 21bfaa7a9d.
After fixing the memory leak when finalizing a Context object in the
previous commit, native crashes would happen when using a Gtk#-based
app. The reason is that this commit tried to fix the leak with the wrong
approach of marking the CairoContext as owned. This avoided the leak by
not incrementing the reference count, but now that the leak is fixed,
cairo_destroy is called one time too much.
The CairoContext passed in the Draw signal is not marked as
transfer-ownership=full in GObject-Introspection metadata. So unmarking
this as owned fixes the "potential double-free" assertion that was
causing the crash.
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.
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
