mutter/src/core/frame.c

597 lines
18 KiB
C
Raw Normal View History

/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/* Mutter X window decorations */
2001-05-31 06:42:58 +00:00
2014-05-02 13:34:02 +00:00
/*
2001-05-31 06:42:58 +00:00
* Copyright (C) 2001 Havoc Pennington
* Copyright (C) 2003, 2004 Red Hat, Inc.
Merge of all the changes on the constraints_experiments branch. This is 2005-11-18 Elijah Newren <newren@gmail.com> Merge of all the changes on the constraints_experiments branch. This is just a summary, to get the full ChangeLog of those changes (approx. 2000 lines): cvs -q -z3 update -Pd -r constraints_experiments cvs -q -z3 diff -pu -r CONSTRAINTS_EXPERIMENTS_BRANCHPOINT ChangeLog Bugs fixed: unfiled - constraints.c is overly complicated[1] unfiled - constraints.c is not robust when all constraints cannot simultaneously be met (constraints need to be prioritized) unfiled - keep-titlebar-onscreen constraint is decoration unaware (since get_outermost_onscreen_positions() forgets to include decorations) unfiled - keyboard snap-moving and snap-resizing snap to hidden edges 109553 - gravity w/ simultaneous move & resize doesn't work 113601 - maximize vertical and horizontal should toggle and be constrained 122196 - windows show up under vertical panels 122670 - jerky/random resizing of window via keyboard[2] 124582 - keyboard and mouse snap-resizing and snap-moving erroneously moves the window multidimensionally 136307 - don't allow apps to resize themselves off the screen (*cough* filechooser *cough*) 142016, 143784 - windows should not span multiple xineramas unless placed there by the user 143145 - clamp new windows to screensize and force them onscreen, if they'll fit 144126 - Handle pathological strut lists sanely[3] 149867 - fixed aspect ratio windows are difficult to resize[4] 152898 - make screen edges consistent; allow easy slamming of windows into the left, right, and bottom edges of the screen too. 154706 - bouncing weirdness at screen edge with keyboard moving or resizing 156699 - avoid struts when placing windows, if possible (nasty a11y blocker) 302456 - dragging offscreen too restrictive 304857 - wireframe moving off the top of the screen is misleading 308521 - make uni-directional resizing easier with alt-middle-drag and prevent the occasional super annoying resize-the-wrong-side(s) behavior 312007 - snap-resize moves windows with a minimum size constraint 312104 - resizing the top of a window can cause the bottom to grow 319351 - don't instantly snap on mouse-move-snapping, remove braindeadedness of having order of releasing shift and releasing button press matter so much [1] fixed in my opinion, anyway. [2] Actually, it's not totally fixed--it's just annoying instead of almost completely unusable. Matthias had a suggestion that may fix the remainder of the problems (see http://tinyurl.com/bwzuu). [3] This bug was originally about not-quite-so-pathological cases but was left open for the worse cases. The code from the branch handles the remainder of the cases mentioned in this bug. [4] Actually, although it's far better there's still some minor issues left: a slight drift that's only noticeable after lots of resizing, and potential problems with partially onscreen constraints due to not clearing any fixed_directions flags (aspect ratio windows get resized in both directions and thus aren't fixed in one of them) New feature: 81704 - edge resistance for user move and resize operations; in particular 3 different kinds of resistance are implemented: Pixel-Distance: window movement is resisted when it aligns with an edge unless the movement is greater than a threshold number of pixels Timeout: window movement past an edge is prevented until a certain amount of time has elapsed during the operation since the first request to move it past that edge Keyboard-Buildup: when moving or resizing with the keyboard, once a window is aligned with a certain edge it cannot move past until the correct direction has been pressed enough times (e.g. 2 or 3 times) Major changes: - constraints.c has been rewritten; very few lines of code from the old version remain. There is a comment near the top of the function explaining the basics of how the new framework works. A more detailed explanation can be found in doc/how-constraints-works.txt - edge-resistance.[ch] are new files implementing edge-resistance. - boxes.[ch] are new files containing low-level error-prone functions used heavily in constraints.c and edge-resistance.c, among various places throughout the code. testboxes.c contains a thorough testsuite for the boxes.[ch] functions compiled into a program, testboxes. - meta_window_move_resize_internal() *must* be told the gravity of the associated operation (if it's just a move operation, the gravity will be ignored, but for resize and move+resize the correct value is needed) - the craziness of different values that meta_window_move_resize_internal() accepts has been documented in a large comment at the beginning of the function. It may be possible to clean this up some, but until then things will remain as they were before--caller beware. - screen and xinerama usable areas (i.e. places not covered by e.g. panels) are cached in the workspace now, as are the screen and xinerama edges. These get updated with the workarea in src/workspace.c:ensure_work_areas_validated()
2005-11-19 14:58:50 +00:00
* Copyright (C) 2005 Elijah Newren
2014-05-02 13:34:02 +00:00
*
2001-05-31 06:42:58 +00:00
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
2014-05-02 13:34:02 +00:00
*
2001-05-31 06:42:58 +00:00
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <http://www.gnu.org/licenses/>.
2001-05-31 06:42:58 +00:00
*/
#include "config.h"
#include "core/frame.h"
#include "backends/x11/meta-backend-x11.h"
#include "compositor/compositor-private.h"
#include "core/bell.h"
#include "core/keybindings-private.h"
#include "meta/meta-x11-errors.h"
#include "x11/meta-x11-display-private.h"
#include "x11/window-x11.h"
#include "x11/window-props.h"
2001-06-03 21:39:57 +00:00
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
#include <X11/Xatom.h>
#include <X11/extensions/shape.h>
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
2001-06-20 03:01:26 +00:00
#define EVENT_MASK (SubstructureRedirectMask | \
StructureNotifyMask | SubstructureNotifyMask | \
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
PropertyChangeMask | FocusChangeMask)
2001-06-20 03:01:26 +00:00
2001-06-03 01:33:27 +00:00
void
meta_window_ensure_frame (MetaWindow *window)
{
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
MetaX11Display *x11_display = window->display->x11_display;
unsigned long data[1] = { 1 };
meta_x11_error_trap_push (x11_display);
XChangeProperty (x11_display->xdisplay,
meta_window_x11_get_xwindow (window),
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
x11_display->atom__MUTTER_NEEDS_FRAME,
XA_CARDINAL,
32, PropModeReplace, (guchar*) data, 1);
meta_x11_error_trap_pop (x11_display);
}
void
meta_window_set_frame_xwindow (MetaWindow *window,
Window xframe)
{
MetaX11Display *x11_display = window->display->x11_display;
2001-06-03 01:33:27 +00:00
XSetWindowAttributes attrs;
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
gulong create_serial = 0;
MetaFrame *frame;
2014-05-02 13:34:02 +00:00
2001-06-03 01:33:27 +00:00
if (window->frame)
return;
2014-05-02 13:34:02 +00:00
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
frame = g_new0 (MetaFrame, 1);
2001-06-03 01:33:27 +00:00
frame->window = window;
frame->xwindow = xframe;
2001-06-03 01:33:27 +00:00
2001-06-09 21:58:30 +00:00
frame->rect = window->rect;
frame->child_x = 0;
frame->child_y = 0;
frame->bottom_height = 0;
frame->right_width = 0;
frame->borders_cached = FALSE;
2014-05-02 13:34:02 +00:00
meta_sync_counter_init (&frame->sync_counter, window, frame->xwindow);
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
window->frame = frame;
meta_verbose ("Frame geometry %d,%d %dx%d",
frame->rect.x, frame->rect.y,
frame->rect.width, frame->rect.height);
2014-05-02 13:34:02 +00:00
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
meta_verbose ("Setting frame 0x%lx for window %s, "
"frame geometry %d,%d %dx%d",
xframe, window->desc,
frame->rect.x, frame->rect.y,
frame->rect.width, frame->rect.height);
meta_stack_tracker_record_add (window->display->stack_tracker,
frame->xwindow,
create_serial);
meta_verbose ("Frame for %s is 0x%lx", frame->window->desc, frame->xwindow);
meta_x11_error_trap_push (x11_display);
attrs.event_mask = EVENT_MASK;
XChangeWindowAttributes (x11_display->xdisplay,
frame->xwindow, CWEventMask, &attrs);
2014-05-02 13:34:02 +00:00
if (META_X11_DISPLAY_HAS_SHAPE (x11_display))
XShapeSelectInput (x11_display->xdisplay, frame->xwindow, ShapeNotifyMask);
meta_x11_display_register_x_window (x11_display, &frame->xwindow, window);
2001-05-31 06:42:58 +00:00
if (window->mapped)
{
window->mapped = FALSE; /* the reparent will unmap the window,
* we don't want to take that as a withdraw
*/
meta_topic (META_DEBUG_WINDOW_STATE,
"Incrementing unmaps_pending on %s for reparent", window->desc);
window->unmaps_pending += 1;
}
meta_stack_tracker_record_remove (window->display->stack_tracker,
meta_window_x11_get_xwindow (window),
XNextRequest (x11_display->xdisplay));
XReparentWindow (x11_display->xdisplay,
meta_window_x11_get_xwindow (window),
2001-05-31 06:42:58 +00:00
frame->xwindow,
2014-05-28 14:49:42 +00:00
frame->child_x,
frame->child_y);
window->reparents_pending += 1;
/* FIXME handle this error */
meta_x11_error_trap_pop (x11_display);
2014-05-02 13:34:02 +00:00
/* Ensure focus is restored after the unmap/map events triggered
* by XReparentWindow().
*/
if (meta_window_has_focus (window))
window->restore_focus_on_map = TRUE;
2001-05-31 06:42:58 +00:00
/* stick frame to the window */
2001-06-04 06:17:52 +00:00
window->frame = frame;
meta_window_reload_property_from_xwindow (window, frame->xwindow,
x11_display->atom__NET_WM_SYNC_REQUEST_COUNTER,
TRUE);
meta_window_reload_property_from_xwindow (window, frame->xwindow,
x11_display->atom__NET_WM_OPAQUE_REGION,
TRUE);
meta_x11_error_trap_push (x11_display);
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
XMapWindow (x11_display->xdisplay, frame->xwindow);
meta_x11_error_trap_pop (x11_display);
2001-06-23 05:49:35 +00:00
/* Move keybindings to frame instead of window */
meta_window_grab_keys (window);
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
/* Even though the property was already set, notify
* on it so other bits of the machinery catch up
* on the new frame.
*/
g_object_notify (G_OBJECT (window), "decorated");
2001-05-31 06:42:58 +00:00
}
void
meta_window_destroy_frame (MetaWindow *window)
{
MetaFrame *frame;
MetaFrameBorders borders;
MetaX11Display *x11_display;
2014-05-02 13:34:02 +00:00
2001-05-31 06:42:58 +00:00
if (window->frame == NULL)
return;
x11_display = window->display->x11_display;
meta_verbose ("Unframing window %s", window->desc);
2014-05-02 13:34:02 +00:00
2001-05-31 06:42:58 +00:00
frame = window->frame;
meta_frame_calc_borders (frame, &borders);
2014-05-02 13:34:02 +00:00
2001-05-31 06:42:58 +00:00
/* Unparent the client window; it may be destroyed,
* thus the error trap.
*/
meta_x11_error_trap_push (x11_display);
if (window->mapped)
{
window->mapped = FALSE; /* Keep track of unmapping it, so we
* can identify a withdraw initiated
* by the client.
*/
meta_topic (META_DEBUG_WINDOW_STATE,
"Incrementing unmaps_pending on %s for reparent back to root", window->desc);
window->unmaps_pending += 1;
}
if (!x11_display->closing)
{
if (!window->unmanaging)
{
meta_stack_tracker_record_add (window->display->stack_tracker,
meta_window_x11_get_xwindow (window),
XNextRequest (x11_display->xdisplay));
}
XReparentWindow (x11_display->xdisplay,
meta_window_x11_get_xwindow (window),
x11_display->xroot,
/* Using anything other than client root window coordinates
* coordinates here means we'll need to ensure a configure
* notify event is sent; see bug 399552.
*/
window->frame->rect.x + borders.invisible.left,
window->frame->rect.y + borders.invisible.top);
window->reparents_pending += 1;
}
if (META_X11_DISPLAY_HAS_SHAPE (x11_display))
XShapeSelectInput (x11_display->xdisplay, frame->xwindow, NoEventMask);
XDeleteProperty (x11_display->xdisplay,
meta_window_x11_get_xwindow (window),
x11_display->atom__MUTTER_NEEDS_FRAME);
meta_x11_error_trap_pop (x11_display);
2001-05-31 06:42:58 +00:00
/* Ensure focus is restored after the unmap/map events triggered
* by XReparentWindow().
*/
if (meta_window_has_focus (window))
window->restore_focus_on_map = TRUE;
meta_x11_display_unregister_x_window (x11_display, frame->xwindow);
2014-05-02 13:34:02 +00:00
2001-05-31 06:42:58 +00:00
window->frame = NULL;
g_clear_pointer (&window->frame_bounds, mtk_region_unref);
g_clear_pointer (&frame->opaque_region, mtk_region_unref);
2001-06-23 05:49:35 +00:00
/* Move keybindings to window instead of frame */
meta_window_grab_keys (window);
2014-05-02 13:34:02 +00:00
meta_sync_counter_clear (&frame->sync_counter);
2001-05-31 06:42:58 +00:00
g_free (frame);
2014-05-02 13:34:02 +00:00
2001-06-04 06:17:52 +00:00
/* Put our state back where it should be */
if (!window->unmanaging)
meta_compositor_sync_updates_frozen (window->display->compositor, window);
Refactor thrice-duplicated queue code in window.c. Closes #376760. 2007-06-10 Thomas Thurman <thomas@thurman.org.uk> Refactor thrice-duplicated queue code in window.c. Closes #376760. * src/window.c (meta_window_queue, meta_window_unqueue): New functions. * src/window.[ch] (meta_window_unqueue_*, meta_window_queue_*): Removed functions. * src/window.c (meta_window_new_with_attrs, meta_window_free, meta_window_flush_calc_showing, queue_calc_showing_func, meta_window_minimize, meta_window_unminimize, meta_window_maximize, meta_window_make_fullscreen, meta_window_shade, meta_window_unshade, meta_window_move_resize_internal, window_stick_impl, window_unstick_impl, meta_window_client_message, process_property_notify): Modified to use new queueing functions. * src/window.c (idle_move_resize, idle_update_icon, idle_calc_showing): update to receive queue number from pointer. * src/window.h (MetaQueueType): new enum. * src/window.h (MetaWindow): *_queued replaced with is_in_queue bitfield. * src/core.c (meta_core_queue_frame_resize): * src/display.c (event_callback, meta_display_queue_retheme_all_windows): Using new queueing functions. * src/frame.c (meta_window_destroy_frame): Using new queueing functions. * src/screen.c (queue_resize, meta_screen_resize_func, queue_windows_showing): Using new queueing functions. * src/window-props.c (reload_mwm_hints, reload_wm_hints, reload_transient_for): Using new queueing functions. * src/workspace.c (meta_workspace_add_window, meta_workspace_remove_window, meta_workspace_queue_calc_showing, meta_workspace_invalidate_work_area): Using new queueing functions. svn path=/trunk/; revision=3236
2007-06-11 01:15:33 +00:00
meta_window_queue (window, META_QUEUE_CALC_SHOWING);
meta_window_queue (window, META_QUEUE_MOVE_RESIZE);
2001-05-31 06:42:58 +00:00
}
void
meta_frame_borders_clear (MetaFrameBorders *self)
{
self->visible.top = self->invisible.top = self->total.top = 0;
self->visible.bottom = self->invisible.bottom = self->total.bottom = 0;
self->visible.left = self->invisible.left = self->total.left = 0;
self->visible.right = self->invisible.right = self->total.right = 0;
}
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
static void
meta_frame_query_borders (MetaFrame *frame,
MetaFrameBorders *borders)
{
MetaWindow *window = frame->window;
MetaX11Display *x11_display = window->display->x11_display;
int format, res;
Atom type;
unsigned long nitems, bytes_after;
unsigned char *data;
if (!frame->xwindow)
return;
meta_x11_error_trap_push (x11_display);
res = XGetWindowProperty (x11_display->xdisplay,
frame->xwindow,
x11_display->atom__GTK_FRAME_EXTENTS,
0, 4,
False, XA_CARDINAL,
&type, &format,
&nitems, &bytes_after,
(unsigned char **) &data);
if (meta_x11_error_trap_pop_with_return (x11_display) != Success)
return;
if (res == Success && nitems == 4)
{
borders->invisible = (MetaFrameBorder) {
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
((long *) data)[0],
((long *) data)[1],
((long *) data)[2],
((long *) data)[3],
};
}
g_clear_pointer (&data, XFree);
meta_x11_error_trap_push (x11_display);
res = XGetWindowProperty (x11_display->xdisplay,
frame->xwindow,
x11_display->atom__MUTTER_FRAME_EXTENTS,
0, 4,
False, XA_CARDINAL,
&type, &format,
&nitems, &bytes_after,
(unsigned char **) &data);
if (meta_x11_error_trap_pop_with_return (x11_display) != Success)
return;
if (res == Success && nitems == 4)
{
borders->visible = (MetaFrameBorder) {
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
((long *) data)[0],
((long *) data)[1],
((long *) data)[2],
((long *) data)[3],
};
}
g_clear_pointer (&data, XFree);
borders->total = (MetaFrameBorder) {
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
borders->invisible.left + frame->cached_borders.visible.left,
borders->invisible.right + frame->cached_borders.visible.right,
borders->invisible.top + frame->cached_borders.visible.top,
borders->invisible.bottom + frame->cached_borders.visible.bottom,
};
}
2001-06-18 03:24:25 +00:00
void
meta_frame_calc_borders (MetaFrame *frame,
MetaFrameBorders *borders)
2001-06-18 03:24:25 +00:00
{
/* Save on if statements and potential uninitialized values
* in callers -- if there's no frame, then zero the borders. */
if (frame == NULL)
meta_frame_borders_clear (borders);
else
{
if (!frame->borders_cached)
{
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
meta_frame_query_borders (frame, &frame->cached_borders);
frame->borders_cached = TRUE;
}
*borders = frame->cached_borders;
}
}
void
meta_frame_clear_cached_borders (MetaFrame *frame)
{
frame->borders_cached = FALSE;
2001-06-18 03:24:25 +00:00
}
gboolean
2001-06-10 03:17:15 +00:00
meta_frame_sync_to_window (MetaFrame *frame,
gboolean need_resize)
2001-06-03 01:33:27 +00:00
{
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
MetaWindow *window = frame->window;
MetaX11Display *x11_display = window->display->x11_display;
meta_topic (META_DEBUG_GEOMETRY,
"Syncing frame geometry %d,%d %dx%d (SE: %d,%d)",
frame->rect.x, frame->rect.y,
frame->rect.width, frame->rect.height,
frame->rect.x + frame->rect.width,
frame->rect.y + frame->rect.height);
2001-06-10 03:17:15 +00:00
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
meta_x11_error_trap_push (x11_display);
XMoveResizeWindow (x11_display->xdisplay,
frame->xwindow,
frame->rect.x,
frame->rect.y,
frame->rect.width,
frame->rect.height);
meta_x11_error_trap_pop (x11_display);
2001-06-03 21:39:57 +00:00
return need_resize;
}
MtkRegion *
meta_frame_get_frame_bounds (MetaFrame *frame)
{
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
MetaFrameBorders borders;
MtkRegion *bounds;
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
meta_frame_calc_borders (frame, &borders);
/* FIXME: currently just the client area, should shape closer to
* frame border, incl. rounded corners.
*/
bounds = mtk_region_create_rectangle (&(MtkRectangle) {
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
borders.total.left,
borders.total.top,
frame->rect.width - borders.total.left - borders.total.right,
frame->rect.height - borders.total.top - borders.total.bottom,
});
return bounds;
2001-06-03 21:39:57 +00:00
}
void
meta_frame_get_mask (MetaFrame *frame,
MtkRectangle *frame_rect,
cairo_t *cr)
{
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
MetaFrameBorders borders;
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
meta_frame_calc_borders (frame, &borders);
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
cairo_rectangle (cr,
0, 0,
frame->rect.width,
frame->rect.height);
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
cairo_set_source_rgb (cr, 0, 0, 0);
cairo_fill (cr);
2002-08-23 18:00:40 +00:00
}
Window
meta_frame_get_xwindow (MetaFrame *frame)
{
return frame->xwindow;
}
static void
send_configure_notify (MetaFrame *frame)
{
MetaX11Display *x11_display = frame->window->display->x11_display;
XEvent event = { 0 };
/* We never get told by the frames client, just reassert the
* current frame size.
*/
event.type = ConfigureNotify;
event.xconfigure.display = x11_display->xdisplay;
event.xconfigure.event = frame->xwindow;
event.xconfigure.window = frame->xwindow;
event.xconfigure.x = frame->rect.x;
event.xconfigure.y = frame->rect.y;
event.xconfigure.width = frame->rect.width;
event.xconfigure.height = frame->rect.height;
event.xconfigure.border_width = 0;
event.xconfigure.above = None;
event.xconfigure.override_redirect = False;
meta_x11_error_trap_push (x11_display);
XSendEvent (x11_display->xdisplay,
frame->xwindow,
False, StructureNotifyMask, &event);
meta_x11_error_trap_pop (x11_display);
}
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
gboolean
meta_frame_handle_xevent (MetaFrame *frame,
XEvent *xevent)
{
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
MetaWindow *window = frame->window;
MetaX11Display *x11_display = window->display->x11_display;
if (xevent->xany.type == PropertyNotify &&
xevent->xproperty.state == PropertyNewValue &&
(xevent->xproperty.atom == x11_display->atom__GTK_FRAME_EXTENTS ||
xevent->xproperty.atom == x11_display->atom__MUTTER_FRAME_EXTENTS))
{
meta_window_frame_size_changed (window);
meta_window_queue (window, META_QUEUE_MOVE_RESIZE);
return TRUE;
}
else if (xevent->xany.type == PropertyNotify &&
xevent->xproperty.state == PropertyNewValue &&
(xevent->xproperty.atom == x11_display->atom__NET_WM_SYNC_REQUEST_COUNTER ||
xevent->xproperty.atom == x11_display->atom__NET_WM_OPAQUE_REGION))
{
meta_window_reload_property_from_xwindow (window, frame->xwindow,
xevent->xproperty.atom, FALSE);
return TRUE;
}
else if (xevent->xany.type == ConfigureRequest &&
xevent->xconfigurerequest.window == frame->xwindow)
{
send_configure_notify (frame);
return TRUE;
}
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
return FALSE;
}
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
GSubprocess *
meta_frame_launch_client (MetaX11Display *x11_display,
const char *display_name)
{
x11: Integrate frames client into Mutter Replace the in-process implementation of frames with the external frames client. When a client window is created and managed by Mutter, Mutter will determine whether it is a window that requires decorations and hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME property on the client window. After the frames client created a window that has the _MUTTER_FRAME_FOR property, Mutter will proceed to reparent the client window on the frame window, and show them as a single unit. Rendering and event handling on the frame window will be performed by the external client, Mutter is still responsible for everything else, namely resizing client and frame window in synchronization, and managing updates on the MetaWindowActor. In order to let the frame be managed by the external client, Mutter needs to change the way some properties are forwarded to the client and/or frame windows. Some properties are necessary to keep propagating to the client window only, some others need to happen on the frame window now, and some others needs to be propagated on both so they are synchronized about the behavior. Also, some events that were previously totally unexpected in frame windows are now susceptible to happen, so must be allowed now. MetaFrame in src/core/frame.c now acts as the wrapper of foreign windows created by the frames client, from the Mutter side. Location, size, and lifetime are still largely in control of Mutter, some details like visible/invisible borders are obtained from the client instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS properties, respectively). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-08 08:35:47 +00:00
g_autoptr(GSubprocessLauncher) launcher = NULL;
g_autoptr (GError) error = NULL;
GSubprocess *proc;
const char *args[2];
args[0] = MUTTER_LIBEXECDIR "/mutter-x11-frames";
args[1] = NULL;
launcher = g_subprocess_launcher_new (G_SUBPROCESS_FLAGS_NONE);
g_subprocess_launcher_setenv (launcher, "DISPLAY", display_name, TRUE);
proc = g_subprocess_launcher_spawnv (launcher, args, &error);
if (error)
{
if (g_error_matches (error, G_SPAWN_ERROR, G_SPAWN_ERROR_NOENT))
{
/* Fallback case for uninstalled tests, relies on CWD being
* the builddir, as it is the case during "ninja test".
*/
g_clear_error (&error);
args[0] = "./src/frames/mutter-x11-frames";
proc = g_subprocess_launcher_spawnv (launcher, args, &error);
}
if (error)
{
g_warning ("Could not launch X11 frames client: %s", error->message);
return NULL;
}
}
return proc;
}
/**
* meta_frame_type_to_string:
* @type: a #MetaFrameType
*
* Converts a frame type enum value to the name string that would
* appear in the theme definition file.
*
* Return value: the string value
*/
const char *
meta_frame_type_to_string (MetaFrameType type)
{
switch (type)
{
case META_FRAME_TYPE_NORMAL:
return "normal";
case META_FRAME_TYPE_DIALOG:
return "dialog";
case META_FRAME_TYPE_MODAL_DIALOG:
return "modal_dialog";
case META_FRAME_TYPE_UTILITY:
return "utility";
case META_FRAME_TYPE_MENU:
return "menu";
case META_FRAME_TYPE_BORDER:
return "border";
case META_FRAME_TYPE_ATTACHED:
return "attached";
case META_FRAME_TYPE_LAST:
break;
}
return "<unknown>";
}
MetaSyncCounter *
meta_frame_get_sync_counter (MetaFrame *frame)
{
return &frame->sync_counter;
}
void
meta_frame_set_opaque_region (MetaFrame *frame,
MtkRegion *region)
{
MetaWindow *window = frame->window;
if (mtk_region_equal (frame->opaque_region, region))
return;
g_clear_pointer (&frame->opaque_region, mtk_region_unref);
if (region != NULL)
frame->opaque_region = mtk_region_ref (region);
meta_compositor_window_shape_changed (window->display->compositor, window);
}