Using regular expressions for targets is not supported, that's why now a
generated-stamp is used to determine whether the files have been
generated. This bug might not be related to osx but newer automake
versions at least >= 1.14.1
This allows you to avoid ugly calls like "NewArray (null, some_array)"
when you want the child type to be determined by the first element of
the children array.
Also throw specific exceptions when both type and children parameters
would be null.
This also demonstrates the use of Gtk.Builder to load .ui files.
Also simplify handling of resources in GtkDemo build: we don't need to
make a distinction between images and other resources.
The main difference with the C demo is that we can't use GResource, as
it's only in gio 2.32 and later, so '@import url("resource://...' won't
work. Instead, we use a separate CssProvider to apply reset.css.
Create 2 makefile variable to facilitate build on Windows:
GENERATED_SOURCES_FILES to match files created by the code generator,
and GENERATED_SOURCES_OPTION for the corresponding option to be passed
to the compiler.
Also adapt the makefile for the valtest sample to use these variables.
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.
Having parameters starting with a forward slash seems to break when
building with MinGW on Windows. So we use a dash to be consistent with
other Makefiles.
Also use the CSFLAGS variable in the sample/gio Makefile, instead of
hardcoding the debug flag.
The sample writes the same PNG file over and over, with some pauses in
between iterations. Some indicative numbers are written to the console,
to help track performance and memory usage.
Feel free to add more elaborate drawing to this sample, to exercise more
of the cairo API.
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 parser will be going away at some point in the future, but we
will still need the fixup step. And the fixup step is really more
of a preliminary step for the generator anyway.
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 structure of a GAPI XML file is now defined by the XML schema in
gapi.xsd.
This XSD is now used by the generator to do a first sanity check on an
XML file before trying to generate code from it. Each generatable object
still does its own validation.
The XSD can also be seen as a documentation of the GAPI XML format, and
can be used by third-parties that produce GAPI XML to validate their
output.
Bundle Options.cs from the Mono source tree, and use it to parse the
command-line options for gapi-codegen. This gives us clearer code,
descriptions for each option, and a nice "--help" output.
This does not change the options syntax, except that -I|--include needs
to specified for each file to include. Two Makefiles in sample/ are
updated for that change.
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.
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.
Make the custom widget a generic class, and add and use a derived class.
Also add a second instance of the custom widget, to better test the
interface properties support.
The drawing area is automatically cleared to the background color, so we
don't need a Drawn callback to do it ourselves.
Preserve the color selected in the color selection dialog, so that it's
pre-selected the next time the dialog is opened.
