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#.
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.
This makes the code 64-bit clean (instead of assuming that a pointer
fits in a Int32) and simplifies the code.
Although the GTK doc doesn't say so, the C code shows the array is NULL
terminated, so we should be OK here.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
There are no real code changes in this commit, just a lot of file
renaming and boilerplate additions.
A few .custom files are just removed, because the corresponding class in
GTK is gone, so they were not really used anymore.
Some files need to be re-indented, but that will be done in a separate
commit, so that git can track the renamed files correctly and not be
confused by all the changes.
A few properties would not be generated, as a property with the same
name already exists in the Widget class. To resolve this, we mark the
corresponding accessors as new.
When creating a subclass of ComboBox with an entry, the has-entry
property was not initialized, leading to a crash when trying to access
the entry.
For subclasses of ComboBoxText, two other properties were not
initialized, leading to Gtk-CRITICAL error messages.
In gtksettings.c, properties are installed using a custom function. So a
few properties were added as custom code. Move those as a fixup, and add
all the other properties too.
The only missing properties now are gtk-im-preedit-style and
gtk-im-status-style, because their type is hidden.
G_DEFINE_TYPE_EXTENDED is the general macro for type implementations, on
which G_DEFINE_TYPE_WITH_CODE is based. Handle it just like
G_DEFINE_TYPE_WITH_CODE.
Reparse the API with that change, which marks a few classes as
implementing GtkStyleProvider.
Add ComboBox[Text] (bool with_entry) protected constructors to allow
subclasses with an Entry.
Add an Entry property for easy access to the Entry child widget.
Also remove the unused gtk/ComboBoxEntry.custom.
The interface parsing fix added a few properties on interfaces that have
no accessors. In this case, the code generated in the adapter for those
properties does not build: it tries to use (Get/Set)Property but they
don"t inherit from Glib.Object.
Hide those properties for now, until a proper fix is implemented. As
they were not available before, it's not that bad.
With the new G_DEFINE_INTERFACE macro, the interface initialization
function is named *_default_init, so we need to handle that like
*_base_init and *_class_init.
Reparse gtk/gtk-api.raw and gio/gio-api.raw. This creates some new
signals that were previously incorrectly reported as virtual methods,
and also adds some properties.
The action area is created as a GtkButtonBox, so casting it to a
GtkHButtonBox doesn't work. And GtkHButtonBox is going to be deprecated
in 3.2 anyway.
This fixes a crash when accessing Dialog.ActionArea. With this,
everything in sample/test seems to work OK.
