It was "Missing name of pseudo-class", but the real problem is exactly
the opposite: we /have/ been given a name, but it is not a valid one.
Change it to "Invalid name of pseudo-class" to minimise confusion.
gtk_text_iter_backward_line() checks the value of
real->line_char_offset without previously calling
ensure_char_offsets (real) to make sure the former
is up-to-date.
As a consequence of this, when gtk_text_iter_backward_line()
is called after a gtk_text_buffer_insert_range() in the
first line of buffer, the iter is not moved to the start of
the line, and the return value is wrong.
Fixed by adding the ensure_char_offsets() call.
A test case for this bug is added to the textiter gtk testsuite.
When a widget is created, its default scale is the scale of the
primary screen (for instance 2). But once parented to another widget
its scale factor should be the one of its parent (if parented to a
widget on a screen at scale factor 1, it should be 1).
The problem is that we don't emit the notify::scale-factor signal when
reparenting happens.
https://bugzilla.gnome.org/show_bug.cgi?id=776821
gtk_show_uri_on_window() will pass enough information for Portal helpers
to allow dialogue parenting in Flatpak, gtk_show_uri() won't, so
deprecate it.
https://bugzilla.gnome.org/show_bug.cgi?id=778678
This is a workaround for a regression in updating scrollbars in
some applications; notably eog. We haven't fully tracked down yet
why a queue_allocation is not sufficient here, it should.
https://bugzilla.gnome.org/show_bug.cgi?id=765410
combo_box_popdown() of course doesn’t popdown our menu if it is NULL.
But the required call to this at end-of-life was in destroy(), by which
point dispose() already NULLed the menu, so Menu::popdown() would never
run, even if it should. Fix this by trying popdown() earlier in unmap().
Also, add a converse assurance that we don’t popup() while not mapped.
i.e. when wrap-width > 0. This was only being done for non-grid cases.
So, ComboBoxes in grid mode did not indicate their selection when popped
up and required users to keynav from ‘nothing’ (at the top-left) to the
item they wanted to select. By selecting the active item in advance, now
it’s highlighted & acts as the starting point for keynav around the grid
This previously only mentioned its effect on the displayed value, and
even after the previous commit, its rounding of the actual value upon
change still reads like too much of an afterthought. Worse, it wasn’t
mentioned at all in the doc for the @digits parameter. Change this to
emphasise rounding always occurs and the displayed value is secondary.
Whether it should is an open question, but for now, the documentation
should clearly indicate that currently rounding is only applied upon
changes to the value, not to the existing value when ::digits changes.
This is already clear in the doc for the underlying Range::round-digits.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
The documents state that gtk_scale_set_digits() “causes the value of the
adjustment to be rounded off to this number of digits, so the retrieved
value matches the value the user saw.” Note the lack of any condition.
But in fact, if draw-value was false, rounding was disabled on the base
Range, so values that weren’t displayed weren’t rounded. This made the
docs wrong and made an apparently cosmetic detail alter functionality.
Fix by ensuring the number of digits set on Scale is always propagated
along to gtk_range_set_round_digits(), thus rounding to it in all cases
when the value changes, regardless of whether the value is displayed.
This doesn’t address the other idea from Bugzilla: that changing the
number of digits should clamp the _existing_ value if it’s more precise.
This contradicts digits docs in the base Range, but the above from Scale
can be read as implying it’ll happen. For now, that’s an open question.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
GtkFileChooserButton installs a handler for the popped-up signal, which
refilters the menu, in order to hide the “(None)” item from the popup
if it was previously selected in the ComboBox. This oddity means that:
• Until recently, this item would be selected in the menu shell, which
would then be popped up and change the selection away from that item.
This was therefore redundant (more on which below!) but benign.
• After the patch for https://bugzilla.gnome.org/show_bug.cgi?id=771242
however, this causes a critical assertion fail, as now we stash the
originally selected item in a pointer so that it can be selected only
after realisation/popup – but by that stage, the model has just been
refiltered and the previous pointer no longer refers to a valid item.
This commit works around this problem by, after popping up the menu,
getting the active item again, in case a popped-up handler has gone and
invalidated the pointer to the active item that we saved before popup.
If a handler does this, everything done to find/use the original item is
pointless. But this avoids the ugly critical in FileChooserButton, while
not harming every other ComboBox that doesn’t mess with its model while
popping up (hopefully the vast majority), and it’s very difficult to
imagine a way to check if the active item is /going to/ be hidden later)
This reverts commit 4875c689a0.
This was a thinko. Writable is not actually settable from the
application side, but only for the user, from the backend side.
Images with just an aspect ratio, but without a size, should be scaled
to be fully visible in the given area.
But we scaled them to completely cover the given area, which made them
partially invisible.
Reftest included.
Also, "ie" wasn't very clear, but fixing that to "i.e." would cause
truncation of the summary when processed by bindings using doxygen. So,
I replaced it with "in other words", which is no _less_ clear, at least.
drag-data-delete is emitted based on the interchange of the
DELETE atom, which may well be set or bypassed locally by
the app. As such emitting it here is not right, the other
paths handling the DELETE atom interchange are still valid
and there.
https://bugzilla.gnome.org/show_bug.cgi?id=774726
See the implementation of gtk_entry_create_layout():
pango_attr_list_splice() is used to add the PangoAttrList of the preedit
string. And that is done *after* applying the PangoAttrList of the
"attributes" property.
https://bugzilla.gnome.org/show_bug.cgi?id=776868
...which treats the first '.' in doc comments as the end of the summary.
So, e.g., in gtkmm, get_kinetic_scrolling() is currently summarised as
"Changes the behaviour of @scrolled_window wrt." Not very informative!
No need for a period there & anyway, the phrase "wrt to" is superfluous,
and we have space to actually say "with regard to", so just do that now.
If the signal handler ends up changing the label text,
the link is no longer around to update the css node.
Check for this possibility to avoid a crash here.
When running uninstalled tests with GtkApplication on an autobuilder with
a fake session bus, warnings will cause the tests to abort. The GNOME
session manager, the Xfce session manager, and the Inhibit portal are all
not needed for normal operation of GTK, so we should not log warnings if
they are not found.
As well as not being present on a fake session bus, it's also not
expected that they'll be present on all platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=774784
... with gtk_list_box_get_row_at_y. It would be nice to avoid the
'find' versus 'get' discrepancy since we are planning to expose it as
public API.
https://bugzilla.gnome.org/show_bug.cgi?id=776187
When the background-clip of the background is smaller than the
background-clip of blended images, not pushing a group is wrong.
Test testing exactly that included.
For a menu mode CB with wrap_width == 0 and an active item, that item is
selected in gtk_combo_box_menu_popup. Selection causes the MenuShell to
activate and hence take a grab. This was done before the menu was popped
up. A patch distributed in Debian sid - after being proposed on our BZ -
revealed that on the 1st popup of any such ComboBox, within grab_add,
the MenuShell's toplevel's GdkWindow is NULL. This causes a Gdk-CRITICAL
assertion fail on the 1st time opening any such CB, on Debian and if
that patch were merged to GTK+. By selecting after popup, we ensure the
MenuShell is realised before its grab_add and so avoid the critical.
https://bugzilla.gnome.org/show_bug.cgi?id=771242
We were producing org.symbolic.png from org.gnome.Recipes-symbolic.svg,
which is not useful. Look for the last dot in the original name, to
produce the expected org.gnome.Recipes-symbolic.symbolic.png instead.
Since at-spi-atk commit 96621a5e95 fixed PropertyChange notifications
for AccessibleParent, setting the parent will result in a call to
ref_state_set() which assumes that the object is fully initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=774939
While GtkEventController implementations today are all GtkGesture, it is
possible to create a GtkEventController manually. This is an extrac check
to ensure we only add gestures to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=774760
When checking if a rectangle is contained by the rounded box, the code
will refuse a rectangle which is the exact size as the one backing the
rounded box, since it checks for greater or equal width and height.
Check for greater only instead.
https://bugzilla.gnome.org/show_bug.cgi?id=774114
Unlike other container widgets, GtkStack would allocate its children
prior to moving its windows, which might prevent further valid size
allocation signals to be emitted.
Re-order the size allocation of child widgets to be performed after
moving the GtkStack windows.
Thanks to Owen for spotting the real issue here.
https://bugzilla.gnome.org/show_bug.cgi?id=767713
This fixes a DOS where any app can cause all running gtk apps
to use arbitrary amounts of memory.
Originally reported against mate-panel, where running a big slideshow
in eye-of-mate caused increasing RAM usage in mate-panel.
v2: Hardcode the value
Signed-off-by: Lauri Kasanen <curaga@operamail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773587
Making sure the surfaces are using the same scale factor makes it more
likely a fast path will be used when pixman gets involved, as pointed
out by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=772075
We are currently truncating job names to 255 bytes, because that's the
maximum allowed length of job-name attribute in CUPS. This is a CUPS
limitation that GtkPrintOperation shouldn't need to know, and it
shouldn't affect other backends, that might have other limitations or
even no limitation at all. This has another side effect, that what you
set as GtkPrintOperation:job-name could be different to what you get if
the property is truncated, this is not documented in
gtk_print_operation_set_job_name(). So, I think the job name should be
truncated by the CUPS backend, right before setting the job-name
attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=774097
The GApplication platform data may contain a startup ID that on X11
is used to set the startup notification ID when activated. Do the
same on the wayland backend to make startup notifications work for
DBus-activated applications where the DESKTOP_STARTUP_ID environment
variable is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
GtkLevelBar supports adding custom offsets as style classes, and they
are applied whenever the :value property matches. The current code,
however, only updates any CSS nodes when an offset is found, causing
it to not update when a discrete value changes but no custom offset
is added.
Fix that by always updating the CSS nodes.
https://bugzilla.gnome.org/show_bug.cgi?id=773799
For some reason we end up allocating the colorplane widget
before it is realized, and then never initialize the surface.
Fix this by explicitly doing it on realize.
https://bugzilla.gnome.org/show_bug.cgi?id=773474
With best-effort, try to use gdk_window_move_to_rect() more often, when
all pieces fit together. For the non-legacy paths to be triggered for
when gtk_menu_popup_for_device() or gtk_menu_popup() were used, the
following conditions must be met:
1) There is no custom positioning function specified
2) The menu is attached to a widget (using gtk_menu_attach_to_widget())
3) There is a associated grab device
https://bugzilla.gnome.org/show_bug.cgi?id=772922
the darker bottom border used on buttons looks bad on circular ones
so now a gradient clipped on the border-box and a transparent
border is used in that partcular case.
See https://bugzilla.gnome.org/show_bug.cgi?id=771205 for details.
$button_fill contains the background-image property value of
buttons, having it readable outside the drawing mixin allows, for
example, stacking background images in an easier way.
This allows the use of a "text-direction" hint set to one of "none", "rtl",
or "ltr" to enforce the text direction of a "horizontal-buttons"
display-hint.
This is useful when a menu has buttons that map to physical space in the
UI and therefore must match the application widgetry.
https://bugzilla.gnome.org/show_bug.cgi?id=772775
gtk_widget_destroy() removes widgets from their container. However
_internal_ widgets must be unref'ed using gtk_widget_unparent() instead.
This is symmetric with the fact that these widgets were ref'ed by direct
call to gtk_widget_set_parent(). It's also the method that was used in
gtk_headerbar_destroy().
https://bugzilla.gnome.org/show_bug.cgi?id=772859
> Due to Gtk+ keeping a reference to the window internally,
> gtk_window_new() does not return a reference to the caller.
> To delete a GtkWindow, call gtk_widget_destroy().
Caller(s) aren't expecting a need to delete help_overlay themselves
once they've installed it. (E.g. see gtk_application_window_added()).
I didn't notice any direct precedents, but there's a parallel in the
current implementation of gtk_container_destroy() which uses
gtk_widget_destroy() on any added widget.
This avoids leaking 100s of kB per window, when I tested nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=772859
