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.
This is regenerate at every build (from Makefile.am) so
there's no need to store it in the repo. It must have been
included by mistake during the move.
As we now use partial classes for custom code, we can put additional
interface implementation declaration in the custom code, instead of
adding it through a fix-up.
Side-note: I thought about moving to IEnumerable<T>, but ListStore is a
list of objects anyway, and Container is an array of Widgets, so there
wouldn't be much benefit from type safety.
When a C function returns an array, we need to be able to determine its
length. This is done either through a parameter to that function, or
because the array is null-terminated. If we don't know about either of
those, we print out a warning and fail the validation for the return
value. This means the corresponding method will not be generated.
This fixes a crash when trying to generate a method for which this
information is missing.
This wasn't a problem until now because the parser doesn't handle array
return values, so they were always handled through fix-ups. But now we
can get a GAPI XML converted from GIR which contains the "array"
attribute for a return value but no other information.
In a lot of places, we were only checking the presence of boolean
attributes, like "array", automatically assuming they were true. This
meant that we didn't allow setting them explicitly to false, which
apparently is needed for some bindings.
For all boolean attributes, we now use the GetAttributeAsBoolean method
added in the previous commit, to correctly check the value of the
attribute. As before, if the attribute is not present, it is considered
to be false.
Thanks to Stephan Sundermann for noticing this issue.
