A problem with the zoom scroll mode is that you have to restart
if you hit the bottom of the screen before you hit the bottom
of your document.
This commit adds an autoscroll feature to the zoom scroll: if
you move outside the window while in zoom scroll mode, we keep
scrolling in the direction you were going until you let go
of the mouse button.
https://bugzilla.gnome.org/show_bug.cgi?id=704703
Triggering zoom scroll mode by Shift click was too much
of an easter egg. It also requires using keyboard and
mouse together, which is hard to do for many users.
Instead, we now trigger zoom scroll mode by click-and-hold
(or touch-and-hold).
https://bugzilla.gnome.org/show_bug.cgi?id=704703
The internal class GtkPressAndHold was so far only
reacting to touch events. But in most cases where
a touch-and-hold or 'long press' pattern is useful,
click-and-hold can also be used.
This patch makes GtkPressAndHold react to mouse
clicks as well.
https://bugzilla.gnome.org/show_bug.cgi?id=704703
Add a boolean property that controls whether a window close button
will be shown in the header bar or not. Doing this in the toolkit
will ensure consistency of the visual apperance.
https://bugzilla.gnome.org/show_bug.cgi?id=702971
If we don't dispatch the pending events then we can enter poll with events
still requiring to be processed and which can then lead to us deadlocking
there.
These files are generated, so adding them to git is somewhat
icky, but it helps translators who currently can't use intltool-update
on a fresh git checkout.
Don't specify packing properties for internal children.
This doesn't work unless the internal children are actually
direct children of the container (which we are about to
change for GtkInfoBar). Also, it is redundant, since we
just set the properties to the values they already have
anyway.
Packing properties in ui files are parsed and handled by
the container, which assumes that the child is a direct
descendant. For internal children, this is inconvenient,
because we don't want to reconstruct the entire internal
structure between the container and the child in the ui
file.
It would be best to not specify packing properties
in that case, but since existing ui files do this for
GtkInfoBar and we are about to change the internal
structure of GtkInfoBar, be more forgiving here.
This reverts commit fbbcb5c01b.
We will be doing this in gnome-settings-daemon itself instead,
as some X11 based platforms using GTK+ will want to override this.
Xsun is no longer shipped to customers, and Oracle/Sun's Xorg distribution
uses "Sun Microsystems" as the vendor name, so this hack is incorrect in
the more common recent cases.
We checked for G_IS_LOADABLE_ICON() before GDK_IS_PIXBUF().
Since we made GdkPixbuf implement GLoadableIcon, the special case for
pixbufs is never used, and the much much slower GLoadableIcon path is
taken instead. Move the GdkPixbuf one to be first to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=705320
Update the gtk-install-bin property sheets so that it does not "install"
the wrong GDK DLL/LIB when building a broadway-enabled GDK
when the non-Broadway GDK had been previously built.
Add the Visual Studio 2010 projects to build the GDK Broadway backend, just
like the Visual Studio 2008 project files in the last commit. Similarly,
split up the property sheets so that they are easier to maintain and can
be made more flexible for different build types. Also remove some unneeded
stuff from some of these items.
Also, fix the filter file completion for GTK, as a source file was excluded
for that and this was overlooked as it seemingly did not cause any trouble.
-Add Visual Studio 2008 projects and pre-configured gdkconfig.h for
Broadway builds
-Decouple the Visual Studio property sheets, to simplify maintenance and
enhance flexibility for different builds
Visual Studio 2010 projects updates will follow later.
