gtk_inspector_object_tree_find_object accesses the type information
of the object, so we can't safely use it on an already decaying
object when we get a weak notify. Instead just walk the tree and
compare pointers, that is safe.
https://bugzilla.gnome.org/show_bug.cgi?id=756852
Create css nodes for icons in entries, with name image, and use
gtk_style_context_save_to_node() for them. We still set the
style classes .left and .right on them.
Use the new element names instead of the type name and style
classes.
Note that there is one problem with moving away from type names
here: it turns out that style properties only work if the selector
uses the type name.
See the previous commit for why this is necessary.
Also make gtk_widget_class_set_css_name work by looking at
the correct class for the name.
Note for future reference: GTK_WIDGET_GET_CLASS() does not
work in the instance init function.
The widget path machinery assumes that we always have types,
and without this change, it will start spewing warnings when
we start to introduce node names.
If a window is decorated, we need to draw the frame and shadow, even if
it is app-paintable - it's just nonsense to have a frame that we handle
events on, but expect the app to paint it. (We paint the titlebar in
any case.) If a client wants to handle all painting, it should use an
undecorated window.
https://bugzilla.gnome.org/show_bug.cgi?id=756886
When the $(resource_prefix)/gtk/help-overlay.ui resource exists,
load a GtkShortcutsWindow from it for each GtkApplicationWindow,
and set up a win.show-help-overlay action with accels <Primary>F1
and <Primary>? to show it.
Use CHILD1/CHILD2 instead of 0 and 1, always use the same order and
don't check for child NULL-ness, because it will be done in
gtk_paned_set_child_visible anyways.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A boolean is returned to know if @iter has been set to the exact
location.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
When the search entry is shown, the 'special' nature of
., ~ and / should not trigger the location entry, because
that interrupts the search and is likely not what the
user intended.
https://bugzilla.gnome.org/show_bug.cgi?id=756505
Disclosure triangles are usually used pointing down, however
in this case the popover spawns in the upper direction, which
makes it odd looking.
Instead of pointing always down or up, point down when not toggled and
animate a rotation when toggled.
https://bugzilla.gnome.org/show_bug.cgi?id=756568
Since the change to use GtkPlacesView we don't want to show
internal storage on the sidebar.
In our case we were checking for drive_can_eject and
drive_is_media_removable.
However for some external hard drives it's reported that they
are not ejectable nor the have removable media. So the only
attribute that they have different from internal drives is that
they can be stopped.
So check for if the drive can be stopped to decide if it is
external or internal.
On the way realized we don't need to check for the mounts associated
with the volume to know if the volume can be ejected or not. So remove
that code.
https://bugzilla.gnome.org/show_bug.cgi?id=756589
It is assumed that border.top is the same than pointing_to.height (which
equals the strong cursor position), which is not since some time ago.
The border calculation has been move on top too, it is now used in the
Y position one, and doesn't depend on anything we calculate later.
Text handles are subsurfaces on wayland, so sort of their own toplevel.
This made gtk_widget_translate_coordinates() to bail out there, resulting
in text handles being mispositioned and jumpy. To fix this, translate to
toplevel GtkWindow coordinates manually, and translate coordinates from
there.
Along the way, the coordinates reported in ::handle-dragged have been
fixed so there is no small jumps in either axis (most noticeable in the
X axis when you started dragging, and in the Y axis when moving between
lines of different heights.
Make it what it is - the enum - so that that it is sure that the hint
will fit in the field. Without this, any hint that doesn't fit in 3
bits will be truncated to the 3 least significant bits, causing
unexpected behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Otherwise the popopver will be automatically unmapped in
_gtk_popover_update_child_visible() when the X axis (coming more
or less directly from events) goes outside the textview.
we used to consider every button inside osd containers linked,
this is not true anymore, now those buttons behave normally.
This will clearly cause breakage in applications.
According to http://datatracker.ietf.org/doc/rfc2911/, The 'name'
attribute syntax is essentially the same as 'text', including the
REQUIRED support of UTF-8 except that the sequence of characters
is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.
CUPS will not print jobs with names exceeding 255 characters.
https://bugzilla.gnome.org/show_bug.cgi?id=755988
Passing GTK_ICON_LOOKUP_GENERIC_FALLBACK to the icon lookup doesn't work
for GIcons, so we have to make sure we use the right GThemedIcon.
Fixes image-icon-name-use-fallback reftest.
If the last tag toggle is the end iter, the function returned the wrong
tag toggle.
This resulted in some bugs where the view wasn't relayout/redrawn
correctly.
The function also always returned TRUE, probably because the return
value is used nowhere. But for consistency with
_gtk_text_btree_get_iter_at_first_toggle(), it's better to keep the
return value, and also because otherwise the function would be wrong (it
doesn't always return a tag toggle, if there is none).
https://bugzilla.gnome.org/show_bug.cgi?id=755413
_gtk_accessibility_init() only gets called if the default
display changes, but in case gdk_init() is called before gtk_init()
the default display is already set and no property notification occurs.
This can happen quite easily in pygobject where
"from gi.repository import Gdk, Gtk"
will call gdk_init() followed by gtk_init() in the Python overrides.
This fixes it by checking for a default display in all cases.
Removing pages from the assistant with gtk_widget_destroy() used
to work. It broke with the recent interposition of a box between
each page and the notebook. Fix this by cleaning up when the box
child is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=756042
In fact there were two issues:
1. GtkFlowBoxChild with "can-focus"==FALSE should pass the focus
to its child immediately.
2. GtkFlowBox with "can-focus"==FALSE should cease its custom keynav
implementation and fall back to the default GtkContainer behavior
which is more natural.
Thanks to these changes the flow box can act as a better replacement
for GtkGrid and similar containers.
https://bugzilla.gnome.org/show_bug.cgi?id=753371
Move focus to list when search results appear to make it
possible to select the first search result by just hitting
Enter. To keep this from interfering with keynav, we need
to make sure that we still handle Escape to search. And when
search comes up empty, we need to move the focus back to the
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=755926
The stack calls gtk_widget_grab_focus on the last focus widget,
which selects the text in the entry, so we need to make sure to
move the focus there first to keep that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=755931
Once a window is maximized/fullscreen, resize increments should be
ignored otherwise the window may appear smaller than the screen size.
That also applies to configure requests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
We were calling gtk_container_should_propagate_draw
twice for each child. We can avoid this by splitting
out an gtk_container_propagate_draw_internal function.
Almost all callers of _gtk_widget_draw already did their own
cairo_save/restore, so drop the save/restore calls inside
_gtk_widget_draw and instead fix the last caller, gtk_widget_draw,
to do the same.
Call gtk_popover_update_position instead which will pick up the new
transition_diff value and pass it on to
_gtk_window_set_popover_position, which in turn will move the window
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
Check whether the given popover even changed size in
_gtk_window_set_popover_position. If not, just move its GdkWindow
without calling gtk_widget_queue_resize. Using popover_get_rect here is
still relatively costly, but popover_size_allocate would be doing that
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
We can use gdk_window_peek_children here, instead of copying
the list. Note that we preserve the bottom-to-top ordering by
iterating the list from the end.
gdk_window_get_children_with_user_data was doing a list
reversal while filtering the list.
The string we were using is the representation of the internal text
in the popover entry. However that can be freed before setting the
bookmark label, if i.e. the row is destroyed and therefore the popover
as well.
To avoid that, duplicate the label in a local variable.
One of the consequences is that for those people using development version
we migth screwed its bookmarks file, since the bookmark manager wrote
garbage from the already freed label.
https://bugzilla.gnome.org/show_bug.cgi?id=755215
We are passing widget coordinates to gtk_text_view_window_to_buffer_coords()
which expects coordinates to be relative to the text window in this case.
This may result in drop coordinates being displaced if the side windows to
the top/left sides are visible and taking space, so the DnD indicator will
point to the wrong position.
This can be seen on gnome-builder and gedit when displaying line numbers.
The row and rename popovers are always relative_to a row.
We also keep a pointer to them so we can interact with them in
callbacks.
However, if the row is destroyed its associated popovers will be
destroyed as well as relative_to destroyes and frees memory of its
associated widget when its relative_to widget is destroyed.
If we, for example, update the places while the popover is shown we are
going to access and invalid widget on the next time.
To avoid that, connect to the destroy signal of the popovers and clean
the sidebar pointers when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=755444
The patch did not check for Visual Studio 2008 correctly, plus it
would break the build on later Visual Studio versions, as it should
be __popcnt(), not __popcount(). Fix that.
The popcount builtin was added in GCC after version 4.2 (which is what
some *BSDs are using), which means we need to be more specific when
using it than just asking for GCC.
While we're at it, we can improve the compiler detection, and use a
builtin popcount on Clang ≥ 3.1 and MSVC 2008.
https://bugzilla.gnome.org/show_bug.cgi?id=755455
Instead of handling the horizontal and vertical peers separately
(and often, duplicatively), collect all peers in one go. At the
same time, avoid creating and destroying hash tables more often
than necessary.
