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
