Those functions aren't as useful anymore, hiding/showing can be
controlled by setting the widget visibility, and grabbing can be
achieved by performing a GTK+ grab.
GdkWindows are gone now from the API, the pointed_to rectangle
is from now on relative to the widget allocation. GtkTextView
and GtkEntry were updated to adapt to this change.
This is not as necessary now that bubble windows are popovers, if
a modal behavior is wanted on popover contents, a GTK+ grab on the
popover widget will suffice.
Popovers are transient floating widgets that are confined to the
window space. These have their own GdkWindow that is set on top
of the regular window contents, so they can be used for popup menu
alike UIs with custom popup/popdown/grabs behavior.
Stop trying to deal with "theoretical possibilities".
We can't possibly continue to be a faithful GActionGroup implementation
across dispose because dispose has a side effect of removing everyone's
signal handlers.
The code that we ran after the dispose chainup to do all of the fancy
signal emulation was therefore dead. The test that aimed to verify this
was buggy itself due to an uninitialised variable, so really, it never
worked at all.
We keep the re-ordering of the chainup from the original commit to avoid having
trouble with GtkActionMuxer and keep the checks in place that will prevent an
outright segfault in the case that someone else tries to use the interface
post-dispose.
https://bugzilla.gnome.org/show_bug.cgi?id=722189
With proper notifications, plus an accessor method for that state. This
allows client to just listen to notify::is-maximized instead of tracking
window-state-event.
https://bugzilla.gnome.org/show_bug.cgi?id=698786
This leads to disastruous results, since each menu is itself
in a GtkWindow, so holding down the menu key leads to a neverending
cascade of menus on top of menus.
https://bugzilla.gnome.org/show_bug.cgi?id=722106
Theming code gets confused when computing the spacing for 0px wide dots
and then divides by 0. And then cairo complains and stops drawing
anything forever out of spite and then we end up with a single color
screen.
https://bugzilla.gnome.org/show_bug.cgi?id=721800
Rename testsrules_msvc.mak to detectenv_msvc.mak and remove some package-
specific stuff from it, to reflect on the nature that this NMake Makefile
is shared.
The current approach of building the introspection files for GTK works, but
is often cumbersome as one needs to set many environmental variables before
launching a solution file, which runs a Windows batch script to generate
the .gir/.typelib files. It was also possible to hand-run the batch script
from the Visual Studio command prompt, but even more environmental
variables need to be set.
This changes the approach to build the introspection files using an NMake
Makefile (but elimating from the Visual Studio Project Files the part to
build the introspection files) to:
-Make it clearer to the person building the introspection files what
environmental variables are needed, specifically for PKG_CONFIG_PATH and
MINGWDIR and CFG (formerly CONF). Setting stuff like VSVER, PLAT and BASEDIR
is no longer required, which was a bit clunky.
-Allows some more easier flexibility on the build of the intropsection files.
Make sure the needed public headers for GTK master is "installed", and re-
order some items so that it is easier when the headers lists are
automatically acquired from the various Makefile.am's.
The EWMH defines _NET_WM_MOVERESIZE_SIZE_KEYBOARD and
_NET_WM_MOVERESIZE_MOVE_KEYBOARD for operations that are not
initiated by a button-press event. Allow using these by passing
a button of 0 to gdk_window_begin_move/resize_drag.
The window-dragging code had a number of issues: The code was
starting a drag on every button press, never bothering to cancel
them. This leads to the odd hand cursor occurring between the two
clicks to maximize. We relied on GDK's multi-click detection, which
gives us triple-clicks when we really want sequences of double-clicks.
Lastly, we didn't propery restrict double-click handling to the primary
button, so e.g. if you had a window on an empty workspace, double-right
click on the titlebar would maximize it, which is not intended.
This commit solves all three problem by a doing our own double-click
detection, and only starting a drag when the pointer goes out of
'double-click range'. We change the way dragging is implemented for
menubars and toolbars to just letting events bubble up, so they
get the same behaviour as the titlebar. To make this work, we
have to select for pointer motion events in a few more places.
