Instead, use the monitor's work area.
This might have unforseen side effects that warrant a later revert, such
as:
- Apparently some WMs assume maximizing when a window is maximum screen
size.
- WMs might not shrink the window by the decorations' size when it tries
to be fullscreen.
- Applications might have buggy size request code that causes weirdly
sized windows.
Ignore the "show-desktop" property on GtkPlacesSidebar for the
defaultvalue test.
Currently, "make check" is passing because it runs the test under a xvfb
with no XSETTINGS provider, so we see the Gtk default value. No matter
what we set the default value to in Gtk, however, there will be some
desktop environment in which someone running the installed test outside
of an xvfb will get the wrong result. Best to ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
Change the GtkSettings default for "shell-shows-desktop" back to TRUE
and also change the default value of the "show-desktop" property on
GtkPlacesSidebar so that the defaultvalue test passes.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
Return values of g_variant_get_child_value() were not unreffed
correctly together with one value returned by g_variant_get().
Use g_variant_get_data() instead of copying each byte separately.
https://bugzilla.gnome.org/show_bug.cgi?id=712799
Scroll valuators were being just appended again and again, leading
to 1) a growing memory issue anytime a device changed 2) the first
scroll valuators to stay permanent on the application lifetime, as
the first stored valuators would always match.
https://bugzilla.gnome.org/show_bug.cgi?id=705203
This is so we always have the latest information given by XRandR (or other), and not
rely on Core protocol information that might not have been updated yet.
This is specially visible when a monitor is connected (less frequent) or disconnected
(much more frequent), callbacks on GdkScreen::monitors-changed that call
gdk_screen_get_width/height() could get the screen size previous to the monitor
rearrangement.
So in order to fix this, keep track of the latest monitors information, and calculate
the bounding box in order to know the screen size.
https://bugzilla.gnome.org/show_bug.cgi?id=715029
Passive grabs may take pointer focus out of the application, even though
the pointer didn't leave the window, but those events still trigger resetting
of the scroll axes. This is most visible with compiz, and possibly other
reparenting WMs, where passive grabs happen on the WM-managed window that
is a parent of the application toplevel.
As it is not possible to have scrolling happening on the timespan a passive
grab takes action, it is entirely safe for GTK+ to assume none happened if
it gets a crossing event of that nature.
https://bugzilla.gnome.org/show_bug.cgi?id=699574#c33
It's been reported in several applications that scrolling feels jerky
since commit cc7b3985b3.
Investigation reported that the combination of passive 4-7 button grabs
on the toplevel and the presence of native subwindows might trigger
too often crossing events from the child window to the toplevel and
back as scroll "buttons" trigger the passive grab. Those crossing events
would reset the scroll valuators rendering scrolling from jerky on
touchpads (where there's intermediate smooth events between the emulated
button ones) to ineffective on regular mouse wheels (where the crossing
event would reset the valuators right before the single smooth scroll
event we get is delivered)
So, only reset scroll valuators when the pointer enters the toplevel
(we only care about this when the pointer is on the window after it's
been possibly scrolling somewhere else), and it doesn't come from an
inferior.
The situations where this happened varied though, the native subwindow
could be one created explicitly by the application, or created indirectly
through gdk_window_ensure_native(). The latter was mainly the case for
evolution (through gtk_selection_set_owner()) and any GtkScrolledWindow
under the oxygen-gtk3 theme (through gdk_window_set_composited())
https://bugzilla.gnome.org/show_bug.cgi?id=699574
GtkAboutDialog highlights emails written as <...> and
urls written as http://... . gnome-terminal manages to
put <http://...> into its license text, which sadly
confuses the parser into running evolution on http://...
Fix things up far enough that <http://...> is now
recognized as url, and only the part inside the <> is
underlined (for email addresses, we include the <> in
the underline).
Add a GtkSetting for whether the desktop shell is showing the desktop
folder icons.
This is on by default because most desktop shells do show the icons on
the desktop. We already have a patch in gnome-settings-daemon to bind
this to the org.gnome.desktop.background show-desktop-icons GSettings
key which is off by default on GNOME.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
gtk_menu_tracker_add_items() fetched the action-namespace from the menu
item, but didn't pass it into gtk_menu_tracker_section_new() when its
internal namespace was still NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=712164
Don't recurse the mainloop in _gtk_tree_view_column_start_drag().
It doesn't serve any discernible purpose, and recursing the
mainloop from the flush-events phas of the frame clock breaks
frame synchronization with mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
If a queue_redraw() (invalidating a region, or the whole widget) was
called from the draw() call, it could get ignored if surface_dirty
existed, as it would then be updated, but destroyed right at the end of
the _gtk_pixel_cache_repaint(), leading the next call to
_gtk_pixel_cache_draw() have its call to repaint() be a no-op
(since there's no surface_dirty) and then simply draw from (non
updated) surface.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=711545
currently it's using the same sizes for natural and minimum, but it
happens that, when it's allowed to use the arrow, the minimum size
can be smaller than natural.
https://bugzilla.gnome.org/show_bug.cgi?id=693227
Although I can't find explicit documentation for clipboard pointer, it
seems to be possible to modify clibpoard memory without side-effects.
According to MSDN,
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366596%28v=vs.85%29.aspx
"The global and local functions are supported for porting from 16-bit
code, or for maintaining source code compatibility with 16-bit
Windows. Starting with 32-bit Windows, the global and local functions
are implemented as wrapper functions that call the corresponding heap
functions using a handle to the process's default heap."
"Memory objects allocated by GlobalAlloc and LocalAlloc are in private,
committed pages with read/write access that cannot be accessed by other
processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is
not actually shared globally as it is in 16-bit Windows. This value has
no effect and is available only for compatibility. "
https://bugzilla.gnome.org/show_bug.cgi?id=711553
