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.
If the size was constrained by the xdg_positioner mechanisms, we handle
the resize by resizing the popup window. What we shouldn't do is
hide/show the popup window so avoid that.
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
Instead of from the IMContextQuartz's client window because the former
is the event window where the text will be inserted. In some cases
they're different and the text may be discarded (because the client
window isn't editable) or misplaced.
Fixes Bug 707945.
The cache key is just the name of the cursor, so if a previously added
cursor had e.g. scale == 1, if we ask for a new cursor with scale == 2,
we might still fetch the scale == 1 cursor from the cache. Avoid this by
making sure the scale of the cached one is correct.
If it isn't, load the cursor as normal, and update the cache entry with
the new properly scaled cursor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1183
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.
CGDisplayModeGetWidth returns 0 if mode is NULL; that happens if the
CGDisplay is offline or mirroring another monitor and it leads to a
divide-by-zero crash.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1565
