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.
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.
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.
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.
Use gtk_text_iter_set_line_offset (&tmp_iter, 0) instead of
gtk_text_iter_get_line(). The difference should not be big. In the first
case the line doesn't need to be traversed thanks to the offset 0. For
get_line(), the btree must be traversed.
A temporary iter is needed to not break the behavior. But the behavior
is quite strange, the function works directly on the iter passed as an
argument to the function, even if the function returns FALSE (not
found). So maybe a later commit will fix this strange behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=629129
find_by_log_attrs() was a recursive function. It is replaced by an
iteration.
The already_moved_initially parameter was TRUE only for the recursive
call, so the paramater is removed.
There is also a small cleanup of the find_visible_by_log_attrs()
(remove trailing spaces, fix indentation).
There is still a part to optimize for a later commit.
https://bugzilla.gnome.org/show_bug.cgi?id=629129
This is fallout from the recent dialog changes. We don't set the
headerbar as titlebar early enough anymore, so when the window title
gets set, it does not get passed on to the headerbar. So, re-set it
manually when the titlebar is put in place.
https://bugzilla.gnome.org/show_bug.cgi?id=733099
This will let us theme activatable rows differently.
We also avoid emitting the ::row-activated signal for
rows that are not activatable. For compatibility reasons,
rows are activatable by default.
https://bugzilla.gnome.org/show_bug.cgi?id=733112
Move the touchscreen switch to the other debug switches, and
move the hidpi spin to the other graphical controls. Since the
Visual tab is getting large, make it scroll. The General tab
is purely informational again.
Otherwise, the CSS background we draw would be clipped if the ink rect
was smaller than the allocation (a very common thing).
Broken since 37030a7710 where we clipped
to the ink rect.
The overlap was caused by using pack-end for the arrow, which
causes it to be allocated from the other end. Avoid the problem
by using pack-start for both the title and the arrow, and
reordering them according to xalign.
Some of the features we expose can be hardcoded via environment
variables. In that case, don't confuse the user by letting them
change settings that have no effect.
The displacement animation has been replaced by edge gradients, that
have a stronger color the harder overshooting is hit. This makes it
possible to remove the internal overshoot window, which was merely
used to have contents displaced when overshooting to top/left.
Overshooting to bottom/right used to cause queue_resize() to be
called on the scrolled window, this isn't necessary anymore either.
https://bugzilla.gnome.org/show_bug.cgi?id=731297
There was this hack, taken verbatim from GtkCList according to the comment,
that would recursively translate the allocation during scrolling, and set
it on children widgets through the direct gtk_widget_set_allocation() setter.
Since commit 4f89eb05cf, this has caused the wrong clipping areas to children
widgets of a textview. The reasons for this seem lost in time, and the approach
seems indeed wrong for windowed widgets as the repositioning of those windows
couldn't happen.
So replace all of this with just a gtk_widget_size_allocate() call, which does
work ok for the children widgets embedded in the "multiple views" gtk demo, and
ought to work for every other widget.
https://bugzilla.gnome.org/show_bug.cgi?id=732900
The reparenting happening on the column header so it gets a movable
window breaks the implicit grab, so this is one situation were we
want a pointer grab, if just to replace it.
https://bugzilla.gnome.org/show_bug.cgi?id=732933
Code was expecting view coordinates, not widget ones, as we're
only dealing with horizontal displacements, just adding the
horizontal adjustment value suffices.
https://bugzilla.gnome.org/show_bug.cgi?id=732933
This saves some code and lets us reuse the color swatch styling.
Among other things, this fixes a lack of discernible border when
the selected color is very similar to the background.
https://bugzilla.gnome.org/show_bug.cgi?id=680885
The recent reshuffling caused an ordering problem where we would
hide the action area before relocating the buttons to the header
bar. But hiding makes the default button loose its defaultness.
Rearrange things so that we move the buttons before hiding the
action area, and thus preserve the default.
If the drag gesture gets a GtkGesture::updated signal, the user
is directly interacting through pointer/touch with the range slider,
animating the adjustment value change in this situation can produce
perceived lag, so set the value immediately when this is happening.
Use the adjustment target value when repositioning the cursor, and remove the
checks that ensured the cursor was made onscreen immediately, as there will
be definitely a delay on animated adjustment changes.
When moving the cursor, compare current adjustment value with the post-animation
target value, in order to avoid false "keynav failed" positives as the animation
hasn't started yet, so dx/dy are still 0 at that time.