This changes the configure option into two states:
auto: build all that can be build (default)
A list of backend names: build them and fail if we can't
"papi" is missing because it's not in Debian and I can't test it.
The autotools build uses relative filenames here while with meson
we get absolute paths. Switch to basename so we get the same result
for both and don't break reproducible builds with absolute paths
in public headers.
Build the input modules for GTK+, either as modules or built directly
into GTK. Also provide a configure option to build the specified
immodules, or all, or the backend immodule(s) or none of the immodules
into GTK. Note that for Visual Studio all immodules are built into
the GTK DLL by default, like what is done in the Visual Studio projects.
Note that building the backend immodules for Quartz, X11 and Wayland are
currently untested.
This will ensure that the version info is easily visible from the
GDK/GTK+ DLLs, and ensure that the print dialogs will have a more modern
look and feel.
Otherwise, it errors out on make distcleancheck in debian packaging
```
ERROR: files left in build directory after distclean:
./gtk/gtktypefuncs.c
make[1]: *** [Makefile:1005: distcleancheck] Error 1
```
Add private API to GDK to move these variables from the environment into
static scope. Also move the DESKTOP_STARTUP_ID validation here to reduce
code duplication.
Use constructors to read them as early as possible; however, do not
unset them until first requested. This avoids breaking gnome-shell and
gnome-settings-daemon, which want to use the DESKTOP_AUTOSTART_ID in
their own gnome-session clients.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1761
They're either wrong (when using FALSE because the widgets don't account
for changes to the CSS) or unnecessary (when using TRUE because it's the
default).
Fixes!1777
The above flags in combination with "-fvisibility=hidden" break the
g-i build because it results in the g-i generated dumper executable not
linking against the libraries because they are detected as unused and
thrown out.
Fix by only using -fvisibility=hidden for the library and not g-i.
Look for subdirectories named "gtk-3.x", where 'x' starts as current
minor version and counts down to 14, then drops to 0.
Only look for gtk.css in these directories though. If a theme only
provides gtk-dark.css, it won't be found.
- Rather than making labeled buttons inside lists toned down,
only tone down image buttons, so that we don't have to include
icon-only actions. Places like Software can continue using label
buttons with no change without having those less visible.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1748
The problem here was that NSPasteboard would release the clipboard
owner if all data items were transferred. When trying to re-use this
owner at a later point, GTK+ would attempt a retain call on a released
object and crash.
Fix this by not immediately releasing the owner after declaring types,
so by keeping our own reference around.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/529
It might be too late to do it at GtkApplication::add_platform_data time,
since the envvar may be consumed earlier on if gdk_display_open() happened
to be called before (eg. through gtk_get_option_group(TRUE)).
Stash the envvar in a constructor function, so its ensured to happen before
it can get consumed.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1754
This is named gdkconstructor.h to avoid any possible conflicts. This fixes
the current usages of G_HAS_CONSTRUCTORS, as that header is not installed
by glib.
CREATEPROCESS_MANIFEST_RESOURCE_ID is a macro defined in winbase.h,
so we need an include to resolve that macro to its value, 1.
Without that it stays as a literal CREATEPROCESS_MANIFEST_RESOURCE_ID,
and ends up in the .exe file as-is, and Windows can't find it by that name,
resulting in UAC manifest not working and gtk-update-icon-cache bringing
up UAC prompt.
Every time a new <INCLUDE> directive is used inside a gtk-doc
sections.txt file it overrides the current include header until the next
<INCLUDE> directive. This has the unfortunate effect of making every
single section following the print-related ones to generate
documentation that says to include gtkunixprint.h.
In order to avoid re-arranging the gtk3-sections.txt file, we can tell
gtk-doc what's the default header to include for GTK, and override it
using `@Include` directives directly into the gtk-doc stanzas of the
sections that require a different header.
Fixes: #1746
including when the control modifier is present, i.e. when one is typing
control-I for instance.
Orca would convert them back to the corresponding ASCII letter anyway, and
when pressing control-tab, we do want to pass "tab", not pass "\t" that Orca
would erroneously convert to "control-I".
Fixes#1743
If the query has a non-null location, set the scope to that directory,
otherwise set it to the local computer.
There is unfortunately no way to get Spotlight to search
non-recursively, nor does NSFileManager offer a convenient search of
the contents of a directory's regular files.
Copy documentation for gtk_clipboard_wait_for_targets from gtk/gtkclipboard.c
to quartz implementation. Primarily to add transfer container annotation as
otherwise pygobject tries to deallocate individual GdkAtoms.
Issue #1584.
In case the theme doesn't set a height/min-height for the treeview
separator the treeview drawing gets confused and draws rows on top of each
other depending on the redraw area.
This is due to gtk_tree_view_get_row_height() assuming that a node with a
height <= 0 is not set and not a separator and it will default to the
expander size.
Ideally gtk_tree_view_get_row_height() would know if it operates on a separator,
but there are too many calls/levels, so just make sure the separator height
is at least 1 (Adwaita already sets "min-height: 2px", so no change there)
GtkMenu's "accel-group" property setter, gtk_menu_set_accel_group(),
currently returns in failure if the caller passes it a NULL `accel_group`
argument. This argument is annotated with `(allow-none)`. This patch
add support for the NULL case.
When 0 or GDK_CURRENT_TIME is passed to gtk_window_present_with_time(),
print a warning so that the application developer knows that this isn't
a supported use of the function, but carry on working for now.
If the column used for the GtkTreeView:tooltip-column contains NULL
we're already skipping a tooltip; let's ignore empty strings as well,
as an empty tooltip is pretty much pointless.
Close#1681
We're using [a-z] ranges with sed and grep, and POSIX does not specify
their behaviour in non-ASCII locales:
In the POSIX locale, a range expression represents the set of
collating elements that fall between two elements in the collation
sequence, inclusive. In other locales, a range expression has
unspecified behavior
-- IEEE Std 1003.1-2017, § 9.3.5 (7)
This can lead to no results, or invalid replacements, which in turn can
lead to broken builds or broken build artifacts.
Fixes: #1662
When we receive a size from the move-to-rect implementation, force GTK
to continue using that size until reconfigured by move-to-rect, or
when remapped.
Fixes: #1651
On X11, the position of the menu is calculated synchronously by
gdk_window_move_to_rect(). This means that calculating the window size
when showing is too late, as that'd mean the size used when calculating
the position is out-of-date. The first time a menu is mapped, however,
the size is calculated during realization; but a window is only realized
once, so it doesn't work for subsequent maps.
Currently, this is harmless, as a GtkMenu can change its size however it
wants after it has been mapped. This, however, is problematic, as it
means the position calculated by gdk_window_move_to_rect() might no
longer be valid, or constraints made by the same function might no
longer be respected.
Thus, this is a preparation for making GtkMenu popups stay the same size
until they are remapped again at a later point.
Sometimes (read for GtkMenu on X11) it's not enough to resize on show,
and relying on the size to be calculated on realization only works the
first time a menu is popped up, so add an API that GtkMenu can use to
ensure the size of a menu is "refreshed" before passing anything along
to gdk_window_move_to_rect().
This causes window size guessing to always use the remembered size (the
size of the GdkWindow). This will be useful for menus which size is
managed by gdk_window_move_to_rect(), to avoid overriding the size
calculated by the move-to-rect implementation.
We don't need to do it, since g_clear_pointer() will do it for us, and
will also check if the function conforms to a GDestroyNotify. Using an
explicit cast will generate a compiler warning.
Now that we've switched the on and off states to gadgets, we need to
ensure that the widget's clip take into account the clip of every
gadget.
Fixes#1631
Improve overflow arrow buttons drawing on a scrollable dropdown menu:
reduce top button's margin-top to match size of a bottom button, add
margin-top for bottom button to compensate bottom margin (otherwise
button overlaps with menu content).
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1539
- it's less busy and still clearer without the label
- It may be right that color alone is a poor differentiator,
but labels do still exist for the accessible theme.
- 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
- 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.
