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>
This is a mono profiler module that can be used to detect when GTK or
GDK methods are called from a thread which is not the main GUI thread.
Thanks to Andrés Aragoneses for doing the work to bring this into Gtk#.
Switch the hash tables used to store fields, properties and methods to
strong-type dictionaries, and make them private. Make the necessary
adjustments in the subclasses.
The additional type information makes the code a bit more safe
and readable.
At least one bug is fixed by this: in ObjectGen, an invalid child
property could still be generated, as it was not removed from the hash
table.
This should cause no real change to the generated code, except maybe in
the order of some members.
