Without that change, using ListStore.SetValue with a long would use the
float overload, which might not be expected and cause some issues.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
When dealing with several namespaces there might be classes with the same name
(especially Global which is autogenerated in g-i based bindings). On generation
the file would be overriden by the last occurence in the xml. To encounter
this every namespace has it's own directory now. This also improves structure
a lot when dealing with big libraries.
Also do the necessary adaption for the build and the csproj files.
In Windows builds of GTK+ 3.x, the dll filename is libgtk-3-0.dll.
We use this opportunity to use a common const in the DllImport
statement for all custom code.
This reverts commit 21bfaa7a9d.
After fixing the memory leak when finalizing a Context object in the
previous commit, native crashes would happen when using a Gtk#-based
app. The reason is that this commit tried to fix the leak with the wrong
approach of marking the CairoContext as owned. This avoided the leak by
not incrementing the reference count, but now that the leak is fixed,
cairo_destroy is called one time too much.
The CairoContext passed in the Draw signal is not marked as
transfer-ownership=full in GObject-Introspection metadata. So unmarking
this as owned fixes the "potential double-free" assertion that was
causing the crash.
This commit makes it possible to build any project of the gtk-sharp.sln
from an IDE (except audit and sample projects, which require a bit more
work).
This doesn't mean that autotools is deprecated, but just that it is more
comfortable to use an IDE when working on gtk-sharp because it will
offer better auto-completion, and will stop highlight misleading
semantic errors, from now on.
At application shutdown, it's very likely to be spammed by
gui-thread-check with a river of:
*** GTK CALL NOT IN GUI THREAD: Widget.Dispose
*** GTK CALL NOT IN GUI THREAD: Widget.remove_InternalDestroyed
*** GTK CALL NOT IN GUI THREAD: Widget.Dispose
*** GTK CALL NOT IN GUI THREAD: Widget.remove_InternalDestroyed
...
From what I gather, these two methods (in gtk-sharp master[1]) could
be called by the finalizers, but do not call any unmanaged functions,
so it should be ok to not report them as violations.
[1] https://github.com/mono/gtk-sharp/blob/master/gtk/Widget.cs
Cherry-picked from 77a40599ca
Using fflush() right away after printf() calls avoids the buffers to
be written in an apparently complete-out-of-sync way from the point
of view of the developer. This problem would specially occur when
redirecting all output to a file this way:
mono Foo.exe > out.txt 2>&1
Without this fix, all the output from gui-thread-check would appear
at the end of the file, instead of in between the output generated by
the program.
Cherry-picked from 6988cd4cd2
As GtkTextIter has no public properties, the default generated Equals
implementation would be "return true;". We now suppress that and with a
fix-up now use the native gtk_text_iter_equal to implement the Equals
method.
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.
