2006-10-01 18:30:10 -04:00
|
|
|
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
|
|
|
|
|
|
Comprehensively rename to Mutter
Code:
All references in the code not related to themes, keybindings, or
GConf were changed from 'metacity' to 'mutter'. This includes, among other
things, strings, comments, the atoms used in the message protocol, and
the envvars used for debugging. The GConf schema file was reduced to
the 3 settings new to mutter.
The overall version was brought up to 2.27 to match current gnome.
Structure:
All files named '*metacity*' were renamed '*mutter*' with appropriate
changes in the automake system. Files removed are
doc/creating_themes, src/themes, doc/metacity-theme.dtd,
metacity.doap. These files will eventually end up in an external
gnome-wm-data module.
Installation location:
On the filesystem the mutter-plugindir was change from
$(libdir)/metacity/plugins/clutter to just $(libdir)/mutter/plugins.
The mutter-plugins.pc.in reflects these changes.
Note:
mutter.desktop.in and mutter-wm.desktop both continue to have
X-GNOME-WMSettingsModule=metacity set. This allows
gnome-control-center to continue using libmetacity.so for
configuration. This is fine since most the general keybindings and wm
settings are being read from /apps/metacity/* in gconf.
2009-06-10 06:29:20 -04:00
|
|
|
/* Mutter X window decorations */
|
2001-05-31 02:42:58 -04:00
|
|
|
|
2014-05-02 09:34:02 -04:00
|
|
|
/*
|
2001-05-31 02:42:58 -04:00
|
|
|
* Copyright (C) 2001 Havoc Pennington
|
2004-08-26 22:17:49 -04:00
|
|
|
* 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 09:58:50 -05:00
|
|
|
* Copyright (C) 2005 Elijah Newren
|
2014-05-02 09:34:02 -04:00
|
|
|
*
|
2001-05-31 02:42:58 -04: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 09:34:02 -04:00
|
|
|
*
|
2001-05-31 02:42:58 -04:00
|
|
|
* You should have received a copy of the GNU General Public License
|
2014-01-11 20:42:06 -05:00
|
|
|
* along with this program; if not, see <http://www.gnu.org/licenses/>.
|
2001-05-31 02:42:58 -04:00
|
|
|
*/
|
|
|
|
|
|
2018-07-10 04:36:24 -04:00
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
|
|
#include "core/frame.h"
|
|
|
|
|
|
2014-07-10 13:29:20 -04:00
|
|
|
#include "backends/x11/meta-backend-x11.h"
|
2018-07-10 04:36:24 -04:00
|
|
|
#include "core/bell.h"
|
|
|
|
|
#include "core/keybindings-private.h"
|
|
|
|
|
#include "meta/meta-x11-errors.h"
|
2017-08-26 12:26:30 -04:00
|
|
|
#include "x11/meta-x11-display-private.h"
|
2001-06-03 17:39:57 -04: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 04:35:47 -04:00
|
|
|
#include <X11/Xatom.h>
|
|
|
|
|
|
2001-06-19 23:01:26 -04: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 04:35:47 -04:00
|
|
|
PropertyChangeMask | FocusChangeMask)
|
2001-06-19 23:01:26 -04:00
|
|
|
|
2001-06-02 21:33:27 -04: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 04:35:47 -04:00
|
|
|
MetaX11Display *x11_display = window->display->x11_display;
|
|
|
|
|
unsigned long data[1] = { 1 };
|
|
|
|
|
|
|
|
|
|
meta_x11_error_trap_push (x11_display);
|
|
|
|
|
|
|
|
|
|
XChangeProperty (x11_display->xdisplay,
|
|
|
|
|
window->xwindow,
|
|
|
|
|
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-02 21:33:27 -04: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 04:35:47 -04:00
|
|
|
gulong create_serial = 0;
|
|
|
|
|
MetaFrame *frame;
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2001-06-02 21:33:27 -04:00
|
|
|
if (window->frame)
|
|
|
|
|
return;
|
2014-05-02 09:34:02 -04: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 04:35:47 -04:00
|
|
|
frame = g_new0 (MetaFrame, 1);
|
2001-06-02 21:33:27 -04:00
|
|
|
|
|
|
|
|
frame->window = window;
|
|
|
|
|
frame->xwindow = None;
|
|
|
|
|
|
2001-06-09 17:58:30 -04:00
|
|
|
frame->rect = window->rect;
|
|
|
|
|
frame->child_x = 0;
|
|
|
|
|
frame->child_y = 0;
|
|
|
|
|
frame->bottom_height = 0;
|
|
|
|
|
frame->right_width = 0;
|
|
|
|
|
|
2013-11-15 17:37:50 -05:00
|
|
|
frame->borders_cached = FALSE;
|
2014-05-02 09:34:02 -04: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 04:35:47 -04:00
|
|
|
window->frame = frame;
|
|
|
|
|
|
2020-10-02 11:47:22 -04:00
|
|
|
meta_verbose ("Frame geometry %d,%d %dx%d",
|
2002-04-22 14:18:38 -04:00
|
|
|
frame->rect.x, frame->rect.y,
|
|
|
|
|
frame->rect.width, frame->rect.height);
|
2014-05-02 09:34:02 -04: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 04:35:47 -04: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);
|
|
|
|
|
|
|
|
|
|
frame->xwindow = xframe;
|
2015-01-01 00:55:36 -05:00
|
|
|
|
2017-08-26 13:03:51 -04:00
|
|
|
meta_stack_tracker_record_add (window->display->stack_tracker,
|
2014-09-08 21:20:14 -04:00
|
|
|
frame->xwindow,
|
2009-06-13 16:45:32 -04:00
|
|
|
create_serial);
|
2003-08-16 12:32:10 -04:00
|
|
|
|
2020-10-02 11:47:22 -04:00
|
|
|
meta_verbose ("Frame for %s is 0x%lx", frame->window->desc, frame->xwindow);
|
2003-08-16 12:32:10 -04:00
|
|
|
attrs.event_mask = EVENT_MASK;
|
2017-08-26 12:26:30 -04:00
|
|
|
XChangeWindowAttributes (x11_display->xdisplay,
|
2003-08-16 12:32:10 -04:00
|
|
|
frame->xwindow, CWEventMask, &attrs);
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2017-08-26 12:56:44 -04:00
|
|
|
meta_x11_display_register_x_window (x11_display, &frame->xwindow, window);
|
2001-05-31 02:42:58 -04:00
|
|
|
|
2017-08-27 14:48:55 -04:00
|
|
|
meta_x11_error_trap_push (x11_display);
|
2002-01-10 22:31:14 -05:00
|
|
|
if (window->mapped)
|
|
|
|
|
{
|
|
|
|
|
window->mapped = FALSE; /* the reparent will unmap the window,
|
|
|
|
|
* we don't want to take that as a withdraw
|
|
|
|
|
*/
|
2002-02-07 22:34:26 -05:00
|
|
|
meta_topic (META_DEBUG_WINDOW_STATE,
|
2020-10-02 11:47:22 -04:00
|
|
|
"Incrementing unmaps_pending on %s for reparent", window->desc);
|
2002-01-10 22:31:14 -05:00
|
|
|
window->unmaps_pending += 1;
|
|
|
|
|
}
|
2001-09-08 23:44:42 -04:00
|
|
|
|
2017-08-26 13:03:51 -04:00
|
|
|
meta_stack_tracker_record_remove (window->display->stack_tracker,
|
2014-09-08 21:20:14 -04:00
|
|
|
window->xwindow,
|
2017-08-26 12:26:30 -04:00
|
|
|
XNextRequest (x11_display->xdisplay));
|
|
|
|
|
XReparentWindow (x11_display->xdisplay,
|
2001-05-31 02:42:58 -04:00
|
|
|
window->xwindow,
|
|
|
|
|
frame->xwindow,
|
2014-05-28 10:49:42 -04:00
|
|
|
frame->child_x,
|
|
|
|
|
frame->child_y);
|
2019-06-24 09:10:22 -04:00
|
|
|
window->reparents_pending += 1;
|
2001-10-13 00:00:08 -04:00
|
|
|
/* FIXME handle this error */
|
2017-08-27 14:48:55 -04:00
|
|
|
meta_x11_error_trap_pop (x11_display);
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2018-08-21 18:58:06 -04: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 02:42:58 -04:00
|
|
|
/* stick frame to the window */
|
2001-06-04 02:17:52 -04:00
|
|
|
window->frame = frame;
|
2011-03-20 17:15:47 -04: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 04:35:47 -04:00
|
|
|
XMapWindow (x11_display->xdisplay, frame->xwindow);
|
2014-05-21 10:07:36 -04:00
|
|
|
|
2001-06-23 01:49:35 -04: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 04:35:47 -04: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 02:42:58 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
meta_window_destroy_frame (MetaWindow *window)
|
|
|
|
|
{
|
|
|
|
|
MetaFrame *frame;
|
2011-10-17 17:18:50 -04:00
|
|
|
MetaFrameBorders borders;
|
2017-08-26 12:26:30 -04:00
|
|
|
MetaX11Display *x11_display;
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2001-05-31 02:42:58 -04:00
|
|
|
if (window->frame == NULL)
|
|
|
|
|
return;
|
|
|
|
|
|
2017-08-26 12:26:30 -04:00
|
|
|
x11_display = window->display->x11_display;
|
|
|
|
|
|
2020-10-02 11:47:22 -04:00
|
|
|
meta_verbose ("Unframing window %s", window->desc);
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2001-05-31 02:42:58 -04:00
|
|
|
frame = window->frame;
|
2011-10-17 17:18:50 -04:00
|
|
|
|
|
|
|
|
meta_frame_calc_borders (frame, &borders);
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2001-05-31 02:42:58 -04:00
|
|
|
/* Unparent the client window; it may be destroyed,
|
|
|
|
|
* thus the error trap.
|
|
|
|
|
*/
|
2017-08-27 14:48:55 -04:00
|
|
|
meta_x11_error_trap_push (x11_display);
|
2002-01-10 22:31:14 -05:00
|
|
|
if (window->mapped)
|
|
|
|
|
{
|
|
|
|
|
window->mapped = FALSE; /* Keep track of unmapping it, so we
|
|
|
|
|
* can identify a withdraw initiated
|
|
|
|
|
* by the client.
|
|
|
|
|
*/
|
2002-02-07 22:34:26 -05:00
|
|
|
meta_topic (META_DEBUG_WINDOW_STATE,
|
2020-10-02 11:47:22 -04:00
|
|
|
"Incrementing unmaps_pending on %s for reparent back to root", window->desc);
|
2002-01-10 22:31:14 -05:00
|
|
|
window->unmaps_pending += 1;
|
|
|
|
|
}
|
2019-06-14 11:26:23 -04:00
|
|
|
|
|
|
|
|
if (!x11_display->closing)
|
|
|
|
|
{
|
2022-11-21 06:59:42 -05:00
|
|
|
if (!window->unmanaging)
|
|
|
|
|
{
|
|
|
|
|
meta_stack_tracker_record_add (window->display->stack_tracker,
|
|
|
|
|
window->xwindow,
|
|
|
|
|
XNextRequest (x11_display->xdisplay));
|
|
|
|
|
}
|
2019-06-14 11:26:23 -04:00
|
|
|
|
|
|
|
|
XReparentWindow (x11_display->xdisplay,
|
|
|
|
|
window->xwindow,
|
|
|
|
|
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);
|
2019-06-24 09:10:22 -04:00
|
|
|
window->reparents_pending += 1;
|
2019-06-14 11:26:23 -04:00
|
|
|
}
|
|
|
|
|
|
2017-08-27 14:48:55 -04:00
|
|
|
meta_x11_error_trap_pop (x11_display);
|
2001-05-31 02:42:58 -04:00
|
|
|
|
2018-08-21 18:58:06 -04: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;
|
|
|
|
|
|
2017-08-26 12:56:44 -04:00
|
|
|
meta_x11_display_unregister_x_window (x11_display, frame->xwindow);
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2001-05-31 02:42:58 -04:00
|
|
|
window->frame = NULL;
|
2011-10-03 08:59:16 -04:00
|
|
|
if (window->frame_bounds)
|
|
|
|
|
{
|
|
|
|
|
cairo_region_destroy (window->frame_bounds);
|
|
|
|
|
window->frame_bounds = NULL;
|
|
|
|
|
}
|
2001-05-31 02:42:58 -04:00
|
|
|
|
2001-06-23 01:49:35 -04:00
|
|
|
/* Move keybindings to window instead of frame */
|
|
|
|
|
meta_window_grab_keys (window);
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2001-05-31 02:42:58 -04:00
|
|
|
g_free (frame);
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2001-06-04 02:17:52 -04:00
|
|
|
/* Put our state back where it should be */
|
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-10 21:15:33 -04:00
|
|
|
meta_window_queue (window, META_QUEUE_CALC_SHOWING);
|
2009-02-04 20:06:15 -05:00
|
|
|
meta_window_queue (window, META_QUEUE_MOVE_RESIZE);
|
2001-05-31 02:42:58 -04:00
|
|
|
}
|
|
|
|
|
|
2001-06-17 23:24:25 -04:00
|
|
|
|
|
|
|
|
MetaFrameFlags
|
|
|
|
|
meta_frame_get_flags (MetaFrame *frame)
|
|
|
|
|
{
|
|
|
|
|
MetaFrameFlags flags;
|
|
|
|
|
|
2002-06-21 23:23:02 -04:00
|
|
|
flags = 0;
|
2001-06-23 14:30:27 -04:00
|
|
|
|
2002-06-21 23:23:02 -04:00
|
|
|
if (frame->window->border_only)
|
|
|
|
|
{
|
|
|
|
|
; /* FIXME this may disable the _function_ as well as decor
|
|
|
|
|
* in some cases, which is sort of wrong.
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
flags |= META_FRAME_ALLOWS_MENU;
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2002-06-21 23:23:02 -04:00
|
|
|
if (frame->window->has_close_func)
|
|
|
|
|
flags |= META_FRAME_ALLOWS_DELETE;
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2002-06-21 23:23:02 -04:00
|
|
|
if (frame->window->has_maximize_func)
|
|
|
|
|
flags |= META_FRAME_ALLOWS_MAXIMIZE;
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2002-06-21 23:23:02 -04:00
|
|
|
if (frame->window->has_minimize_func)
|
|
|
|
|
flags |= META_FRAME_ALLOWS_MINIMIZE;
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2002-06-21 23:23:02 -04:00
|
|
|
if (frame->window->has_shade_func)
|
|
|
|
|
flags |= META_FRAME_ALLOWS_SHADE;
|
2014-05-02 09:34:02 -04:00
|
|
|
}
|
|
|
|
|
|
2002-07-02 22:32:40 -04:00
|
|
|
if (META_WINDOW_ALLOWS_MOVE (frame->window))
|
2001-06-23 14:30:27 -04:00
|
|
|
flags |= META_FRAME_ALLOWS_MOVE;
|
2001-07-02 21:45:43 -04:00
|
|
|
|
2002-07-02 22:32:40 -04:00
|
|
|
if (META_WINDOW_ALLOWS_HORIZONTAL_RESIZE (frame->window))
|
|
|
|
|
flags |= META_FRAME_ALLOWS_HORIZONTAL_RESIZE;
|
|
|
|
|
|
|
|
|
|
if (META_WINDOW_ALLOWS_VERTICAL_RESIZE (frame->window))
|
|
|
|
|
flags |= META_FRAME_ALLOWS_VERTICAL_RESIZE;
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2010-09-10 05:55:20 -04:00
|
|
|
if (meta_window_appears_focused (frame->window))
|
2001-06-17 23:24:25 -04:00
|
|
|
flags |= META_FRAME_HAS_FOCUS;
|
|
|
|
|
|
|
|
|
|
if (frame->window->shaded)
|
|
|
|
|
flags |= META_FRAME_SHADED;
|
|
|
|
|
|
2011-02-28 05:41:23 -05:00
|
|
|
if (frame->window->on_all_workspaces_requested)
|
2001-06-17 23:24:25 -04:00
|
|
|
flags |= META_FRAME_STUCK;
|
2001-06-18 02:11:53 -04:00
|
|
|
|
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 09:58:50 -05:00
|
|
|
/* FIXME: Should we have some kind of UI for windows that are just vertically
|
|
|
|
|
* maximized or just horizontally maximized?
|
|
|
|
|
*/
|
|
|
|
|
if (META_WINDOW_MAXIMIZED (frame->window))
|
2002-06-08 02:07:21 -04:00
|
|
|
flags |= META_FRAME_MAXIMIZED;
|
|
|
|
|
|
2016-01-10 09:16:09 -05:00
|
|
|
if (META_WINDOW_TILED_LEFT (frame->window))
|
|
|
|
|
flags |= META_FRAME_TILED_LEFT;
|
|
|
|
|
|
|
|
|
|
if (META_WINDOW_TILED_RIGHT (frame->window))
|
|
|
|
|
flags |= META_FRAME_TILED_RIGHT;
|
|
|
|
|
|
2002-06-08 02:07:21 -04:00
|
|
|
if (frame->window->fullscreen)
|
|
|
|
|
flags |= META_FRAME_FULLSCREEN;
|
2001-06-23 02:54:28 -04:00
|
|
|
|
Added "above" to the list of flags a frame can have, so that we know when
* common.h: Added "above" to the list of flags a frame can have, so
that we know when to mark it as always on top. Added six grab ops,
one to do and one to undo each of the three new titlebar buttons
(shade, above, stick). Added six new button functions, similarly.
(#96229)
* frame.c (meta_frame_get_flags): If a frame has the WM_STATE_ABOVE X
attribute, set META_FRAME_ABOVE in its flags.
* frames.c (meta_frames_apply_shapes): Allow variable amounts of
rounding. (#113162)
* frames.c (show_tip_now, meta_frames_paint_to_drawable, control_rect,
get_control): extend handling of existing buttons to the
3*2 new kinds of button. (#96229)
* frames.c (meta_frames_button_press_event): translate clicks on the 3*2
new kinds of button to the new grab ops. (#96229)
* frames.c (meta_frames_button_release_event): implement the various
actions for the 3*2 new kinds of button. (#96229)
* frames.c (meta_frames_update_prelit_control,
meta_frames_motion_notify_event): extend existing motion
notifications for buttons to the 3*2 new kinds of button. (#96229)
* frames.c (meta_frames_set_window_background): handle specified
background colours and alpha transparency. (#151261)
* frames.h (MetaFrameControl): New control types for the 3*2 new kinds
of button. (#96229)
* iconcache.[ch] (meta_read_icons): use theme's fallback icons if a
window has no icon; use metacity's fallback icons only if the theme
does not provide any. (#11363)
* iconcache.[ch] (meta_invalidate_default_icons (new function)): clear
icon cache on windows using default icons, and update them. (#11363)
* main.c (main): added \n to error message.
* prefs.c (button_function_from_string): extend for 3 new button
types. (#96229)
* prefs.c (button_opposite_function (new function)): return a button
function's inverse (shade -> unshade, etc) (#96229)
* prefs.c (update_button_layout): allocate space for a button's
inverse, if it has one. (#96229)
* theme-parser.c (ParseState): add state for fallback icons (#11363)
* theme-parser.c (ParseInfo): add format_version; remove
menu_icon_* (#114305)
* theme-parser.c (parse_positive_integer): add lookup for integer
constants (#331356)
* theme-parser.c (parse_rounding (new function)): parse window
rounding amount (#113162)
* theme-parser.c (parse_alpha): don't set error if the number can't
be parsed since it'll already be set; change tolerance in comparison
from 1e6 to 1e-6
* theme-parser.c (parse_color (new function)): parse colour, including
possible constant lookup.
* theme-parser.c (parse_toplevel_element): allow defining of various
new kinds of constant; allow
hide_buttons (#121639) and more detailed rounding attributes on
<frame_geometry> (#113162); allow background and alpha attributes on
<frame_style>; (#151261) remove support for <menu_icon> except as
stub; (#114305) add support for loading stock images (#113465); add
support for <fallback>. (#11363))
* theme-parser.c (parse_draw_op_element): add from and to attribute
for arcs. (#121603)
* theme-parser.c (parse_style_element): add check for theme version
supporting a button function. (#96229)
* theme-parser.c (parse_style_set_element): add ability for shaded
windows to be resizable (#114304)
* theme-parser.c (meta_theme_load): add theme versioning routine.
* theme.c ( meta_frame_layout_get_borders): return rectangles for
the new 3*2 kinds of button, except where they're
inapplicable. (#96229)
* theme.c (meta_frame_layout_calc_geometry): don't format buttons on
windows with no buttons (#121639); strip the 3*2 new kinds of button
correctly (#96229); allow variable amounts of rounding (#113162).
* theme.c (meta_frame_style_new): set alpha to 255 by
default. (#151261)
* theme.c (meta_frame_style_unref): free colour spec if
allocated. (#151261)
* theme.c (meta_frame_style_validate): it's only an error not to
include a button if that button is valid in the current
theme. (#96229)
* theme.c (button_rect): return rectangles for the new 3*2 kinds
of button. (#96229)
* theme.c (meta_frame_style_set_unref): free differently resizable
shaded styles. (#114304)
* theme.c (get_style): look up differently resizable styles
for shaded windows. (#114304)
* theme.c (free_menu_ops (removed function), get_menu_icon
(removed function), meta_theme_draw_menu_icon (removed function),
meta_menu_icon_type_from_string (removed function),
meta_menu_icon_type_to_string (removed function),
meta_theme_free, meta_theme_validate): removed menu icon code. (#114305)
* theme.c (meta_theme_load_image): add size_of_theme_icons
parameter. (#113465)
* theme.c (meta_theme_define_color_constant (new function),
meta_theme_lookup_color_constant (new function)): allow
definition of colour constants. (#129747)
* theme.c (meta_button_type_from_string, meta_button_type_to_string):
add the 3*2 new kinds of button. (#96229)
* theme.c (meta_theme_earliest_version_with_button (new function)):
return the theme version each button was introduced in. (#96229)
* theme.h ( MetaFrameLayout): add "hide_buttons" flag (#121639) and
corner radiuses. (#113162)
* theme.h (MetaFrameGeometry): add rectangles for the 3*2 new
buttons. (#96229)
* theme.h (MetaButtonType): the 3*2 new buttons. (#96229)
* theme.h (MetaFrameStyle): add window_background_color and
window_background_alpha so that we can specify background on a
<frame_style>. (#151261)
* theme.h (MetaFrameStyleSet): shaded_styles gets resize
dimension. (#114304)
* theme.h (MetaTheme): added format_version, color_constants
hash, (#129747) fallback_icon and fallback_mini_icon, (#11363)
and removed menu_icons. (#114305)
* theme.h (META_THEME_ALLOWS (new macro)): return whether a theme
supports a given feature. Also, several macros representing
new features in v2.
* ui.c (meta_ui_set_current_theme)): also invalidate default
icons. (#11363)
* window.[ch] (meta_window_update_icon_now)): became
non-static. (#11363)
2006-10-07 12:56:47 -04:00
|
|
|
if (frame->window->wm_state_above)
|
|
|
|
|
flags |= META_FRAME_ABOVE;
|
2014-05-02 09:34:02 -04:00
|
|
|
|
2001-06-18 02:11:53 -04:00
|
|
|
return flags;
|
2001-06-17 23:24:25 -04:00
|
|
|
}
|
|
|
|
|
|
2011-07-12 00:59:12 -04:00
|
|
|
void
|
|
|
|
|
meta_frame_borders_clear (MetaFrameBorders *self)
|
|
|
|
|
{
|
2011-07-12 00:55:50 -04:00
|
|
|
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;
|
2011-07-12 00:59:12 -04: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 04:35:47 -04: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 = (GtkBorder) {
|
|
|
|
|
((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 = (GtkBorder) {
|
|
|
|
|
((long *) data)[0],
|
|
|
|
|
((long *) data)[1],
|
|
|
|
|
((long *) data)[2],
|
|
|
|
|
((long *) data)[3],
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
g_clear_pointer (&data, XFree);
|
|
|
|
|
|
|
|
|
|
borders->total = (GtkBorder) {
|
|
|
|
|
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-17 23:24:25 -04:00
|
|
|
void
|
2011-07-12 00:37:41 -04:00
|
|
|
meta_frame_calc_borders (MetaFrame *frame,
|
|
|
|
|
MetaFrameBorders *borders)
|
2001-06-17 23:24:25 -04:00
|
|
|
{
|
2012-03-12 23:11:07 -04: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
|
2013-11-15 17:37:50 -05:00
|
|
|
{
|
|
|
|
|
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 04:35:47 -04:00
|
|
|
meta_frame_query_borders (frame, &frame->cached_borders);
|
2013-11-15 17:37:50 -05:00
|
|
|
frame->borders_cached = TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*borders = frame->cached_borders;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
meta_frame_clear_cached_borders (MetaFrame *frame)
|
|
|
|
|
{
|
|
|
|
|
frame->borders_cached = FALSE;
|
2001-06-17 23:24:25 -04:00
|
|
|
}
|
|
|
|
|
|
2011-03-22 15:36:12 -04:00
|
|
|
gboolean
|
2001-06-09 23:17:15 -04:00
|
|
|
meta_frame_sync_to_window (MetaFrame *frame,
|
|
|
|
|
gboolean need_resize)
|
2001-06-02 21:33:27 -04: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 04:35:47 -04:00
|
|
|
MetaWindow *window = frame->window;
|
|
|
|
|
MetaX11Display *x11_display = window->display->x11_display;
|
|
|
|
|
|
2002-02-24 14:58:27 -05:00
|
|
|
meta_topic (META_DEBUG_GEOMETRY,
|
2020-10-02 11:47:22 -04:00
|
|
|
"Syncing frame geometry %d,%d %dx%d (SE: %d,%d)",
|
2002-02-24 14:58:27 -05:00
|
|
|
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-09 23:17:15 -04: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 04:35:47 -04: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 17:39:57 -04:00
|
|
|
|
2011-03-22 15:36:12 -04:00
|
|
|
return need_resize;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cairo_region_t *
|
|
|
|
|
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 04:35:47 -04:00
|
|
|
MetaFrameBorders borders;
|
|
|
|
|
cairo_region_t *bounds;
|
|
|
|
|
|
|
|
|
|
meta_frame_calc_borders (frame, &borders);
|
|
|
|
|
/* FIXME: currently just the client area, should shape closer to
|
|
|
|
|
* frame border, incl. rounded corners.
|
|
|
|
|
*/
|
|
|
|
|
bounds = cairo_region_create_rectangle (&(cairo_rectangle_int_t) {
|
|
|
|
|
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 17:39:57 -04:00
|
|
|
}
|
|
|
|
|
|
2013-04-12 13:00:15 -04:00
|
|
|
void
|
2020-01-16 05:42:04 -05:00
|
|
|
meta_frame_get_mask (MetaFrame *frame,
|
|
|
|
|
cairo_rectangle_int_t *frame_rect,
|
|
|
|
|
cairo_t *cr)
|
2013-04-12 13:00:15 -04: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 04:35:47 -04:00
|
|
|
MetaFrameBorders borders;
|
2017-08-26 12:26:30 -04: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 04:35:47 -04:00
|
|
|
meta_frame_calc_borders (frame, &borders);
|
2017-08-26 12:26:30 -04: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 04:35:47 -04:00
|
|
|
cairo_rectangle (cr,
|
|
|
|
|
borders.invisible.left,
|
|
|
|
|
borders.invisible.top,
|
|
|
|
|
frame_rect->width,
|
|
|
|
|
frame_rect->height);
|
|
|
|
|
cairo_set_source_rgb (cr, 0, 0, 0);
|
|
|
|
|
cairo_fill (cr);
|
2002-08-23 14:00:40 -04:00
|
|
|
}
|
|
|
|
|
|
2008-05-18 20:00:09 -04:00
|
|
|
Window
|
|
|
|
|
meta_frame_get_xwindow (MetaFrame *frame)
|
|
|
|
|
{
|
|
|
|
|
return frame->xwindow;
|
|
|
|
|
}
|
2015-01-01 00:24:49 -05: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 04:35:47 -04:00
|
|
|
gboolean
|
|
|
|
|
meta_frame_handle_xevent (MetaFrame *frame,
|
|
|
|
|
XEvent *xevent)
|
2015-01-01 00:24:49 -05: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 04:35:47 -04: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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return FALSE;
|
2015-01-01 00:24:49 -05: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 04:35:47 -04:00
|
|
|
GSubprocess *
|
|
|
|
|
meta_frame_launch_client (MetaX11Display *x11_display,
|
|
|
|
|
const char *display_name)
|
2015-01-01 00:24:49 -05: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 04:35:47 -04: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;
|
2015-01-01 00:24:49 -05:00
|
|
|
}
|
2022-06-08 10:10:59 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 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>";
|
|
|
|
|
}
|