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.
Otherwise we get errors on g_content_type_is_a(). This happens mostly on Windows
because it only knows a limited set of mime types and tries to convert
them to file extensions without any fallback.
open() in text mode should never be used without an encoding because it defaults
to the locale encoding which is rarely what is wanted.
This fixes the Windows build in some cases (depending on the locale/paths used)
When parsing a UI description for GtkFileFilter we should avoid passing
empty strings, to avoid issues when serialising the filter before
sending it over DBus.
Fixes: #1973
Be prepared for the eventuality that somebody
might reinsert the same action group without
holding any extra references on it.
This was observed as causing crashes in
gnome-builder.
Otherwise the native window gets created with GDK_TYPE_HINT_NORMAL
and in fullscreen appears on its own screen or tab instead of over
the combo like it's supposed to.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1737
Don't export any functions taking or returning MacOS types in
gdkquartz.h, gdkprivate-quartz.h, or any header that either includes.
The GdkQuartz internal functions are moved to a new header
gdkinternal-quartz.h, the functions used by quartz-specific
Gtk files are moved to another new header gdkquartz-gtk-only.h, and
the key and event enums to a new header gdkkeys-quartz.h.
We named the argument `position` in the code and doc arguments, but the
rest of the documentation referred to `index` instead. That was maybe
meant to hint at the child property named :index, but we can simply be
fully clear here. We can call the argument `index_`, replacing the local
variable with that name, thus avoiding any possible confusion with the
unrelated ::get-child-position, and refer users to :index for completion
`index_` is used instead of plain `index` in case anyone is #including
<strings.h> and getting the old index() function superseded by strchr();
see https://gitlab.gnome.org/GNOME/gtk/merge_requests/932#note_531149
Some users expect that the Overlay will automatically request enough
size for its overlay children as well as its main child. It doesn't,
because it's just a GtkBin. Add a short paragraph pointing that out.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1939
The documentation for gtk_widget_get_action_group
and gtk_widget_list_prefixes states that both of
these operate on all the action groups that are
'available' to the widget.
Which means: they are meant to walk up the parent
muxer chain. So do that.
Add tests to verify the expected behavior.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1396
Currently, calling `gtk_entry_completion_complete()` does not adjust
the visbility of the popup used to show completion entries. This makes
it difficlt to dynamically populate the model based on what is being
entered into the completion's entry.
For example, if the model is being populated from a database, and no
matches have (yet) been added between typing a character and the 100ms
delay before completion is automatically triggered, the popup will not
be shown even after matches have been added.
This patch simply moves the related code from the private timeout method
to the public function and shuffles the position of some functions so as
to keep the compiler happy.
This is a backport of the GdkProfiler from master. It does not include
the pixel bandwidth numbers that come from gdkdrawcontext.c since there
does not seem to be an analog in 3.x.
Additionally, this implements the recent changes for SYsprof's D-Bus
profiler API which adds a Capabilities property and an options hash-table
to the D-Bus interface for forward portability.
We don't need to cover every case with a va_marshaller, but there are a
number of them that are useful because they will often only be connected
to by a single signal handler.
Generally speaking, if I opened into a file to add a va_marshaller, I just
set all of them.
This adds specific marshallers for all of the locations where a generic
marshaller is being used. It also provides va_marshallers to reduce the
chances that we get stack traces from perf going through ffi_call_unix64.
Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
along with a new 'type-format' setting that allows
to choose the output format for the "Type" column.
The options implemented for this setting are:
'mime' : Output from g_content_type_get_mime_type().
'description' : Output from g_content_type_get_description().
'category' : It uses the corresponding generic icon
of the mime type to group by categories (aka basic types).
This produces a more compact output than previous options,
and allows for type families to be grouped together, so eg.
after sorting by "Type" column, jpeg and png images will
be placed together, or the various types of archiver files
will also be grouped together.
This format was copied from and currently used by Nautilus
list view, so we also improve consistency with Nautilus.
Bugzilla entry for Nautilus implementation is:
https://bugzilla.gnome.org/show_bug.cgi?id=683722
The list of type families or categories can be checked on:
https://developer.gnome.org/icon-naming-spec/#mimetypes
This 'category' format is set as default.
Issue #362
This has caused numerous issues for users, especially in the
filechooser, which have not been fixed in all the years since the pixel
cache has been introduced.
If anyone seriously has complaints about the treeview performance (and
those did not exist with the pixel cache), feel free to revert this
commit *and* fix the pixel cache issues.
Closes#503Closes#1691Closes#466
It takes half a second on my system to initially
populate the Emoji chooser. That is too long. Do
the work in 8 millisecond chunks to give GTK a
chance to get some frames done.
