It’s possible for code which uses a `GtkListBox` to reuse a single
header row, and move it around between rows. For example, this might
happen if the code has interactive widgets (like buttons) in the row,
and doesn’t want to continually recreate them and reattach signals to
them whenever the row headers change.
Unfortunately, this was broken, as the old header widget was
unconditionally unparented, even if it had just been set as the header
for a different row in the same `GtkListBox`. This left it assigned as
a child widget in the `GtkListBox` (so it was iterated over by
`forall`), but without its parent widget set.
Fix that by only unparenting the header if it hasn’t already been
assigned as the parent of a different row.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
G_ENABLE_DEBUG is tied to the meson builttype property, so building with "plain"
results in G_ENABLE_DEBUG not being defined and the GTK_DEBUG env var just gets ignored
for that build.
Since it can be confusing that GTK_DEBUG has no effect print a warning message instead.
Fixes#2020
In the unlikely case that GTK is "embedded" with other toolkits
(hi, Mutter), GTK will clobber the embedder's AtkUtil implementation,
leaving its own a11y in a broken state.
AtkUtil is not meant to be overridden by multiple toolkits within a
single client, so the most sensible thing to do is stay away from it
if that is the case. This helps the embedder's a11y to win.
Fixes Clutter a11y in Mutter after xwayland-on-demand, process
startup used to be in a fixed order so that Clutter's a11y would
eventually win, but x11/gtk startup is now asynchronous and able to
happen at a later point.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1687
gdk_screen_get_resolution() can return -1 when the resolution is
unknown. Catch that case and use the default resolution of 96, like in
every other case.
Fixes#2119
We need to take the device scale into account, like it is done in
gdkwindow.c.
This fixes wrongly placed DnD surfaces in scaled contexts on X11
as well as Wayland.
We're potentially applying multiple properties during object
construction; we should avoid constantly notifying after setting each
one, and instead coalesce the notifications at the end. In most cases,
the calling code doesn't have access to the instance, so it won't be
able to connect to the "notify" signal anyway, but it avoids a lot of
busy work.
because if there's a tooltip visible then popups fail to show
with the following warning:
"Gdk-WARNING **: Tried to map a popup with a non-top most parent"
This bug affect popups of the form:
1) popups from gtk_menu_popup_{at_widget|at_rect|for_device}()
This can be reproduce with a normal GtkComboBox that has a
tooltip attached (eg. via GtkBuilder 'tooltip_text' attribute).
Also see GtkLabel reproducer from gtk3-demo mentioned in #1785
2) custom popups created with gtk_window_new (GTK_WINDOW_POPUP)
A reproducer that shows this case is a GtkComboBox with
the property 'appears-as-list'[1] set to TRUE (default is FALSE).
Fixes issue #1785
[1] https://developer.gnome.org/gtk3/stable/GtkComboBox.html#GtkComboBox--s-appears-as-list
Popovers have special handling to restablish
the previous 'default' and 'focused' widget,
that code it's in the map() unmap() handlers
in gtk/popover.c .
But, at the same time, GtkWindow also does
automatic restablishing of previous 'default' and
'focused' widgets, that's in _gtk_window_unset_focus_and_default()
function in gtk/gtkwindow.c which is called from
gtk_widget_hide() in gtk/gtkwidget.c .
So, when a popover is closed, both code-paths are
executed, conflicting with each other and resulting
in the popover failing to properly restablish the
default widget.
The commit that introduced _gtk_window_unset_focus_and_default()
to gtkwindow.c is from 2002 (commit ff9c2c5669) so
it predates by far the popover.c implementation,
therefore the rationale thing to do here is to exempt
popovers from being handled in _gtk_window_unset_focus_and_default()
(as that function is oblivion to the fact that
popovers have their own handling).
So, this commit exempts popovers from being handled
in the aforementioned function, but only for
the 'default' widget part atm, because although
by the previous rationale we should exempt it
from the 'focused' widget part too, I could not
find a bug in the issue tracker about that, so
instead we just exempt the 'default' widget part
that we know for sure it fixes issue #2125
Fixes issue #2125
Fix popovers to properly gain focus when clicked
inside an unfocused window.
We use the GTK_PHASE_CAPTURE of the 'pressed' event
to early detect that the popover is being clicked
inside an inactive window, this allow us to present
the window (and be focused) before the normal signal
handlers for the popover click/pressed events are run
which would ultimately give focus to popover widget.
This fix works for both modal and 'non modal' popovers
when being clicked inside unfocused windows.
Fixes issue #1871
With the switch to meson we no longer built with _FILE_OFFSET_BITS which
results in fstat being the 32 bit variant, not matching GStatBuf, which is
_stat64 on 64bit mingw builds.
This makes things use _fstat64 in this case, to match GStatBuf.
Because otherwise when the file list is sorted "by name"
and the new name causes the file to be re-sorted to another
row, the selection stays in the old row which is now
occupied by a different file.
Fixed by keeping track of the renamed file and revealing
it in the "row-changed" signal handler, which gets emitted
after a file is renamed.
Fixes issue #948
When loading a SVG icon from a gresource file only containing SVG icons,
but without having a SVG loader available in gdk-pixbuf, we would crash
when trying to eventually load the resource. Fix this by gracefully
handling this by simply failing to load the icon, while the first time
it happens, log a warning.
https://gitlab.gnome.org/GNOME/gtk/issues/2084
When explorer.exe creates a taskbar it broadcasts a "TaskbarCreated"
message to all toplevels. Applications, By handling that message,
are able to re-create the icons to be displayed in the taskbar.
Explorer creates a new taskbar in two circumstances:
A) when explorer starts up
B) when the DPI of the monitor changes
A) happens either when explorer.exe is started for the first time at
logon, or when it is restarted after being terminated.
B) happens when the user changes the DPI preference of the active
monitor where the desktop is displayed, or if the desktop is moved
to a monitor with different DPI.
Currently, this message is handled in Gtk and icons are re-created.
However the current implementation has a small issue in that it
doesn't set the tooltip on the new icons, so tooltips get lost
after re-creation.
The tooltip is important because Windows uses it for identification
of taskbar icons and for storing and applying user preferences. For
an explanation of that see:
https://bugzilla.gnome.org/show_bug.cgi?id=609622
With this commit the tooltip is correctly applied to new taskbar
icons when handling taskbar_created_msg.
See Merge Request !1003
- use even sides for the titlebuttons so the result is a circle and not an ellipse
- add maximum border radius
- set min width/height to 0
- adjust margin and padding to match the previous look
This commit fixes a bug (issue #2066) caused by gdk_window_set_cursor being called with a NULL pointer as its first argument during the
unrealize-ing of a GtkPaned, resulting in a Gtk-CRITICAL. The change ensures that, even if the function gtk_paned_state_flags_changed
is called on a GtkPaned while it is part way through being unrealized (as can happen, for example, if a descendant of the GtkPaned calls
gtk_clipboard_store when it is unrealize-d, see the issue report for a test case), the function gdk_window_set_cursor is not called on
the GtkPaned's priv->handle member if this pointer is NULL.
Closes#2066Fixes#2066
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2066
Commit 42b02d9d ("ignore resize increments for maximized/fullscreen")
introduced a regression which prevents window from being resized while
maximized or fullscreen.
Move the check for maximized/fullscreen where the geometry is handled
rather than ignoring the geometry info when maximized/fullscreen so that
a client issuing a "move_resize()" while maximized or fullscreen can get
the requested size when restoring the original window state.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1044
- make use of already existing checkradio_bg/fg_color
- use the primary color blue ($selected_bg_color) for the check and radio background and white ($selected_fg_color) for the fg color
- no change to backdrop
GMountOperation now supports options to unlock TCRYPT volumes. This
patch sets these options if they are returned by AskPassword() of a
GtkMountOperationHandlerProxy.
