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.
