Changing code to agree with docs, which said frame.flat, was backwards.
Mea culpa. Theme authors ran with the actual behaviour, not the docs. As
stability is more important, let’s go back to frame > border.flat, and
fix the docs to reflect what the code does and how to set .flat in code.
N.B. This retains the change in HighContrast of "frame border" to "frame
> border". Not using the direct child selector contradicted Adwaita &
could conceivably have unwanted results on nested nodes named border.
https://bugzilla.gnome.org/show_bug.cgi?id=778905
There are GtkGestureSingle subclasses that can be made to handle multiple
fingers (GtkGestureSingle is a subclass of GtkGesture, and not the
opposite, after all). And GtkGestureSwipe already tries to handle
GDK_TOUCHPAD_SWIPE events, except this event handler silently ignores
those.
Falling back to the GtkGesture generic handler which already
handles touchpad gesture events fixes this.
This reverts commit 367e021652.
This causes criticals in e.g. the Text View: Multiple Buffers demo.
More work is required to get a fix for Bug 778853 that does not cause
anything else to regress.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
The fact that it doesn’t reuse the existing GtkLabel if present is not
immediately obvious to users (or is it just me?), so clarify that the
pre-existing :label-widget, if any, is always removed and replaced.
Commit 0c20604932 changed the theme to expect the .flat class on
the frame node rather than the border one, but didn't update the
code that applies the style according to the :shadow-type property.
https://bugzilla.gnome.org/show_bug.cgi?id=779005
POLICY_AUTOMATIC means scrollbars are only shown when needed, i.e. when
the size of the window is not large enough to show the entire child. So
when measuring the preferred size, such scrollbars should be ignored.
But measure() was adding size for bars for which policy_may_be_visible()
was TRUE, which it returns for POLICY_ALWAYS (good) & _AUTOMATIC (bad).
So we reserved space for child plus scrollbars, & because we have enough
space for the child, POLICY_AUTOMATIC hides the scrollbar, leaving the
extra reserved space empty at the right/bottom sides of the child. This
is very noticeable/inconvenient for non-overlay, automatic scrollbars.
Fix this by only requesting size for scrollbars that use POLICY_ALWAYS,
rather than basing the decision on policy_may_be_visible().
https://bugzilla.gnome.org/show_bug.cgi?id=778853
Using Ctrl + left/right to skip between words, or left/right to cancel a
selection, were causing movement on the screen in the opposite direction
of the glyph on the key. This was surprising and awful UX for RTL users.
This is based on a patch covering the former case by:
Author: Mehdi Sadeghi <mehdi@mehdix.org>
Date: Sat Feb 18 02:16:00 2017 +0000
https://bugzilla.gnome.org/show_bug.cgi?id=136059
Using Ctrl + left/right to skip between words, or left/right to cancel a
selection, were causing movement on the screen in the opposite direction
of the glyph on the key. This was surprising and awful UX for RTL users.
This is based on a patch covering the former case by:
Author: Ori Avtalion <ori@avtalion.name>
Date: Tue Apr 20 08:06:23 2010 +0000
https://bugzilla.gnome.org/show_bug.cgi?id=136059
The docs say that this class should be put on the frame node, and that’s
all we can do from C code, but the CSS was selecting on the border node.
The result was that adding .flat did not disable the border as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=778905
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
