- 29 Aug, 2017 4 commits
-
-
Matthias Clasen authored
We can now control with CSS where there the outline is drawn.
-
Matthias Clasen authored
Make :focus(visible) match the new state.
-
Matthias Clasen authored
For now, we only set the new visible focus state on the focus widget, when we have visible focus. Later on, we will allow setting it on other widgets.
-
Matthias Clasen authored
The new flag is called GTK_STATE_FLAGS_FOCUS_VISIBLE.
-
- 28 Aug, 2017 14 commits
-
-
Daniel Boles authored
Disconnect the now-unwanted signal handler, and hide the icon. https://bugzilla.gnome.org/show_bug.cgi?id=786940
-
-
Daniel Boles authored
We hijack the secondary icon for the emoji picker, but the handler for ::icon-press did not check the pressed icon and opened it for either. https://bugzilla.gnome.org/show_bug.cgi?id=786938
-
Ask Hjorth Larsen authored
-
Ask Hjorth Larsen authored
-
Matej Urbančič authored
-
Matej Urbančič authored
-
Timm Bäder authored
-
Timm Bäder authored
-
Timm Bäder authored
This reverts commit 8c0e5ada. This is actually needed since GtkHeaderBar will allocate and snapshot widget that coun_visible_children does not consider.
-
-
Timm Bäder authored
-
Timm Bäder authored
gtk_popover_get_pointing_to does not fill the given rect in every case.
-
Timm Bäder authored
Ths avoids doing a bunch of work as well as passing 0 to g_alloca which is undefined.
-
- 27 Aug, 2017 5 commits
-
-
-
-
-
Matthias Clasen authored
Despite the comment, we ended up without ENABLE_NLS.
-
Matthias Clasen authored
We need to actually trigger the drop from the gdk side.
-
- 26 Aug, 2017 3 commits
-
-
Matthias Clasen authored
Drag contexts are objects, so there is no need to carry a manual refcount around.
-
Matthias Clasen authored
Under X, we were not setting the right drag cursor initially, because at current_action == action == 0, initially. Fix this by explicitly using the right cursor when grabbing.
-
Matthias Clasen authored
Subsurfaces don't currently work with our new rendering, and this makes popovers unusable. We can go back to using subsurfaces for popovers when this is fixed.
-
- 25 Aug, 2017 4 commits
-
-
Timm Bäder authored
Thanks to Murray Cumming.
-
-
Jordi Mas authored
-
-
- 24 Aug, 2017 5 commits
-
-
-
Daniel Boles authored
.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
-
Daniel Boles authored
This helps test whether the Popover positioning gets messed up by the presence of CSD shadow or other accessories around the content area. https://bugzilla.gnome.org/show_bug.cgi?id=786209
-
-
Piotr Drąg authored
-
- 23 Aug, 2017 5 commits
-
-
Matthias Clasen authored
We don't support Motif DND anymore, so no need to look for Motif-specific messages.
-
Daniel Boles authored
It was reported that the lack of a tooltip made its purpose unclear. This can be solved by just copying PlacesViewRow’s eject_button tooltip. https://bugzilla.gnome.org/show_bug.cgi?id=766909
-
Carlos Garnacho authored
This prevents the load_fonts() function from switching to the "no fonts" page and back when the model is reloaded. Given GtkSettings::gtk-fontconfig-timestamp is 0 on Wayland and style changes happen often, the stack change messes up popovers and pointer focus on the fonts treeview and test entry.
-
Tested for both modal and non-modal dialogs https://bugzilla.gnome.org/show_bug.cgi?id=785306
-
Instead of using conditional compilation, use respondsToSelector to check at runtime for setAccessoryViewDisclosed. https://bugzilla.gnome.org/show_bug.cgi?id=785306
-