set_transient_for(toplevel) was only called in list_setup(). It was easy
to make a test showing a NULL :transient-for instead of the correct one.
So, move the call from list_setup() to popup_for_device(). Also do that
for window_group_add_window(), which means not calling it redundantly.
(I tried using a ComboBox:parent-set handler, but the Inspector’s CB
didn’t like that: it calls popup_for_device() twice and closes on button
release. Anyway, using popup() is much more concise than a new handler.)
The screen for the list-mode popup_window was only being set in
set_popup_widget(), i.e. when changing modes, so if the ComboBox was
moved to a different screen later, the popup would appear on the
original one, which is wrong.
Worse, this (somehow) broke opening some combos in the Inspector.
Fix this by moving the call to set_screen() to popup_for_device(), so
the popup_window is put on the correct screen each time around.
https://bugzilla.gnome.org/show_bug.cgi?id=468868https://bugzilla.gnome.org/show_bug.cgi?id=786771
Add integration of the libcloudproviders DBus API to the
GtkPlacesSidebar by showing name and sync status of the cloud providers.
The exported menu is rendered as a GtkPopover.
The sidebar will be updated if the list of cloudproviders changes e.g.
by adding or removing an account. If any cloud provider changes detailed
information like sync status only the individual sidebar row gets
updated.
Co-authored-by: Carlos Soriano <csoriano@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=786123
Bad actors, such as our very own FileChooserButton, may connect to the
:popped-up property and alter the model as the menu becomes in/visible.
We were getting an iter to the model while popped-up, then doing
popdown(), then using the iter, which may have just been invalidated by
the errant notify::popped-up handler. If so, we quickly crash fatally.
This is clearly bonkers, but until such patterns are removed, we have to
work around them. So, set_active() from the clicked item while it is
known to be valid, by moving the call to set_active() before popdown().
While here, change set_active_iter(iter) to set_active_internal(path) to
avoid pointlessly going through the iter to get the path we already have
https://bugzilla.gnome.org/show_bug.cgi?id=729651
Just adding/removing to/from the BoxGadget is not sufficient; that
leaves the GdkWindow hanging around, taking input, changing the cursor,
and all sorts of other nefarious shenanigans.
Resolve by ensuring the child’s GdkWindow is unmapped if collapsed.
Note: the reflexive solution is just to set_visible(child, expanded),
but it is best to avoid messing with the child’s :visible property.
https://bugzilla.gnome.org/show_bug.cgi?id=776937
.update_position() enforces that non-Wayland platforms must position a
Popover within its parent Window. We use the allocation of the Window
to translate the position and check for overshoot on each of its sides.
Calling Widget.get_allocation() of a CSD Window includes its shadows.
But shadows were not excluded from the area in which we can position.
Thus, Popovers could get positioned in the shadow of CSD windows, where,
at least on X11, no input is received. Therefore, positioning a Popover
over a shadow meant its child widgets within that area became unusable.
Fix by calling Window.get_shadow() and including it in the overshoot on
each side. This adjusts for how the allocation includes shadows, making
overshoots with and without shadows the same. Thus, we avoid considering
shadows as viable for positioning, favouring a side where input works.
https://bugzilla.gnome.org/show_bug.cgi?id=786209
https://bugzilla.gnome.org/show_bug.cgi?id=784723 introduced support for
native file chooser dialogs on macOS, but due to the use of generics in
the patch, there will be compilation errors on pre-Xcode 7 platforms,
such as Mountain Lion and Mavericks.
I strongly recommend to revert this patch when the oldest supported
macOS release is bumped to Yosemite (10.10).
https://bugzilla.gnome.org/show_bug.cgi?id=785306
Seems to be there for the sole purpose of ensuring the button
shall receive the key release on keyboard-triggered activation.
For the cases where this makes sense (eg. comboboxes, menubuttons,
...) gtk+ already does ensure the menu is popup after key release.
This makes the grab pretty useless, and there's many other cases
where it doesn't make sense (eg. button being activated
programmatically from an event handler in another widget).
Fixes button activation unintendedly triggering shortcut inhibition
on wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=786480
They are not usually yellow anymore, the previous advice about how to
style them was for pre-3.20 versions, and the immediate replacement (CSS
class .tooltip) does not seem ready for primetime.
https://bugzilla.gnome.org/show_bug.cgi?id=784421
No longer store variation sequences explicitly. Instead, put a 0
in the sequence where the modifiers will be inserted. This is more
compact, and it allows us to put variations directly into the
recent section. Update the type of the recent-emoji setting to
match these changes.
A recent commit for emoji also updated seemingly unrelated parts of the
generated CSS files, presumably due to other things that changed in
master. The CSS files should be kept in sync with their SASS sources.
Add an "Insert Emoji" item to the context menu in entries.
We also add a show-emoji-icon property, which when set to
TRUE, will add an icon that can be clicked to bring up
the Emoji chooser.
When the popover is dismissed, we return the focus to
where it came from. However, by using gtk_widget_grab_focus,
we were messing up the selection if that widget happens to
be an entry. Special-case GtkEntry and use
gtk_entry_grab_focus_without_selecting to avoid this issue.
The json file is imported from the (MIT-licensed) emoji.json[0] node
module, which generates it from the emoji list published by the
Unicode Consortium.
This commit also adds a little tool to convert the data into
a compact GVariant, and the result of that conversion, which is
added to libgtk as a resource. The following commits will make use
of it.
[0] https://github.com/amio/emoji.json
In gtk_container_real_set_focus_child(), we try to scroll to the
position of the new :focus-child if we have h or v adjustments.
gtk_widget_translate_coordinates() returns FALSE if neither widget is
realized or in other situations that cause output parameters x and y not
to be set. Thus, if the caller did not initialise x/y and uses them even
if the function returns FALSE, they are using uninitialised variables.
In gtk_container_real_set_focus_child(), we did not check the return
value but merrily went ahead and used x and y regardless. This is UB, as
caught by Valgrind, as well as being pointless.
The trivial fix is to exit early if (!gtk_widget_translate_coordinates).
https://bugzilla.gnome.org/show_bug.cgi?id=776909
This fixes a fallout from 8a7d0ab481 where the error wasn't being
set when a display couldn't be opened right after parsing the
commandline.
It also fixes an older bug where the error would be left unset if the
commandline had already been parsed before (ie. when gtk_initialized
is TRUE).
https://bugzilla.gnome.org/show_bug.cgi?id=771959
