Add left/right/top/bottom style classes according to which edge(s)
of the progressbar the progress is adjacent to. Only for a fraction
of 1.0 will we set more than one edge.
xdg-shell has moved on and replaced set_margin with set_window_geometry.
To properly support set_window_geometry requires a full rewrite of how
we've been dealing with toplevel windows for now, so just don't set any
margin until we can have a proper toplevel window abstraction in GTK+.
Don't shadow existing variables. Instead of sharing the allocation and
then overwriting the width/height when convenient, declare it in the
block we use it in, as, really, the three different paths are all
extremely different, and there's no sense in sharing the variable.
We can't avoid calling set_titlebar in buildable_add_child, since
GtkBuilder assumes that it can e.g. call grab_default at the end,
which only works if the widget is inside a toplevel at that point.
Instead, drop the titlebar and clean up priv->headerbar in constructed
if we find that we don't want a headerbar.
find_by_log_attrs() can return true only in this case:
return moved && !gtk_text_iter_is_end (arg_iter);
So if the iter moved (i.e. something has been found), but is the end
iter, find_by_log_attrs() returns false.
Now the same checks are made in find_visible_by_log_attrs(). The public
functions using find_visible_by_log_attrs() say in their documentation
that false is returned for the end iter, hence the check with
gtk_text_iter_is_end().
https://bugzilla.gnome.org/show_bug.cgi?id=618852
attrs[len] is the last PangoLogAttr available, at the iter position after the
last character of the line.
For a line in the middle or the start of the buffer, the '\n' is taken
into account by 'len'. For example the is_word_end is generally reached
before the '\n', not after. But for the last line in the buffer, where
there is no trailing '\n', it is important to test until attrs[len].
The bug didn't occur before because find_by_log_attrs() worked directly
on the iter passed as the function argument. But now it is no longer the
case.
https://bugzilla.gnome.org/show_bug.cgi?id=618852
- Return true (found) and false (not found) explicitly.
- Set found_offset only when something has been found.
find_backward_cursor_pos_func() was a bit different, the while loop had
the condition "offset > 0" but the return was "offset >= 0". Probably a
micro-optimization, since offset == 0 is always a cursor position.
Anyway now the code is the same as the other functions.
https://bugzilla.gnome.org/show_bug.cgi?id=618852
Do not work with the iter passed as the function argument. Work with
another iter, and set it back to the function argument only if something
has been found.
This fixes a few unit tests. But there are regressions for a few others.
https://bugzilla.gnome.org/show_bug.cgi?id=618852
The Adwaita icon theme ships spinners in a scalable directory
with MaxSize=32 and Scale=1. One way to make them scale up in
hi-dpi would be to add an @2 directory with MaxSize=32 and Scale=2,
but that directory would also be consulted in non hi-dpi situations
and give us an effective spinner max size of 64.
Instead, treat svg icons implicitly as hi-dpi, and scale them
up to MaxSize * 2 when in hi-dpi.
This was causing menus to show up in the wrong position in case the menu
popped up towards the top and/or left.
The change to the requisition was in error; it is the allocated size
of the menu, not the toplevel, and doesn't include the shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=591258
This had originally been added to Adwaita in the gnome-themes-standard
commit 7bf01517bc2 but was lost during 3.13 theme changes, causing bug
591258 to reappear.
Like the autotools builds of the introspection files, don't include gtkx.h
in the introspection prepropcessing as it should not be included by other
GTK+ headers.
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.
