The migration to generic collections [1] caused another regression: a
KeyNotFoundException was being thrown (instead of returning null like
HashTable did) when using the Destroyed event of the Gtk.Widget class.
[1] 6850b343ca
A particular example of this problem is Banshee's Import Media feature,
which was generating the following stacktrace:
[1 Debug 23:24:36.898] Starting - Importing Media
Marshaling activate signal
Exception in Gtk# callback delegate
Note: Applications can use GLib.ExceptionManager.UnhandledException
to handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown
by the target of an invocation. --->
System.Collections.Generic.KeyNotFoundException: The given key was not
present in the dictionary.
at System.Collections.Generic.Dictionary`2[System.IntPtr,System.Delegate].get_Item
(IntPtr key) [0x00000] in <filename unknown>:0
at Gtk.Widget.add_Destroyed (System.EventHandler value) [0x00000] in
/home/knocte/gtk-sharp/gtk/Widget.cs:333
at Hyena.Widgets.AnimatedWidget..ctor (Gtk.Widget widget, UInt32
duration, Easing easing, Blocking blocking, Boolean horizontal)
[0x0004d] in /home/knocte/banshee/src/Hyena/Hyena.Gui/Hyena.Widgets/AnimatedWidget.cs:78
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 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.
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.
