The font features demo started calling the Harfbuzz API directly
starting from commit 9de3b24c20. Harfbuzz
is an implicit dependency of Pango on some platforms, but it's not part
of the public dependencies; this means that we cannot expect to link to
Pango and automatically get Harfbuzz symbols to link against —
especially when things like --as-needed are in play.
This change triggered build failures on non-Unix platforms, fixed by
commit 2a9967731a, as well as build
failures in Continuous, with this error message:
/usr/lib/gcc/x86_64-gnomeostree-linux/4.9.3/../../../../x86_64-gnomeostree-linux/bin/ld:
font_features.o: undefined reference to symbol 'hb_tag_to_string'
//lib/libharfbuzz.so.0: error adding symbols: DSO missing from command
line
collect2: error: ld returned 1 exit status
In order to get the font features demo to build everywhere we should
take an explicit, though optional, check on Harfbuzz, and conditionally
build the font features demo with the right compiler and linker flags.
The fonts features demo now uses fontconfig APIs via PangoFT2, which makes
the code not build on non-Linux, so only include this demo in the build
on UNIX.
Use the common automake module from the previous commit in the
Makefile.am's, which means that the Makefile.am's in gdk/ and gtk/ can be
cleaned up as a result. As a side effect, the property sheet that is used
to "install" the build results and headers can now be generated in terms of
the listing of headers to copy during 'make dist', where we can acquire
most of the list of headers to "install", so that we can largely avoid the
situation where the property sheet files are not updated in time for this,
causing missing headers when this build of GTK+ is being used.
Also use the Visual Studio Project file generation for the following
projects:
gtk3-demo
gtk3-demo-application
gtk3-icon-browser
gdk-win32
gdk-broadway
gail-util
So that the maintenace of these project files can be simplified as well.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
Since demos.h is now generated according to the platform for which GTK+ is
built, don't distribute it. Generate a Windows-specific demos.h.win32 and
distribute that instead, in which the Visual Studio build files will copy
it to demos.h, so that the build will proceed normally.
https://bugzilla.gnome.org/show_bug.cgi?id=749622
To generate the icon cache files.
We want to avoid a dependency loop if possible; additionally, on some
Debian-based systems gtk-update-icon-cache maps to the GTK2 version of
the utility and the GTK3 version is renamed to
gtk-update-icon-cache-3.0.
To avoid a build dependency on GTK2, use the binary that we just built
in-tree.
https://bugzilla.gnome.org/show_bug.cgi?id=749593
GtkSidebar behaves internally much like GtkStackSwitcher, providing a vertical
sidebar like widget. It is virtually identical in appearance to the widget
currently used in GNOME Tweak Tool.
This widget is connected to a GtkStack, and builds its own contents as a
GtkListBox subclass, using the "title" child property to provide a consistent
navigatable widget.
Being a subclass of GtkListBox it benefits immediately from strong keyboard
navigation, and minimal changes are required for theming.
https://bugzilla.gnome.org/show_bug.cgi?id=735293
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
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.
This demo condenses the essentials of advanced management of
input events. Depending on the information available in input events,
this demo will try to represent as much information as possible for
those.
https://bugzilla.gnome.org/show_bug.cgi?id=719987
Emit the "changed" signal after 150 msecs, so that searching
through big lists, or doing online searches feels more responsive.
This is something already done in various applications to make
search-as-you type more responsive (gnome-shell, gnome-documents,
gnome-control-center, etc.). The 150 msecs is the value currently
used by gnome-shell, so keep it (invisibly) consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=700229
