gtk-update-icon-cache is no longer used at build time, so a lot
of the complicated machinery we have around that (conditional
build, cross build, etc) are no longer required.
It doesn't report -I${prefix}/include in cflags, even if .pc
files explicitly put it there. This was breaking the build
outside of a jhbuild shell when libepoxy is in the jhbuild tree
but not in /usr.
If we want to use OpenGL in GDK then we have two choices; either:
- find the GL headers on each platform
- do extension discovery
- implement all the crazy dlopen()/dlsym() dispatch tables
*or* use libepoxy, which shields us from all this madness and provides a
decent layer for GL clients to use, without creating its own namespace.
Epoxy is also used by other projects, like Xorg and piglit, and it's
portable to all the platforms GDK cares about.
https://bugzilla.gnome.org/show_bug.cgi?id=119189
As a noinst_PROGRAMS, the libtool generated for cross-compiling will be
used, which will mess up the linking. Create a all-local target instead.
Also ensure that building uses always a native version of the tool by
specifying a GTK_UPDATE_ICON_CACHE automake variable.
Finally "config.h" has been created to work for the target platform and
causes problem when cross-compiling. So we temporarily generate a basic
config.h which contains only the strict minimum.
Make the Visual C++-related build files contain the actual GTK+ version, by
generating them during the configure stage and dist'ing them in the release
tarballs. This is especially important for builds of introspection files,
as one may need to look at the release version of GTK+ in those files.
For that to happen the libgtk3 is embedded with a manifest that requests
common controls library 6.x, and GTK lazily calls InitCommonControlsEx()
to initialize those. Then this manifest is used to temporarily override
the process activation contest when loading comdlg32 (which contains the
code for the print dialog), ensuring that it too depends on common
controls 6.x, even if the application that uses GTK does not.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
This adds a new test which can be scripted to trigger various
event and action sequences, and record state changes in the
accessibility layer.
So far, there are a few tests verifying state changes when
focus changes.
Related to https://bugzilla.gnome.org/show_bug.cgi?id=715176
Move bloatpad to ./examples/bp/ so that we can start treating it as more of a
"normal" app instead of just jamming everything into a single .c file.
We don't use the name "bloatpad" for the directory in order not to
create 'git pull' pain with the probably-already-existing executable of
the same name.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
As the Visual Studio 2012/2013 are only slightly different from the Visual
Studio 2010 projects, we can provide support for them by using scripts to
copy the Visual Studio 2010 projects, and update the specific parts as
necessary.
Thus, there would be little maintenance overhead for these as only the 2010
projects need to be kept up-to-date as a result. This might change when we
do get the stack working with WinRT/Metro, but that's going to be another
totally different issue.
