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
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
* gtk/gtkprintunixdialog.c (printer_status_cb): Do not reset the
waiting_for_printer on status change as the default printer might
get added later.
https://bugzilla.gnome.org/show_bug.cgi?id=577642
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).
gtk_container_remove_child() is not enough to break the reference cycle
between the removed menu item and the submenu that is attached to it.
Use gtk_widget_destroy() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=710754
For some widgets, like GtkTreeView, which setup a clock frame
update during realize, it was possible to call
gdk_frame_clock_begin_updating() twice, but only ever disconnecting
from it once. This happens because the realized flag is set at an
unpredictable time by the GtkWidget's realize implementation.
Keep the signal handler ID from us connecting to the "update" signal
to avoid connecting to it twice.
This fixes high wake-up count from any application using GtkTreeView,
even idle ones.
https://bugzilla.gnome.org/show_bug.cgi?id=710666
When showing a tooltip on the edge of a monitor, the tooltip could be wrongly
placed and be shown going from one monitor to the next.
This happened because the current_window wasn't set visible, and when it wasn't
the returned allocated size would be 1, hence wrong calculations.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=698730
When loading a symbolic icon, g_file_get_contents() is currently used
with the icon pathname, to load its SVG data. This won't work when the
icon is not a local file, for instance when a symbolic icon is loaded
from a GFileIcon with a GResource path.
Fortunately GtkIconInfo already holds a GFile, so we can just use
g_file_load_contents() to load the data instead.
https://bugzilla.gnome.org/show_bug.cgi?id=709056
If we start with a padding of -1 then it can leak out of the size
allocation request for the column when the treeview is empty. The
GtkTreeView will then collect these -1 values and add them together,
returning -n where 'n' is the number of columns.
This is usually not a problem because treeviews tend to be used with a
scrollbar and the width of the scrollbar will be added to this number
bringing it into positive territory again. On Ubuntu, with overlay
scrollbars, this is not the case, however.
https://bugzilla.gnome.org/show_bug.cgi?id=703062
Previously, when you clicked and held the button down on a
GtkExpander's label or disclosure triangle, then moved the mouse
away and released the button, the expander would still activate.
This brings the behavior in line with the more generally expected
behavior, as exhibited by GtkButton for example.
https://bugzilla.gnome.org/show_bug.cgi?id=706345
* gtk/gtkwidget.c: drag-leave signal: Document that it is called before
drag-drop.
drag-data-received signal: Document that it is up to the application
to know why the data was requested (e.g. drag motion or drop).
* demos/gtk-demo/toolpalette.c: interactive_canvas_drag_drop():
Do not transform the drop_item created in the drag-motion handler.
Instead caused drag-data-received to be called, remembering why,
and create a new item there.
interactive_canvas_drag_leave(): Remove the idle-handler hack,
now that we do not need to keep the drag-motion drop_item alive until
the drop.
I noticed that this patch was sitting in bug #605611 from 2009
though it had been approved. I do not remember much about why I
created it.
Pass the master device instead if the last slave is NULL. This is
unlikely to happen in most of the cases, but can happen when running
unit tests where there's no pointer interaction to update the last
slave.
https://bugzilla.gnome.org/show_bug.cgi?id=696756
It tests gtk_text_buffer_paste_clipboard(),
gtk_text_buffer_copy_clipboard() and gtk_text_buffer_cut_clipboard() in
various situations, including when GtkTextTags are applied to the
selection.
The last test didn't pass.
https://bugzilla.gnome.org/show_bug.cgi?id=339539
It is more logical to first delete the selection and then pasting the
text. When the selection and the text contain tags, the new behavior is
more natural.
A segfault in paste_from_buffer() is also avoided. The segfault occurs when
the text to paste is deleted because it is the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=339539
A proper name or label is required. In the same way, if the
widget is labelled, ATs uses to expose both the label and the
name, making the final output not really user-friendly.
https://bugzilla.gnome.org/show_bug.cgi?id=707872
Call gtk_widget_get_mapped() in a couple of places before looking at the
widget's parent, since it might be set to a widget that has been
finalized, causing an invalid read.
