Use cursor names instead of font cursors, so we can also show
cursors that are not represented in the X cursor font and thus
don't have a value in the GdkCursorType enumeration.
This path is only intended to be triggered on events directed towards the
child of the scrolledwindow, so make it explicitly so. This avoids scrollbar
"over" state flashing when dragging finishes within the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=746961
The "app_id" of a xdg_surface should be the ID that can potentially be
used to get the DBUS name or the .desktop file.
For GtkApplication programs this is often the ID passed when creating the
GtkApplication object, so when available lets use that.
As fallbacks, first try g_get_prgname as it often corresponds to the
basename part of the .dektop file for non-GtkApplication programs.
Otherwise use gdk_get_program_class, even though that string usually
doesn't conform to the expectations of xdg_surface.set_application_id.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
If the icon happened to come from the drag site icon helper (ie. set through
gtk_drag_source_set_icon*), it would be referenced on the GtkDragInfo,
but not hooked into its context. This results on non visible drag windows,
until set_icon_helper() happened to be called on some path.
GtkRadioButton had a deficient copy of the focus sort code
in GtkContainer, causing focus to jump over the next button
in the list. Just use _gtk_container_focus_sort() here,
which fixes the bug _and_ saves 80 lines of code.
https://bugzilla.gnome.org/show_bug.cgi?id=746817
As of 74405cc, progress bars use a new design with values drawn on top
(or to the left) of the through instead of inside of it. This change
brought a number of regressions: the min-horizontal-bar-height and
min-vertical-bar-width style properties are not respected anymore. For
vertical progress bars, the value was drawn too close to the bar and not
centered vertically.
Fix this by respecting the style properties and drawing the value label
at the correct position.
Also, the xspacing and yspacing properties didn't server any apparent
purpose. Change their semantics to mean "the spacing between the label
and the bar". Hence, they only need to be added to the size request when
showing the label. Since we are changing semantics anyway, reduce their
default values from 7 to 2, to avoid and excessive gap.
https://bugzilla.gnome.org/show_bug.cgi?id=746688
Make it possible to control libcanberra support so we don't risk ending up with
a cyclic dependency when using packages: gtk+ -> libcanberra-gtk3 -> gtk+
https://bugzilla.gnome.org/show_bug.cgi?id=746904
As it is, GtkListBox model binding will work nicely as long as your
create_widget_func returns a floating reference on the newly-created
widget.
If you try to return a full reference (as any higher-level language
would do) then you will leak that reference.
Fix that up by converting any floating references into full references
and then unconditionally releasing the full reference after adding to
the box.
https://bugzilla.gnome.org/show_bug.cgi?id=746893
If the GLX_EXT_texture_from_pixmap extension is not available when we
did the extensions check, then there's no point in using the backend
specific code paths that rely on it.
Use screen workarea to *also* set the position of a maximized window,
not just its size. Without this the window position defaults to 0:0
(the topleft corner), which is wrong when taskbar is position along the
top or left edge of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=746821
I managed to stall recent files today while trying to save a GTK
testcase in glade that contained enough spinning spinners that the CPU
was saturated just redrawing things.
I had to navigate the filesystem!
The direction in which the slider moves can be inverted by setting the
inverted property. But the draw method does not check this, instead it
checks if the direction of the widget is set to be right to left.
Call the should_invert function in order to determine if the direction
of the range should be inverted. It too checks the widget's direction,
but also checks the "inverted" property, and allows the range to be
drawn inverted even if it is vertically oriented.
https://bugzilla.gnome.org/show_bug.cgi?id=746712
Put the equality check in front. This allows better detection of when an
insert or delete needs to be emitted.
Also, only emit text-changed:delete if the deleted text is not the empty
string. Only emit text-changed:insert if the inserted text is not the
empty string.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
