- create more contrast against the headerbar background without lowering
contrast with the label and border.
- top border shaded for extra aid of the state being pressed (in the two button scenatio)
Addesses issue #1588
- colorsheme based on the new icon HIG color palette
- new switches
- darker headerbar to contrast with unfocused windows
- raised buttons derived from the icon style
To avoid confusion, have the NMake Makefiles output the built introspection
files in the same location where the binaries are built for the project
files, according to the Visual Studio version, platform and configuration
where the build is carried out.
Also make generating the introspection NMake snippet portion more robust to
source additions and removals by checking on Makefile changes too.
When a popup is placed using move_to_rect(), it'll get feedback about
the position and size it got assigned. We use this feedback to update
the scroll offset, but while doing so, if the visibility of the arrow
changed, we didn't adapt the offset accordingly.
Fix this by offsetting the provided offset by the height of the arrow,
if it was made visible as a side effect of the scroll offset change
triggered by the feedback.
Related: mutter#105
Closes: #1463
A menu will be clamped to the work area as a side effect of the
move_to_rect() logic if the resize anchor flags was set. For it to work
a second time, the initial size needs to be the actual menu size before
being clamped again. Achieve this by forcing a size recalculation before
showing the menu.
Don't constrain the initial menu size by the work area of some monitor;
instead let the move_to_rect() logic in the backend do the constraining.
This fixes two things:
1) The anchor delta provided to the backend will not be invalid. The
delta is calculated by looking at the active menu item, calculating the
offset given that, but since we clamped the window size before showing
the window, the delta became invalid. This caused visible issues when
the delta was large enough to make the initially calculated popup window
geometry to be placed outside the geometry of the parent window, which
is a violation of the Wayland protocol.
2) The scroll offset to be correct when receiving the positioning
feedback. While the scroll offset was based on the pre-clamped window
size, the feedback, which was used to calculate the new offset, was not,
causing the scroll offset to be clamped as well.
We need to tell the portal what filter is supposed to be selected by
default, or it will just pick the first one, which could be wrong and
annoying.
This will require updated xdg-desktop-portal and xdg-desktop-portal-gtk
to work properly.
Fixes#1492
While the IEC power symbols have been part of Unicode since version 9.0,
released in 2016, not every font supports them.
We can use the old symbols as a fallback, as they seem to have the
better coverage, if not the best appearance.
gtk_file_chooser_set_filter() doesn't work for GtkFileChooserNative. The
code forwards added and removed filters to the delegate dialog, but
doesn't do anything to set the selected one, so the wrong one gets
chosen. So fix that.
This only fixes the fallback dialog. The portal will be fixed in a
subsequent commit.
Partial fix for #1492
When creating the motion controller, we know the widget that is of interest
based on gtk_event_controller_motion_new(). However, not all incoming
events are guaranteed to be of the GdkWindow associated to that widget.
They may also be for a descendant. Therefore, it is useful to translate
those coordinates into the target widget coordinate space as that is
likely what they care about.
We shouldn't give the icons here the same fg colour as the bg... which
makes them disappear and the buttons look like meaningless flat squares.
Fix by just using the same colour the same as foreground disabled. Note:
insensitive_fg_color is more prominent than !disabled, so clearly wrong.
The +/- buttons are meant to be transparent, showing the base_color,
but when backdropped they were picking up background-image from the base
button, meaning they suddenly became more like theme_bg_color instead,
and jumped out of the spinbutton when in backdrop unlike the rest of it.
This looks strange and achieves nothing (especially not indicating that
they are disabled, which is already served fine by their dim fg colour).
Fix this by explicitly saying we don't want any background-image there.
iter_init_common() is used on uninitialized GtkTextIter, and since neither it
nor its callers initiliaze its padding fields, they contain garbage.
This is a problem for Go - which checks that structs passed to C functions do
not contain pointers to Go-allocated memory - when the garbage happens to be
such a pointer. Although Go zero-fills all GtkTextIter that it allocates, this
does not help when GTK functions such as insert_pixbuf_or_widget_segment called
for gtk_text_buffer_create_child_anchor copy garbage from their stack-allocated
GtkTextIter into a clean iter. To work around this a GtkTextIter has to be
discraded after use in text buffer anchor inserting functions:
https://github.com/gotk3/gotk3/pull/307
So it's able to operate properly with the DnD gesture set by
gtk_drag_source_set(). We usually just react on button release,
that's the right time to claim the gesture.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1557
Signal emittion was added in 6f857f87dc commit and it seems that
this is only place where selected_row is set after emitting signal.
Because of this gtk_list_box_get_selected_row currently returns NULL
as selected row if selection mode is set to GTK_SELECTION_BROWSE.
...since one of the "fixes" there was wrong, at least cosmetically:
.get_position() is declared as returning a gboolean, which is in fact an
int in practice, but we should say what we mean, like we already did.
Make sure that the return types of the vfuncs match the ones that are
specified for post-atk-2.11.x AtkTableCellIface, since we already
require atk-2.15.1 and later.
icontheme: Recolor <polygon> elements in SVGs too
See merge request GNOME/gtk!443
(cherry picked from commit 5b049364dc)
284d9093 icontheme: Recolor <polygon> elements in SVGs too
If the revealer is told do animate and then unrealize itself, we do
(correctly) stop the animation, but used to do a shortcut where we
just set the target state as current.
Other things are dependent on the animation properly finishing though,
like the contained widget child visibility. This may lead to inconsistent
state where gtk_revealer_get_child_revealed() returns TRUE but the child
widget is unmapped, or vice-versa.
Fully finish the animation here, so the child state is coherent the next
time the revealer is mapped. We can also skip notifying on the property
since it will be handled by gtk_revealer_set_position().
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/316
If the child is not (partly) revealed, don’t allocate it, or we spam the
console with warnings about giving negative width to children’s gadgets.
We can check :child-visible, which is FALSE if (current&target)_pos == 0
Close https://gitlab.gnome.org/GNOME/gtk/issues/1057
Calling the accessibility function `grab_focus()` on a `GtkCell` under
Wayland will cause the client to crash.
This is another case of `gdk_x11_get_server_time()` being called
regardless of the actual windowing backend used.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
Surface returned from gtk_icon_helper_load_surface can be smaller
then requested pixel size. This happens when icon is embedded in
panel that has bigger size then loaded pixbuf.
Fixes#1280, tray icons not drawing background. This is a magic pattern only
usable for gdk_window_set_background_pattern() that sets the underlying
X window's background to ParentRelative.
`gtk_widget_accessible_grab_focus()` code checks that X11 isenabled at
build time and uses X11 specific functions such as
`gdk_x11_get_server_time()` regardless of the actual backend being used.
Check that we are using an X11 display when X11 is backend enabled, so
we do not crash when running on Wayland
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
- based on a patch by frederik.feichtmeier <frederik.feichtmeier@gmail.com>
I'm certain this is something we had initially, but can't recall
why we got rid of it for the more visually distracting dashed line.
We can always revert when Lapo shows up and slams us with that broken
use case. I'm guessing non-white bgs.
- So far it looks way less distracting than the dashed line
gtk_internal_return_val_if_fail operates only in debug mode,
quartz can call this with a NULL that crashes in
GTK_STYLE_PROVIDER_PRIVATE_GET_INTERFACE.
- introduce $menu_radius
- use it for menus and context-menus
- use the popover box-shadow also for menus
- use padding for menus to avoid edge overlapping
- remove the background for menus to avoid bleeding out of the round edges
Issue #1495 showed that the docs of GtkGrid retain outdated implications
that (as was once, but is no longer, the case) it is intended to replace
GtkBox, by discussing HfW and widget properties in a way that suggests
GtkBox can't handle them. But of course it does, and it's preferable for
simple single-row/column cases. Worse, we said GtkGrid “provides exactly
the same functionality” for the latter case, but the original point of
that Issues was that it doesn’t, at least for CSS positional selectors!
Box:
• Use an actually meaningful @Short_description.
• Remove unhelpful @See_also references to unrelated containers.
• Remove references to “rectangular area”: it might be another shape
via CSS, or “rectangular” might falsely imply 2 dimensions of children.
• Mention Orientable:orientation.
• Emphasise usefulness of :[hv]align for allocating in the other axis.
• Don’t say that Grid “provides exactly the same functionality” for a
single row or column, since (A) it is overkill for that case and (B)
said Issue proved that it *doesn’t* for CSS child order, for example.
• Note in the child properties that are remove in master that we have
better, preferred alternatives available now in GtkWidget/CSS props.
There’s no nice way to deprecate these, though they’re gone in GTK+ 4.
• Correct a copy-paste-o from the blurb of :expand to :fill.
Grid:
• Remove references to deprecated widgets: GtkTable and Gtk[HV]Box.
• Don’t dwell on widget properties and height-for-width in a way that
wrongly implies that Box can’t handle those (or Grid can better). In
fact, just get rid of that bit altogether: Box handles them fine, and
Table is so old as to be not worth mentioning (in anything except the
2 => 3 migration guide) and points to Grid in its deprecation notice.
• Point to GtkBox as being preferred for the simple row/column use case.
Append a variation selector to the Emoji sequences,
to force Emoji presentation. Without this, some
Emoji come out with text presentation by default.
Closes: Pango #334
- step back on toning down the borders. Flatness !> legibility.
- darker active state for light
- draw gradinets from bottom up, to keep px sized shading regardless
of button size.
We wrap SVG data from icons within another SVG with extra styling
information. The wrapped SVG may contain characters that cannot be
part of a data: URL (https://fetch.spec.whatwg.org/#data-urls).
Librsvg 2.45 got more strict in its parsing of data: URLs; whereas
previously it ignored '#' characters in them, now it considers them to
be the start of a fragment identifier, which is not allowed in data:
URLs anyway.
To avoid unallowed characters, we now create a data: URL with a
base-64 encoded SVG.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1471
We display a list of supported protocols in the server_addresses_popover.
However, this curated list contains protocols which may or may not be
available, depending on the respective gvfs backend being installed.
So, populate the list only with protocols which are available.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
When the user types an address with a schema that is not supported,
the Connect button doesn't become sensitive, but there is no visible
feedback at all.
This feels unresponsive and leaves the user clueless.
While it doesn't help explain why the address doesn't work, this will
provide a hint that the input was acknowledged but doesn't work.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
It is permissable to remove a widget using gtk_container_remove from the
gtk_container_foreach callback handler. Document this fact to make it
more discoverable.
Fixes#1461
Gives the same background color to all separators descending from a
title bar than to its direct childrens.
This prevents separators which are in a titlebar but not direct children
from the widget with the titlebar style class from being almost
transparent and hence it prevent them from revealing the clear color of
the window's titlebar (black).
https://gitlab.gnome.org/GNOME/gtk/issues/1231
This is better than nothing at all. The wording is taken from Carlos's
commit message when he added this shortly before 3.12, so add Since too.
Skip the bit from his commit message explaining what this replaced; we
don't need to say all the less good things our convenience API replaces.
- Selection mode does not get the special devel styling.
- removed teh last-child() selector for it doesn't work anymore.
Better style all section of the headerbar than none. Proper fix pending.
Commit 1c96b703 changed the way icon
information is given to DnD. Previously an icon helper was kept at
the drag source site. Now an image definition is stored there.
The difference is that icon helper is an object that changes its
state in response to an icon being set, thus the object survived
multiple icon changes. Whereas image definition is destroyed and
re-created from scratch every time a drag icon is changed.
This created a problem where gtk_drag_begin_internal() would receive
the value of site->image_def when a drag just began, then it emits
"drag-begin" signal, in response to which an application can
set drag icon, changing the value of site->image_def. However,
gtk_drag_begin_internal() is unable to know about that change and
continues to use the old value it received from up the stack.
Not only does it prevent drag icon from being set from "drag-begin",
it also can induce a crash, since the old image_def value used
by gtk_drag_begin_internal() points to a freed memory region.
Fix this by only setting a default icon (which is created in-place)
in gtk_drag_begin_internal() if the caller does not care about icons.
Otherwise gtk_drag_begin_internal() will return a boolean that indicates
whether an icon needs to be set. Then the caller can invoke
gtk_drag_set_icon_definition() to set the icon, if needed.
Fixes#1407.
gtk_drag_clear_source_info() immediately unrefs the info attached
to the context (the very same info we're in the process of destroying
in gtk_drag_source_info_free()). If that reference was the last one,
then accessing the info object after that is a use-after-free error.
Also, change the order a bit to first free the event, and only then
unref the context.
Fix this by copying all the fields of the info that we need, and
then working with these copies.
This was noticed in Firefox and demonstrated using a GtkBuilder ui file.
buildable_add_child() calls set_tab_label(), but the latter did nothing
to update the menu_label corresponding to that tab with the new text.
Using Builder to populate the tab child, only tabs other than last got
the right non-default labels, and even that was mostly coincidental, as
adding the main child called update_labels() via real_insert_page(), so
it took effect when the 2nd last main child is added, updating the rest
but leaving the last with the default label, not that given in Builder.
Fix by factoring out the code from child_reordered() to a new helper
menu_item_recreate() and calling that in set_tab_label(), so that
whenever the tab_label is updated, so is its corresponding menu_label.
This fixes the reported case and presumably others that we could write.
fixes https://gitlab.gnome.org/GNOME/gtk/issues/1397
The gtk_stack_snapshot_slide() function dereferences the
last_visible_child pointer without proper != NULL ckeck. This might
result in NULL pointer dereference and crash if last_visible_child is
invalid.
Add a != NULL check before dereferencing the pointer.
cherry-picked from https://gitlab.gnome.org/GNOME/gtk/merge_requests/361
Before the recent rework of positioning in GtkTooltip, the widget always
used the cursor_size of the GdkDisplay. That work redid this to instead
take GtkSettings::gtk-cursor-theme-size. But that property's doc says:
> Size to use for cursors, or 0 to use the default size.
and has 0 as its default. This is quite a likely scenario for anyone
whose desktop or settings.ini does not explicitly provide a cursor size,
which is the case for XFCE and win32, to name just two common platforms.
Then, it seems getting a cursor_size of 0 causes GtkTooltip to freak out
and hide/show itself at a very rapid speed, thus making it unusable.
So, we should check whether the Settings return 0 and, if so, still use
gdk_display_get_default_cursor_size (display) to ensure we get a size.
https://gitlab.gnome.org/GNOME/gtk/issues/1371
gtk_entry_event's goal is to detect if a specific event concerns one of the two
entry icons. It can happen that this function is called during initialization
and/or before the entry is realized. In this case the entry icons (and the
event) will not yet have an associated window. The code should consider the
aforementioned situation and avoid matching a icon and an event with no
associated windows.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1366
All the other conditionally visible child widgets have this. Without it,
it seems some cases can wrongly reveal it, with a nonsensical home icon.
https://gitlab.gnome.org/GNOME/gtk/issues/1345
There’s a short-path done for focus rectangles, but it can be taken in other conditions, and then fail occasionally to render a dashed line if the border-width is too big.
For building the introspection dumper program on Visual Studio, leave out
the G_LOG_DOMAIN as g-ir-scanner does not like it when it constructs the
compiler command line for Visual Studio.
Also ensure that we are looking for the freshly-built libraries by looking
for the .lib's from the output directories of the Visual Studio project files.
Simplify the styling of sidebar separators by not setting their borders
and margins rather than trying to drop it afterward, which was actually
not working anyway.
Make the selector less greedy to not remove the background on
non-titlebar headerbars contained in non-headerbar titlebars and only to
the ones contained in headerbar titlebars. This avoid issues in some
applications.
Also make dropping the background more agressive to actually remove it.
This is needed to work around headerbar sliding animation issues without
refactoring Adwaita's support of titlebars and headerbars as it may
break applications.
https://gitlab.gnome.org/GNOME/gtk/issues/1264
Let separators be declared as sidebars to have the same style as those
drawn by GtkStackSidebar. This also let them handle the selection-mode
class, whether they are assigned it or they descend from something in
selection mode.
This is convenient when building a custom sidebar using a GtkSeparator
and to extend a sidebar to the title bar.
A number of applications want to track the state of the screensaver.
Make this information available as a boolean property. We only listen
for state changes when ::register-session is set to TRUE.
This is implemented for unsandboxed D-Bus access by talking
directly to org.gnome.ScreenSaver or org.freedesktop.ScreenSaver,
and for sandboxed D-Bus by using a (new) portal API.
A Quartz implementation is missing.
After discussions on IRC, the conclusion was reached that deprecations
only make sense if an action can be taken to not use the deprecated code
that makes the code more current and simplifies a later port to a newer
GTK version.
In this particular case, the suitable action would be adding
gtk_widget_show() calls whenever a widget is created, so that a call to
show_all() is not necessary.
However, in GTK4 these calls would not be necessary and end up just
bloating the codebase unnecessarily.
So it was decided the better solution would be to not deprecate the API
and instead leave this work to be done during potential GTK4 ports of
applications.
This reverts commit 4d71d2303d.
Fixes!1282
When calling PickColor on org.gnome.Shell, we get back an "a{sv}", which
GDBus provides to us as "(a{sv})".
At the minute we're not unpacking this tuple, and so picking fails with
messages like:
GLib-CRITICAL **: 13:38:19.439: g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{o*}"))' failed
Gtk-WARNING **: 13:38:19.439: Picking color failed: No color received
Let's unpack it.
