Had to change gapi2xml.pl to use the new properties method/macro in gtkwindow.c
- Issue, "invisible-chars" and "inner-border" is generated twice in gtkentry.c
Made patch to gwin32registrykey to use little endian by default. So Windows om ARM may fail.
GLib 2.32 has been released in March 2012, so we can now require it a
build and run time. This allows us to remove GLib 2.31 conditionals,
mark the Thread.Init as obsolete, and remove all references to
libgthread.
Please note that the API exposed in glib and gio is still from 2.28, but
we will have some API additions in the future. First example is the next
commit, which brings GBytes, an addition in GLib 2.32.
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.
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.
The only autogenerated AssemblyInfo files are in cairo and in
gtk-sharp's root, not inside other libraries like atk, glib, etc.
Removing them will make MonoDevelop stop rendering a red element
underneath each project.
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 values handled by those two methods are null-terminated arrays of
strings, owned by the caller, so mark them as such.
Signed-off-by: Bertrand Lorentz <bertrand.lorentz@gmail.com>
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.
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(...).
