This comment was added in 93bcca7f02 but missed a
colon so it never actually generated documentation and the nullable annotation
never made it into GObject-introspection language bindings.
This crude regex does not catch any other instances of this mistake. The @
symbol is used to disambiguate signal doc comments from property doc comments,
since property docs usually don't have parameters.
$ pcre2grep -rM '\\* [A-Z][A-Za-z]*:([a-z\-]*):\n +\* @' gtk/
Epiphany is doing something weird after calling gtk_window_close(),
because by the time the callback executes, the window has no GdkWindow.
Frankly, I don't know what's happening there, but we should probably not
crash.
Fixes#2424
Decoration node for drawing is used only for client side decorated
windows, but corners from opaque region is subtracted also for
normal windows.
Rename function to better reflect what it does and do not subtract
corners if decoration node was not used for drawing.
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
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
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.
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.
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.
CSD titlebar are included in the focus-chain. The logic used makes sure that the
initial focus avoids the titlebar, but tabbing around will eventually get there.
This logic fails in case the window has no other focusable widgets apart from
the ones in the header-bar. If this happens keynav focus will be lost. To handle
the above scenario, we need to fallback to focus the header-bar (if any).
Fixes: https://gitlab.gnome.org/GNOME/gnome-software/issues/404
The opaque region is only set when the background color is opaque. So
we need to do something about it when the background color changes.
However, in the case where a size allocation is going to happen, we
already do this update in size_allocate(), so in that case avoid doing
it twice.
According to the spec compositors were to assume surfaces are CSD until
told otherwise. This means we need to send
org_kde_kwin_server_decoration_request_mode in both cases.
This fixes libreoffice under kwin, which would remove it's own headers
as per the manager's request but not inform kwin leaving it in the even
more broken state of having none.
meta-pick of commit c1573a1fda: the
variable gdk_window is used in a check, but we may as well use it again
to avoid calling _gtk_widget_get_window() again unnecessarily.
application/x-rootwindow-drop is not useful anywhere else,
so put it under #ifdef GDK_WINDOWING_X11
On W32 this prevents toplevels from automatically becoming valid
drop targets with a useless drop type.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
This has no practical effect on Adwaita, but might fix some
third-party themes that were broken by GTK+ 3.22.23.
Signed-off-by: Simon McVittie <smcv@debian.org>
https://bugzilla.gnome.org/show_bug.cgi?id=789357
If the compositor prefers server-side decorations and the client doesn't
customize the title bar, we disable client-side decorations and let the
compositor know. Otherwise, we continue to use client-side decorations.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781909
The last touch on this patch series is making GtkWindow able to
selectively adjust various UI details based on the different
tiled edges. The main driver here is that we don't want to show
shadows on edges that are constrained.
This patch adds the necessary code to do that, while still
maintaining compatibility with the old ways.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
GTK windows don't have their tiling states really
hooked into the client-side decoration code, and
the only effect it has is disabling the resizing
edges.
With the introduction of per-edge tiling information,
we are backed by much more precise data on how the
window manager wants the app to behave.
This patch, then, fixes GtkWindow to take into account
per-edge tiling information. For compatibility purposes,
the previous tiled field was kept, and thing will just
continue working if no edge information is supplied.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Clarify that ::destroy, not ::hide*, removes a window from its app, by
replacing the mention of open windows with the blurb on destruction from
:application, completing commit 7db4bee4b6
Also link to the equivalent gtk_application_(add|remove)_window() calls,
since Application.add_window() already links back to Window:application.
* unless you use gtkmm…
https://bugzilla.gnome.org/show_bug.cgi?id=639931
Do not connect to get_settings_for_screen() if we have no screen…
Use g_signal_connect(), not connect_object(), to match how set_screen()
makes these same connections, and how finalize() already disconnects.
https://bugzilla.gnome.org/show_bug.cgi?id=705640
The user data passed when exporting a Wayland window was supposed to be
freed using the destroy_func, as is commonly done. This was previously
broken, as the user data was just NULL:ed when exported, and only
actually destroyed when unexporting before having exported.
While e016d9a5db fixed this, it introduced
a regression, as GtkWindow was nice enough to free the memory anyway
after having received the exported handle, causing it now to double
free.
https://bugzilla.gnome.org/show_bug.cgi?id=782109
Setting the shadow width earlier as done with commit 4cb1b96 to address
bug 771561 proved to cause unexpected side effects on size_allocate
signal propagation.
As the window is sized correctly earlier, the size_allocate signal is
not emitted again in gtk_widget_size_allocate_with_baseline() which
prevents clutter-gtk from relocating its child widget correctly.
To avoid this issue, revert commit 4cb1b96 but make sure the values
passed as min and max size is never negative in Wayland as this is a
protocol error.
With this, the min/max size will be wrong for a short amount of time,
during the state transition, until the shadow width is updated from
gdk_window_set_shadow_width().
This approach is much safer and less intrusive than changing the
size_allocate logic in gtk.
This reverts commit 4cb1b9645e.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=771915
Otherwise, with CSD, we could have a discrepancy where gtk uses the
right values for the shadows whereas the gdk backend still uses the old
values, leading in some cases to invalid or negative min size being
computed (which, in Wayland, leads a protocol error).
https://bugzilla.gnome.org/show_bug.cgi?id=771561
The main corpus of the documentation for gtk_window_get_size() is still
full of X11-isms, so we should port it to something that is more
backend-agnostic. Additionally, having some examples would be nice for
application authors looking at a way to appropriately use this function.
