We now apply the .button style class to rows that are either
activatable or selectable. Selectable rows only get the .button
if the listbox allows selection. This implies that we need to
update row styles when the selection mode changes, or when the
row gets added to a listbox.
Having an explicit property for this will make it easier
to have a hover style only for rows which are activatable
or selectable.
Rows are selectable by default, to preserve compatibility.
It's hard to figure out what the "expected_reply" means except under
close examination -- it's actually talking about whether this was a
reply to a ConfigureRequest or not. The inversion in the check doesn't
help either.
Make the code cleaner by moving it above the freeze/thaw case, and
making the check more explicit and without a confusing variable. If we
haven't sent any ConfigureRequests out, then it must be a gratuitous
ConfigureNotify.
Some windows, like GtkWindow and some other apps, set a transparent
background. The guarantee for begin_paint_region is that there should
be a full clear to the specified background color, not a composite
against what was there before.
This fixes repaint artifacts in Wayland and Weston in a better way than
76922c169f.
Slapping file:// in front of a path does not guarantee a working
uri (e.g. if you are on windows and the path looks like F:\\...).
Therefore, go back to using g_file_new_for_path if we don't have
to deal with a resource.
It turns out that activate-on-single-click interferes with the
expected multi-selection behavior. Turn it off, since there's nothing
to activate in this list, anyway.
The animated scrolling interferes with incremental validation.
As short-term solution, disable scrolling animation during
incremental validation. This is not a proper solution, but
it avoids broken behavior like scrollbars that are not reacting
to clicks. The problem was visible, e.g. in the list view
example in gtk3-demo.
The animated scrolling interferes with incremental validation.
As short-term solution, disable scrolling animation during
incremental validation. This is not a proper solution, but
it avoids broken behavior like scrollbars that are not reacting
to clicks. The problem was visible, e.g. in the list view
example in gtk3-demo.
gdk_x11_display_set_window_scale() affects the interpretation of the
Xft/DPI XSETTING - it is substituted inside GDK with the value of
Gdk/UnscaledDPI xsetting. However, this change is not propagated to
GTK+ and from GTK+ back to gdk_screen_set_resolution() until the
main loop is run.
Fix this by handling the screen resolution directly in gdk/x11.
This requires duplication of code between GDK and GTK+ since we still
have to handle DPI in GTK+ in the case that GdkSettings:gtk-xft-dpi
is set by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=733076
Conceptually, text handles are boxes, whose content is a 'handle',
so draw background, frame and handle. With this, and the previous
commit, the cursor-handle theming in Adwaita now works as intended.
The text handles reuse the style context from their parent widget,
and just add .cursor-handle. That means that the more specific
entry selectors override the .cursor-handle theming unless we
select for .entry.cursor-handle. We also need to work harder to
keep the .entry styling from drawing decorations around the outlines.
The listbox code relies on the container focus adjustment handling
to scroll the cursor row on screen. But GtkContainer has no idea
about row headers, so ensure that we scroll the header on screen too.
