The zoom/rotate change for quartz does not build on 10.7. This change
adds zoom/rotate support in quartz only for 10.8 and following. The
problems is described here:
https://bugzilla.gnome.org/show_bug.cgi?id=760276 and here
https://trac.macports.org/ticket/51052
NSEventPhaseMayBegin was only introduced in 10.8 although documentation
says it is introduced in 10.7. Tests on 10.7 indicate that the phase
property for the Magnify event is not supported at all on 10.7
This fixes a bug that was introduced by db1b24233e.
The reason why 0:0 coordinates were passed was that SWP_NOREPOSITION was
misinterpreted as SWP_NOMOVE. That is not the case - SWP_NOREPOSITION
prevents owner Z-order change, not the window position change.
gnome-control-center is calling gtk_window_resize() on configure-event
signals which leads to a busy loop.
Avoids such a busy loop by not re-configuring a window with the same
size, unless this is coming from and xdg-shell configure.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764374
This commit was found to make emacs windows shrink, but the reversal
caused more widespread damage than initially expected. I've send
suggested fixes to the emacs team, to avoid the shrinking window,
regardless of this commit.
Original commit message:
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
Commit cdc580463e made it so that
unresizable windows can't be smaller than a set default size but it
lost the logic to ensure these windows remain at least big enough to
comply with their requisition.
https://bugzilla.gnome.org/show_bug.cgi?id=764174
We were missing all of the status directories, and a few sizes.
This was causing us to not find image-missing on systems without
hicolor icon theme (this basically only happens on Windows).
https://bugzilla.gnome.org/show_bug.cgi?id=764378
e8aa9b0440 introduced a new debug mode
that highlights resizes. Unfortunately it has the side effect of
always queueing redraws even when the debug mode is not enabled.
Make the redraw conditional.
This is achieved by sending undocumented message WM_SYSMENU
to the window.
Before doing that, the window is given WS_SYSMENU style
(to enable window menu) and some combination of
WS_MAXIMIZEBOX (for "Mazimize" item)
WS_MINIMIZEBOX (for "Minimize" item)
WS_SIZEBOX (for "Size" item)
depending on which operations are currently permissible.
WM_SYSMENU is processed by DefWindowProc(), which results
in showing the window menu. We remove extra styles
at the first opportunity (WM_INITMENU message), as they
alter the way our window is rendered.
https://bugzilla.gnome.org/show_bug.cgi?id=763851
If a layered window was hidden and is made visible, erase its
contents before showing it. GDK will schedule a redraw, but until
then we generally don't want to show old contents.
https://bugzilla.gnome.org/show_bug.cgi?id=763783
Since we are really only interested in the center point of the
slider allocation, the pre-computed slider geometry is perfectly
fine, just use it always. This avoids the complication with
gadget visibility.
The slider gadget may be turned invisible as side-effect of
gtk_range_calc_slider(). If that happens,
gtk_css_gadget_get_content_allocation() returns { 0, 0, 0, 0},
which leads us to calculate a negative allocation for the highlight
node. Avoid this, by just reusing our already calculated slider
allocation in this case (it is not technically the same as the
content, allocation, but the difference hardly matter here.
https://bugzilla.gnome.org/show_bug.cgi?id=764022
These functions are supposed to return the numbers of consecutive
1 bits in each components mask as precision. However, due to a
copy-paste mistake when this code was moved around in
commit 70d689cddd, the precision
was always reported as zero. This affects only a few applications
that directly set window background on X11 windows, such as emacs.
https://bugzilla.gnome.org/show_bug.cgi?id=764210
