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.
The values handled by those two methods are null-terminated arrays of
strings, owned by the caller, so mark them as such.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
The gen-apidiff-html tool takes all apidiff files in a directory, merges
them and then applies mono-api.xsl to produce a nice HTML page that
shows the information about the API changes.
The various resources needed by the HTML page (images, CSS, javascript)
are added in the html/ directory.
This is all adapted from an older version of the tools in Mono git
master, under mcs/tools/corcompare.
Copy latest versions of mono-api-info.cs and mono-api-diff.cs from Mono
git master, along with associated classes. As a consequence,
mono-api-info.cs now depends on Mono.Cecil.
Do the necessary adaptation for our use case: we do API comparison
between version of our assemblies.
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>
The structure of a GAPI XML file is now defined by the XML schema in
gapi.xsd.
This XSD is now used by the generator to do a first sanity check on an
XML file before trying to generate code from it. Each generatable object
still does its own validation.
The XSD can also be seen as a documentation of the GAPI XML format, and
can be used by third-parties that produce GAPI XML to validate their
output.
This fix-up applies the element_type attribute to the method itself,
which is invalid. The correct fix-up that applies it to the return-type
is already there.
With a new --schema option, you can specify the path to an XSD file, and
all GAPI XML files will be validated against this schema, including the
files given through the --include option.
The third and fourth parameters of the Rectangle constructor are width
and height, but cairo_stroke_extents and cairo_fill_extents give right
and bottom coordinates.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
Bundle Options.cs from the Mono source tree, and use it to parse the
command-line options for gapi-codegen. This gives us clearer code,
descriptions for each option, and a nice "--help" output.
This does not change the options syntax, except that -I|--include needs
to specified for each file to include. Two Makefiles in sample/ are
updated for that change.
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.
Fix-ups to improve the DBus.Address* method names.
For example, DBus.GetStream(string address ...) is clear enough and
better than DBus.AddressGetStream(string address ...).
Static methods corresponding to g_simple_async_report_* functions were
automatically grouped into the badly-named Simple class.
Add fix-ups to hide this Simple class, move the methods to
SimpleAsyncResult and rename them accordingly.
Don't generate a static field if it's not going to be used.
This fixes a compilation warning on the generated code for interfaces
that don't have virtual methods.
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.
Wen generating a virtual method, the current member was not set in the
GenerationInfo. That caused the warning message about the callback scope
to refer to a wrong method name.
The Group property for all the Radio* classes (RadioAction, RadioButton,
RadioMenuItem and RadioToolButton) was exposed as a GLib.SList,
with its elements untyped.
We now hide the various Group properties and have custom code to handle
them correctly.
The values found by the parser for the GSocketFamily enum are in fact
constants defined in another header file, so the generated code would be
invalid.
We now hardcode the values through fix-ups. They probably don't
change, and they are also hardcoded in the gir file anyway, so it should
be OK.
Also fix-up a GInetAddress constructor that now gets generated.
The implementor class is not generated correctly, because of some
strangeness with the method names. And I don't think anyone would need
to implement it.
For properties, the parser guesses the type name from an all-caps macro
name. So if the GType has a funny name, like dbus -> DBus, the property
type is wrong.
The parser automatically groups static functions with the same prefix
into classes, but the right name can't be determined automatically.
In this case, ContentType.GetDescription(...) is much better than
Content.TypeGetDescription(...).
Add a sample to illustrate the point of having a
GLibSynchronizationContext, but with the async/await code ifdef'ed out
because we don't require Mono 3.0 for now. Instead, provide a crude
equivalent of what would be generated by the compiler, to show that it
works.
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>
