Some types need special methods to convert an object to a GLib.Value.
The type system will look for a SetGValue method with a "ref GLib.Value"
parameter and invoke it.
A special case in the generation is needed because this is a non-static
method with the Handle being passed as the second parameter and the
GLib.Value as the first. Without this fix, the generator would generate
the Handle for the first parameter and then the GLib.Value.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
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>
If the parent already has a GType property, add a "new" keywords to hide
it.
This eliminates a lot of warnings when using classes derived from
Opaque. Closes issue #100.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
A static getter method would always generate a Handle parameter even
though some types do not have a Handle, for example structs.
Closes issue #99.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
Fixed length arrays are available in gobject introspection and are
already converted by the bindinator tool. The array_len attribute was
only used in structs.
This adds support for them as method parameters, generating the correct
code for them. Fixes issue #98.
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.
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.
The default value for the "platform" parameter is anycpu, which allows
the runtime to use the 64-bit mode on x86_64. This means that any
P/Invoke will only work with 64-bit native libraries.
The recommended version of native Windows binaries provided by the GTK+
project are 32-bit, so a Gtk# app running on 64-bit Windows will fail to
load them, causing a BadImageFormatException at runtime.
Using "-platform:x86" instructs the csc compiler to set a flag in the
generated assembly that instructs the runtime to use only 32-bit mode.
Please note that there are 64-bit GTK+ Windows binaries, but they are
marked as experimental, and we probably don't want explore this right
now.
Also pass the "nologo" parameter so that it doesn't output several
useless line when it is invoked.
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.
The -mno-cygwin parameter has been obsolete for quite some time. It is
now gone in recent gcc version, causing an error when you try to use it.
My understanding that gcc now does the right thing automatically.
Having parameters starting with a forward slash seems to break when
building with MinGW on Windows. So we use a dash to be consistent with
other Makefiles.
Also use the CSFLAGS variable in the sample/gio Makefile, instead of
hardcoding the debug flag.
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.
For method with optional parameters, when generating the overload
without the optional parameters, mark the overload as static if the
original method is static.
It was used to automatically document the Finalize methods, which do not
exist anymore. We are now using the standard Dispose pattern, and the
Dispose methods only appear in a few places, so they can be documented
manually.
Potentially all these IDisposable classes could be used after being
disposed, which would result in native crashes. We now do an explicit
check and throw an exception in managed land when the object has been
disposed.
This is particularly useful because:
a/ the native crashes are quite obscure, there no indication that
you're using a disposed object
b/ Gtk# is passing Context instances to user methods, and disposes them
when the method returns. So if the user code keeps a reference to the
Context, there a good chance it will try to use it after it's disposed.
Other changes in this patch include:
* Renaming a parameter to be more consistent with the other subsequent
ctor called.
* Replacing implementation of some [Obsolete()] methods with the call
to the methods they were replaced with, to avoid redundancy and the
need for more CheckDisposed() calls than necessary.
* Throw ArgumentException when receiving an IntPtr.Zero as a handle,
as a way to protect ourselves from wrapping invalid native pointers,
and throwing ObjectDisposedExceptions because the object was invalid in
the first place.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
The sample writes the same PNG file over and over, with some pauses in
between iterations. Some indicative numbers are written to the console,
to help track performance and memory usage.
Feel free to add more elaborate drawing to this sample, to exercise more
of the cairo API.
A similar situation to what is described in commit e48ac63d54 also
happens with signal callbacks: some signals are passed a native object
that is wrapped in an IDisposable managed object, which is then passed
as an argument to the signal handler. We need to dispose those objects
when the signal handler is done.
Those parameters will now be disposed in a finally {...} block, after
the signal handler has returned. This means that handlers should not
keep a reference to such a parameter, as it will be disposed right after
they return.
This change only affects the Cairo.Context parameter of the Widget.Drawn
signal, but it was badly needed, as shown by the Pixbuf demo in the
GtkDemo sample, which was leaking tens of MBs of memory.
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>
