When filechooer is re-used (instead of being created and destroyed
every time it's needed), it might happen that the directory the
application wishes to initially show is the same directory that
was shown last time the filechooser was used. In that case, make sure
filechooser knows that it does not need to do its default "select $pwd
or $home" routine.
https://bugzilla.gnome.org/show_bug.cgi?id=766122
adds a paragraph to gtk_text_view_get_pixels_below_lines(),
describing how it can be used together with
gtk_text_view_get_pixels_above_lines() to get the total
amount of line spacing between two paragraphs.
https://bugzilla.gnome.org/show_bug.cgi?id=747206
Calling gdk_gl_context_realize() should always result in a valid result,
so we need to provide a default implementation, to avoid a call to a
NULL function pointer.
If the popover's relative-to widget is unparented/reparented, we end
up unparenting/reparenting the popover as well. In that case, at the
moment of reparenting, the widget might have been visible (and is
thus mapped again), but priv->window hasn't been set yet.
We must first set priv->window, and then call gtk_window_add_popover(),
that way gtk_popover_map() has its prerequisites straight.
https://bugzilla.gnome.org/show_bug.cgi?id=766323
gtk_widget_set_parent() will map the widget if the parent is mapped
and the widget is both visible and child-visible. As we currently
only set the child visibility after adding the child, we immediately
map all children that are added to a mapped stack, even when they
are not actually shown. Avoid this by setting the child visibility
before adding the child, so widgets are only mapped when shown.
https://bugzilla.gnome.org/show_bug.cgi?id=766737
Use g_drive_is_removable for external drives detection. Current heuristic
fails in some cases (e.g. when removable drive is attached before login),
see Bug 765457.
Bump GLib version accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=765924
When starting a rubberband selection from an empty area, we could run
into crashes if the selection moves over the rows and then back out
to unpopulated area. Handle this case without crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=766336
Use .marks-before/after to indicate the presence of marks.
As Lapo points out, compatibility with the previous names
is not really that important, since everything else changed
around it.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
Warn about the situation when we've found a resource or file path,
but gdk-pixbuf fails to give us a pixbuf. This generally means that
either pixbuf loaders are not found or the shared-mime database
is missing.
Given that Wayland has no global coordinate, the only way for gdk to
retrieve the monitor a window last entered is to retrieve it from the
GdkWaylandWindow itself.
Implement the backend specific get_monitor_at_window() to return the
monitor that was last entered by the window.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
In Wayland, surfaces get an enter/leave notification each time they
enter or leave an output.
Add an API to GdkWaylandWindow to retrieve the output the window has
last entered.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
Some backends (namely Wayland) do not support global coordinates so
using the window position to determine the monitor will always fail on
such backends.
In such cases, the backend itself might be better suited to identify
the monitor a given window resides on.
Add a vfunc get_monitor_at_window() to the display class so that we can
use the backend to retrieve the monitor, if the backend implements it.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
It turns out that it is too hard (and in some cases, impossible)
to get this information from node positioning, so bring back the
.scale-has-marks-above/below style classes on the main node.
This should allow us to fix the 'pointy sliders'.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
The GdkDragContext should only listen to GDK_GRAB_BROKEN events sent to
its own pointer device. It turns out that the passive key grabs mistake
GDK into sending a GdkEventGrabBroken on the master keyboard, which the
DnD machinery mistakes as a signal to cancel the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=766442
Only generate crossing events on wl_touch.down for the virtual master
device used for touch events, and only whenever this virtual device
actually moves across surfaces. This behavior resembles better what is
expected in X11, where the pointer is warped to the touch position
on XITouchBegin.
This avoids the double emission of leave events when the pointer
emulating touch is lifted, that crossing event will be instead
generated when/if the focus surface changes.
https://bugzilla.gnome.org/show_bug.cgi?id=766314
This is required for proper integration with any other library/application that
may perform wayland API calls and poll() the wayland fd from multiple threads.
Using wl_display_dispatch{_queue}() is thread-safe if not mixed with custom
poll() usage, which GSource/GMainContext does.
Essentially, the problem is that multiple threads polling and reading
the same fd is extremely racy. Use the wayland provided API for allowing
concurrent access to the wayland display fd.
See the wayland man pages for wl_display_prepare_read(),
wl_display_cancel_read() and wl_display_read_events() for more details.
https://bugzilla.gnome.org/show_bug.cgi?id=763852
GtkScrolledWindow leans towards using the minimum size of its child
widget, unless the scrollbar policy is GTK_POLICY_NEVER. This is
probably fine for most GtkScrollable implementations out there.
Especially when using GTK_SCROLL_MINIMUM, which is the default for all
implementations inside gtk+.
However, this is not good for GTK_SCROLL_NATURAL children. eg.,
VteTerminal's minimum size is 1x1 and natural size is the number of
visible rows and columns requested by the user. We really want to use
the natural size unless the user has resized the window to change that.
https://bugzilla.gnome.org/show_bug.cgi?id=766569
