sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/core/frame.c

603 lines
17 KiB
C
Raw Normal View History

Stick an emacs comment directive at the beginning of all the code files so 2006-10-01 Elijah Newren <newren gmail com> * src/*.[ch]: Stick an emacs comment directive at the beginning of all the code files so that people using emacs will be more likely to get coding style correct in their patches. We still need a similar vi directive. #358866
2006-10-01 22:30:10 +00: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 10:29:20 +00:00
/* Mutter X window decorations */
...
2001-05-31 06:42:58 +00:00
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
/*
...
2001-05-31 06:42:58 +00:00
* Copyright (C) 2001 Havoc Pennington
move the have_xrender variable initialization up in the file since it can 2004-08-26 Havoc Pennington <hp@redhat.com> * configure.in: move the have_xrender variable initialization up in the file since it can be set as part of composite check 2004-08-19 Havoc Pennington <hp@redhat.com> Fixes from Rich Wareham * src/display.h (struct _MetaDisplay): add render extension check to the display * src/display.c: check for render * configure.in: don't build compositing manager by default, don't want any nasty surprises; check for render separately from compositing manager * src/frame.c: use an ARGB visual when available for the window frame, so we can be all cool-ass
2004-08-27 02:17:49 +00: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 14:58:50 +00:00
* Copyright (C) 2005 Elijah Newren
Remove trailing whitespace
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.
Remove trailing whitespace
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
Changed obsolete FSF postal address into generic URL. Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-12 01:42:06 +00:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
...
2001-05-31 06:42:58 +00:00
*/
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "config.h"
#include "core/frame.h"
frame: Only XSync when we're on the X11 compositor backend The only case we have is the case where the two X11 connections are the same. When on Wayland, the XSync is costly and expensive, and we should minimize it.
2014-07-10 17:29:20 +00:00
#include "backends/x11/meta-backend-x11.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "core/bell.h"
#include "core/keybindings-private.h"
#include "meta/meta-x11-errors.h"
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
#include "x11/meta-x11-display-private.h"
x11: Add frame synchronization to window frames There's two meanings of "frame" there! Since SSD frames are now rendered by an external client, and there are no actual mechanism that ensures the frame did already get painted when the client did respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be artifacts when resizing windows. In order to get always the best visual result, we should actually synchronize rendering with both the client window and the window frame window. This commit adds these mechanisms, so a sync alarm update is expected on both windows until further resizes are allowed, this ensures window and frame stay in sync, even after moving rendering elsewhere. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-09 13:54:28 +00:00
#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>
...
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,
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-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;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
...
2001-06-03 01:33:27 +00:00
if (window->frame)
return;
Remove trailing whitespace
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;
x11: Add frame synchronization to window frames There's two meanings of "frame" there! Since SSD frames are now rendered by an external client, and there are no actual mechanism that ensures the frame did already get painted when the client did respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be artifacts when resizing windows. In order to get always the best visual result, we should actually synchronize rendering with both the client window and the window frame window. This commit adds these mechanisms, so a sync alarm update is expected on both windows until further resizes are allowed, this ensures window and frame stay in sync, even after moving rendering elsewhere. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-09 13:54:28 +00:00
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;
MetaFrame: Cache borders Cache the computed border size so we can fetch the border size at any time without worrying that we'll be spending too much time in the theme code (in some cases we might allocate a PangoFontDescription or do other significant work.) The main effort here is clearing the cache when various bits of window state change that could potentially affect the computed borders. https://bugzilla.gnome.org/show_bug.cgi?id=707194
2013-11-15 22:37:50 +00:00
frame->borders_cached = FALSE;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
x11: Add frame synchronization to window frames There's two meanings of "frame" there! Since SSD frames are now rendered by an external client, and there are no actual mechanism that ensures the frame did already get painted when the client did respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be artifacts when resizing windows. In order to get always the best visual result, we should actually synchronize rendering with both the client window and the window frame window. This commit adds these mechanisms, so a sync alarm update is expected on both windows until further resizes are allowed, this ensures window and frame stay in sync, even after moving rendering elsewhere. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-09 13:54:28 +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;
Make meta_* logging utilities not require line break Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-02 15:47:22 +00:00
meta_verbose ("Frame geometry %d,%d %dx%d",
call setlocale ourselves because due to a GLib bug that sticks us in ASCII 2002-04-22 Havoc Pennington <hp@redhat.com> * src/main.c (main): call setlocale ourselves because due to a GLib bug that sticks us in ASCII if you call g_print or anything prior to setlocale, and print a warning if we don't set the locale successfully. #79280 * src/workspace.c (meta_workspace_get_work_area): be more verbose about how the work area was computed, to help find bugs here. * src/main.c (main): put locale and codeset in the log file
2002-04-22 18:18:38 +00:00
frame->rect.x, frame->rect.y,
frame->rect.width, frame->rect.height);
Remove trailing whitespace
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);
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
meta_stack_tracker_record_add (window->display->stack_tracker,
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
frame->xwindow,
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
create_serial);
Patch from Soeren Sandmann #108926 to improve opaque resize 2003-08-16 Havoc Pennington <hp@pobox.com> Patch from Soeren Sandmann #108926 to improve opaque resize * src/frame.c (meta_window_ensure_frame): new function * src/ui.c (meta_ui_create_frame_window): new function to create a frame with GDK, so that GDK's invalidation etc. work properly
2003-08-16 16:32:10 +00:00
Make meta_* logging utilities not require line break Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-02 15:47:22 +00:00
meta_verbose ("Frame for %s is 0x%lx", frame->window->desc, frame->xwindow);
core: Wrap an extra X11 call with error trap This XChangeWindowAttributes call was never surrounded by an error trap and was not really expected to fail with BadWindow since the frame window would be owned by Mutter itself. This however is no longer true, and we might be getting a BadWindow from the frame window given the right timing. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2745>
2022-12-06 18:03:24 +00:00
meta_x11_error_trap_push (x11_display);
Patch from Soeren Sandmann #108926 to improve opaque resize 2003-08-16 Havoc Pennington <hp@pobox.com> Patch from Soeren Sandmann #108926 to improve opaque resize * src/frame.c (meta_window_ensure_frame): new function * src/ui.c (meta_ui_create_frame_window): new function to create a frame with GDK, so that GDK's invalidation etc. work properly
2003-08-16 16:32:10 +00:00
attrs.event_mask = EVENT_MASK;
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
XChangeWindowAttributes (x11_display->xdisplay,
Patch from Soeren Sandmann #108926 to improve opaque resize 2003-08-16 Havoc Pennington <hp@pobox.com> Patch from Soeren Sandmann #108926 to improve opaque resize * src/frame.c (meta_window_ensure_frame): new function * src/ui.c (meta_ui_create_frame_window): new function to create a frame with GDK, so that GDK's invalidation etc. work properly
2003-08-16 16:32:10 +00:00
frame->xwindow, CWEventMask, &attrs);
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
Move alarm and xids management to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:56:44 +00:00
meta_x11_display_register_x_window (x11_display, &frame->xwindow, window);
...
2001-05-31 06:42:58 +00:00
only bump unmaps_pending if the window was mapped 2002-01-10 Havoc Pennington <hp@pobox.com> * src/frame.c (meta_window_destroy_frame): only bump unmaps_pending if the window was mapped (meta_window_ensure_frame): ditto * src/keybindings.c: change arrow key bindings to use Ctrl+Alt not just Alt, and add debug mode key bindings * src/stack.c (meta_stack_get_default_focus_window): don't choose a default focus window with unmaps pending, since we probably just unmapped it. * src/display.c (event_callback): move notify_focus on UnmapNotify after the window_free check, so we can move focus to another window when we unmanage * src/window.c (meta_window_hide): invalidate work areas when hiding a window with struts (meta_window_free): invalidate work areas when unmanaging a window with struts
2002-01-11 03:31:14 +00:00
if (window->mapped)
{
window->mapped = FALSE; /* the reparent will unmap the window,
* we don't want to take that as a withdraw
*/
Throughout: move to meta_topic rather than meta_verbose so metacity.log 2002-02-07 Havoc Pennington <hp@pobox.com> Throughout: move to meta_topic rather than meta_verbose so metacity.log can start being more useful * src/util.h (enum): add more debug topics * src/frames.c: clean up some cruft that caused warnings
2002-02-08 03:34:26 +00:00
meta_topic (META_DEBUG_WINDOW_STATE,
Make meta_* logging utilities not require line break Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-02 15:47:22 +00:00
"Incrementing unmaps_pending on %s for reparent", window->desc);
only bump unmaps_pending if the window was mapped 2002-01-10 Havoc Pennington <hp@pobox.com> * src/frame.c (meta_window_destroy_frame): only bump unmaps_pending if the window was mapped (meta_window_ensure_frame): ditto * src/keybindings.c: change arrow key bindings to use Ctrl+Alt not just Alt, and add debug mode key bindings * src/stack.c (meta_stack_get_default_focus_window): don't choose a default focus window with unmaps pending, since we probably just unmapped it. * src/display.c (event_callback): move notify_focus on UnmapNotify after the window_free check, so we can move focus to another window when we unmanage * src/window.c (meta_window_hide): invalidate work areas when hiding a window with struts (meta_window_free): invalidate work areas when unmanaging a window with struts
2002-01-11 03:31:14 +00:00
window->unmaps_pending += 1;
}
don't use gdk_display_name 2001-09-08 Havoc Pennington <hp@pobox.com> * src/ui.c (meta_ui_init): don't use gdk_display_name * src/frame.c (meta_window_ensure_frame): create frame with screen default visual, rather than client window visual; for DRI games, the client window visual was not allowed to be a child of another window with the same visual, apparently. Anyhow now we copy twm, etc. so it must be correct. * src/place.c (meta_window_place): if a transient is placed and its parent has focus, focus the transient.
2001-09-09 03:44:42 +00:00
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
meta_stack_tracker_record_remove (window->display->stack_tracker,
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
window->xwindow,
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
XNextRequest (x11_display->xdisplay));
XReparentWindow (x11_display->xdisplay,
...
2001-05-31 06:42:58 +00:00
window->xwindow,
frame->xwindow,
frame: Don't reset window->rect
2014-05-28 14:49:42 +00:00
frame->child_x,
frame->child_y);
core: Fix multiple reparent requests handling If window decoration is modified within a short period of time, mutter sometimes starts processing the second request before the first UnmapNotify event has been received. In this situation, it considers that the window is not mapped and does not expect another UnmapNotify / MapNotify event sequence to happen. This adds a separate counter to keep track of the pending reparents. The input focus is then restored when MapNotify event is received iff all the expected pending ReparentNotify events have been received. Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> https://gitlab.gnome.org/GNOME/mutter/merge_requests/657
2019-06-24 13:10:22 +00:00
window->reparents_pending += 1;
makefile tweak, add a comment to frame.c
2001-10-13 04:00:08 +00:00
/* FIXME handle this error */
Rename errors.[ch] to meta-x11-errors.[ch] Also rename meta_error_trap_* to meta_x11_error_trap_* and move meta-x11-errors.c to src/x11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-27 18:48:55 +00:00
meta_x11_error_trap_pop (x11_display);
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
core: Preserve focus across decoration changes Changes in window decoration result in the window being reparented in and out its frame. This in turn causes unmap/map events, and XI_FocusOut if the window happened to be focused. In order to preserve the focused window across the decoration change, add a flag so that the focus may be restored on MapNotify. Closes: #273
2018-08-21 22:58:06 +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;
frame: Delay updating the background until the frame is ready To determine the correct background style, the UI needs to access some frame properties via meta_core_get(); this call will bail out early if window->frame is unset, so delay the call until the association is made. https://bugzilla.gnome.org/show_bug.cgi?id=645355
2011-03-20 21:15:47 +00:00
x11: Add frame synchronization to window frames There's two meanings of "frame" there! Since SSD frames are now rendered by an external client, and there are no actual mechanism that ensures the frame did already get painted when the client did respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be artifacts when resizing windows. In order to get always the best visual result, we should actually synchronize rendering with both the client window and the window frame window. This commit adds these mechanisms, so a sync alarm update is expected on both windows until further resizes are allowed, this ensures window and frame stay in sync, even after moving rendering elsewhere. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-09 13:54:28 +00:00
meta_window_reload_property_from_xwindow (window, frame->xwindow,
x11_display->atom__NET_WM_SYNC_REQUEST_COUNTER,
TRUE);
core: Wrap XMapWindow() request with error traps Other X11 calls happening during the process of assigning a frame to a window are already wrapped with error traps, wrap this as well to avoid possible X11 errors. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2745>
2023-01-12 13:07:32 +00:00
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);
core: Wrap XMapWindow() request with error traps Other X11 calls happening during the process of assigning a frame to a window are already wrapped with error traps, wrap this as well to avoid possible X11 errors. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2745>
2023-01-12 13:07:32 +00:00
meta_x11_error_trap_pop (x11_display);
frame: Make sure to XSync before grabbing keybindings Otherwise, the X server might read the backend's connection before GTK+'s, meaning that it sees the XIGrabKeycode requests before the CreateWindow. This fixes keybindings on windows not working immediately. Thanks to Rui Matos <tiagomatos@gmail.com> and Julien Cristau <jcristau@debian.org> for helping track down the issue.
2014-05-21 14:07:36 +00:00
...
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;
frame: Make sure to offset by invisible borders when unmanaging windows When we reparent a window to the root when we're exiting, we need to offset the position by the invisible borders, otherwise windows will creep up and to the left. https://bugzilla.gnome.org/show_bug.cgi?id=660848
2011-10-17 21:18:50 +00:00
MetaFrameBorders borders;
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
MetaX11Display *x11_display;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
...
2001-05-31 06:42:58 +00:00
if (window->frame == NULL)
return;
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
x11_display = window->display->x11_display;
Make meta_* logging utilities not require line break Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-02 15:47:22 +00:00
meta_verbose ("Unframing window %s", window->desc);
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
...
2001-05-31 06:42:58 +00:00
frame = window->frame;
frame: Make sure to offset by invisible borders when unmanaging windows When we reparent a window to the root when we're exiting, we need to offset the position by the invisible borders, otherwise windows will creep up and to the left. https://bugzilla.gnome.org/show_bug.cgi?id=660848
2011-10-17 21:18:50 +00:00
meta_frame_calc_borders (frame, &borders);
Remove trailing whitespace
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.
*/
Rename errors.[ch] to meta-x11-errors.[ch] Also rename meta_error_trap_* to meta_x11_error_trap_* and move meta-x11-errors.c to src/x11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-27 18:48:55 +00:00
meta_x11_error_trap_push (x11_display);
only bump unmaps_pending if the window was mapped 2002-01-10 Havoc Pennington <hp@pobox.com> * src/frame.c (meta_window_destroy_frame): only bump unmaps_pending if the window was mapped (meta_window_ensure_frame): ditto * src/keybindings.c: change arrow key bindings to use Ctrl+Alt not just Alt, and add debug mode key bindings * src/stack.c (meta_stack_get_default_focus_window): don't choose a default focus window with unmaps pending, since we probably just unmapped it. * src/display.c (event_callback): move notify_focus on UnmapNotify after the window_free check, so we can move focus to another window when we unmanage * src/window.c (meta_window_hide): invalidate work areas when hiding a window with struts (meta_window_free): invalidate work areas when unmanaging a window with struts
2002-01-11 03:31:14 +00:00
if (window->mapped)
{
window->mapped = FALSE; /* Keep track of unmapping it, so we
* can identify a withdraw initiated
* by the client.
*/
Throughout: move to meta_topic rather than meta_verbose so metacity.log 2002-02-07 Havoc Pennington <hp@pobox.com> Throughout: move to meta_topic rather than meta_verbose so metacity.log can start being more useful * src/util.h (enum): add more debug topics * src/frames.c: clean up some cruft that caused warnings
2002-02-08 03:34:26 +00:00
meta_topic (META_DEBUG_WINDOW_STATE,
Make meta_* logging utilities not require line break Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-02 15:47:22 +00:00
"Incrementing unmaps_pending on %s for reparent back to root", window->desc);
only bump unmaps_pending if the window was mapped 2002-01-10 Havoc Pennington <hp@pobox.com> * src/frame.c (meta_window_destroy_frame): only bump unmaps_pending if the window was mapped (meta_window_ensure_frame): ditto * src/keybindings.c: change arrow key bindings to use Ctrl+Alt not just Alt, and add debug mode key bindings * src/stack.c (meta_stack_get_default_focus_window): don't choose a default focus window with unmaps pending, since we probably just unmapped it. * src/display.c (event_callback): move notify_focus on UnmapNotify after the window_free check, so we can move focus to another window when we unmanage * src/window.c (meta_window_hide): invalidate work areas when hiding a window with struts (meta_window_free): invalidate work areas when unmanaging a window with struts
2002-01-11 03:31:14 +00:00
window->unmaps_pending += 1;
}
core: Avoid queueing a stack operation on the frame when the X11 is closing When rushing to unmanage X11 windows after the X11 connection is closed/ing, this would succeed at creating a stack operation for no longer known windows. Simply avoid to queue a stack operation if we know it's meaningless. https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-06-14 15:26:23 +00:00
if (!x11_display->closing)
{
core: Avoid notifying the stack manager of frame reparents during unmanaging This may result in a view of the stack in MetaStackManager that does not correspond to reality, since the window is already being unmanaged, there is no point either in notifying the stack manager about it. This slight divergence with reality in the MetaStackManager may produce a non-accurate view if querying its state has to go through the predicted branches. Later synchronization with the X11 stack may even this out, but the result really depends on when it is asked. Fixes some intermittent failures in the stacking/closed-transient-only-take-focus-parents unit test. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-11-21 11:59:42 +00:00
if (!window->unmanaging)
{
meta_stack_tracker_record_add (window->display->stack_tracker,
window->xwindow,
XNextRequest (x11_display->xdisplay));
}
core: Avoid queueing a stack operation on the frame when the X11 is closing When rushing to unmanage X11 windows after the X11 connection is closed/ing, this would succeed at creating a stack operation for no longer known windows. Simply avoid to queue a stack operation if we know it's meaningless. https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-06-14 15:26:23 +00: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);
core: Fix multiple reparent requests handling If window decoration is modified within a short period of time, mutter sometimes starts processing the second request before the first UnmapNotify event has been received. In this situation, it considers that the window is not mapped and does not expect another UnmapNotify / MapNotify event sequence to happen. This adds a separate counter to keep track of the pending reparents. The input focus is then restored when MapNotify event is received iff all the expected pending ReparentNotify events have been received. Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> https://gitlab.gnome.org/GNOME/mutter/merge_requests/657
2019-06-24 13:10:22 +00:00
window->reparents_pending += 1;
core: Avoid queueing a stack operation on the frame when the X11 is closing When rushing to unmanage X11 windows after the X11 connection is closed/ing, this would succeed at creating a stack operation for no longer known windows. Simply avoid to queue a stack operation if we know it's meaningless. https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-06-14 15:26:23 +00:00
}
core: Delete _MUTTER_NEEDS_FRAME property when destroying frame If the window is unmapped or otherwise unmanaged while still existing, we would fail to let the frames client follow up in destroying the frame for the window. Delete the _MUTTER_NEEDS_FRAME property, so that the frames client can react to meta_window_destroy_frame(), this avoids stale invisible frame windows for clients that simply unmap windows to reuse them later. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2791>
2023-01-16 14:18:15 +00:00
XDeleteProperty (x11_display->xdisplay,
window->xwindow,
x11_display->atom__MUTTER_NEEDS_FRAME);
Rename errors.[ch] to meta-x11-errors.[ch] Also rename meta_error_trap_* to meta_x11_error_trap_* and move meta-x11-errors.c to src/x11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-27 18:48:55 +00:00
meta_x11_error_trap_pop (x11_display);
...
2001-05-31 06:42:58 +00:00
core: Preserve focus across decoration changes Changes in window decoration result in the window being reparented in and out its frame. This in turn causes unmap/map events, and XI_FocusOut if the window happened to be focused. In order to preserve the focused window across the decoration change, add a flag so that the focus may be restored on MapNotify. Closes: #273
2018-08-21 22:58:06 +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;
Move alarm and xids management to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:56:44 +00:00
meta_x11_display_unregister_x_window (x11_display, frame->xwindow);
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
...
2001-05-31 06:42:58 +00:00
window->frame = NULL;
frame: destroy window->frame_bounds when destroying the frame Since window->frame_bounds is used as a cache we need to invalidate it when destroying the frame. https://bugzilla.gnome.org/show_bug.cgi?id=660773
2011-10-03 12:59:16 +00:00
if (window->frame_bounds)
{
cairo_region_destroy (window->frame_bounds);
window->frame_bounds = NULL;
}
...
2001-05-31 06:42:58 +00:00
...
2001-06-23 05:49:35 +00:00
/* Move keybindings to window instead of frame */
meta_window_grab_keys (window);
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
x11: Add frame synchronization to window frames There's two meanings of "frame" there! Since SSD frames are now rendered by an external client, and there are no actual mechanism that ensures the frame did already get painted when the client did respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be artifacts when resizing windows. In order to get always the best visual result, we should actually synchronize rendering with both the client window and the window frame window. This commit adds these mechanisms, so a sync alarm update is expected on both windows until further resizes are allowed, this ensures window and frame stay in sync, even after moving rendering elsewhere. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-09 13:54:28 +00:00
meta_sync_counter_clear (&frame->sync_counter);
...
2001-05-31 06:42:58 +00:00
g_free (frame);
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
...
2001-06-04 06:17:52 +00: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-11 01:15:33 +00:00
meta_window_queue (window, META_QUEUE_CALC_SHOWING);
queue resize on window undecorate * src/core/frame.c: queue resize on window undecorate svn path=/trunk/; revision=4114
2009-02-05 01:06:15 +00:00
meta_window_queue (window, META_QUEUE_MOVE_RESIZE);
...
2001-05-31 06:42:58 +00:00
}
...
2001-06-18 03:24:25 +00:00
MetaFrameFlags
meta_frame_get_flags (MetaFrame *frame)
{
MetaFrameFlags flags;
Theme breakage! Themes have to implement "border" frames now, see Atlanta 2002-06-21 Havoc Pennington <hp@pobox.com> Theme breakage! Themes have to implement "border" frames now, see Atlanta for an example. Fixes #84285 * src/tools/metacity-window-demo.c (do_appwindow): add a border-only window * src/window.c (update_mwm_hints): read border only from the MWM hints * src/window.h (struct _MetaWindow): add border_only flag * src/core.c (meta_core_get_frame_type): report border type if required * src/common.h (enum): add META_FRAME_TYPE_BORDER
2002-06-22 03:23:02 +00:00
flags = 0;
...
2001-06-23 18:30:27 +00:00
Theme breakage! Themes have to implement "border" frames now, see Atlanta 2002-06-21 Havoc Pennington <hp@pobox.com> Theme breakage! Themes have to implement "border" frames now, see Atlanta for an example. Fixes #84285 * src/tools/metacity-window-demo.c (do_appwindow): add a border-only window * src/window.c (update_mwm_hints): read border only from the MWM hints * src/window.h (struct _MetaWindow): add border_only flag * src/core.c (meta_core_get_frame_type): report border type if required * src/common.h (enum): add META_FRAME_TYPE_BORDER
2002-06-22 03:23:02 +00: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;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
Theme breakage! Themes have to implement "border" frames now, see Atlanta 2002-06-21 Havoc Pennington <hp@pobox.com> Theme breakage! Themes have to implement "border" frames now, see Atlanta for an example. Fixes #84285 * src/tools/metacity-window-demo.c (do_appwindow): add a border-only window * src/window.c (update_mwm_hints): read border only from the MWM hints * src/window.h (struct _MetaWindow): add border_only flag * src/core.c (meta_core_get_frame_type): report border type if required * src/common.h (enum): add META_FRAME_TYPE_BORDER
2002-06-22 03:23:02 +00:00
if (frame->window->has_close_func)
flags |= META_FRAME_ALLOWS_DELETE;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
Theme breakage! Themes have to implement "border" frames now, see Atlanta 2002-06-21 Havoc Pennington <hp@pobox.com> Theme breakage! Themes have to implement "border" frames now, see Atlanta for an example. Fixes #84285 * src/tools/metacity-window-demo.c (do_appwindow): add a border-only window * src/window.c (update_mwm_hints): read border only from the MWM hints * src/window.h (struct _MetaWindow): add border_only flag * src/core.c (meta_core_get_frame_type): report border type if required * src/common.h (enum): add META_FRAME_TYPE_BORDER
2002-06-22 03:23:02 +00:00
if (frame->window->has_maximize_func)
flags |= META_FRAME_ALLOWS_MAXIMIZE;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
Theme breakage! Themes have to implement "border" frames now, see Atlanta 2002-06-21 Havoc Pennington <hp@pobox.com> Theme breakage! Themes have to implement "border" frames now, see Atlanta for an example. Fixes #84285 * src/tools/metacity-window-demo.c (do_appwindow): add a border-only window * src/window.c (update_mwm_hints): read border only from the MWM hints * src/window.h (struct _MetaWindow): add border_only flag * src/core.c (meta_core_get_frame_type): report border type if required * src/common.h (enum): add META_FRAME_TYPE_BORDER
2002-06-22 03:23:02 +00:00
if (frame->window->has_minimize_func)
flags |= META_FRAME_ALLOWS_MINIMIZE;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
Theme breakage! Themes have to implement "border" frames now, see Atlanta 2002-06-21 Havoc Pennington <hp@pobox.com> Theme breakage! Themes have to implement "border" frames now, see Atlanta for an example. Fixes #84285 * src/tools/metacity-window-demo.c (do_appwindow): add a border-only window * src/window.c (update_mwm_hints): read border only from the MWM hints * src/window.h (struct _MetaWindow): add border_only flag * src/core.c (meta_core_get_frame_type): report border type if required * src/common.h (enum): add META_FRAME_TYPE_BORDER
2002-06-22 03:23:02 +00:00
if (frame->window->has_shade_func)
flags |= META_FRAME_ALLOWS_SHADE;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
}
use new macros to get whether we allow move/resize correct 2002-07-02 Havoc Pennington <hp@pobox.com> * src/window.c (meta_window_show_menu): use new macros to get whether we allow move/resize correct * src/frame.c (meta_frame_get_flags): use new macros to get whether we can move/resize correct, considering maximized/fullscreen for the move case. * src/window.h (META_WINDOW_ALLOWS_RESIZE, META_WINDOW_ALLOWS_MOVE): new macros * src/keybindings.c (process_keyboard_resize_grab): finish the right/left resize, patch from Jayaraj #78179. Has the same old move/resize bug, if it hits a constraint it starts to break because we move without resizing.
2002-07-03 02:32:40 +00:00
if (META_WINDOW_ALLOWS_MOVE (frame->window))
...
2001-06-23 18:30:27 +00:00
flags |= META_FRAME_ALLOWS_MOVE;
...
2001-07-03 01:45:43 +00:00
use new macros to get whether we allow move/resize correct 2002-07-02 Havoc Pennington <hp@pobox.com> * src/window.c (meta_window_show_menu): use new macros to get whether we allow move/resize correct * src/frame.c (meta_frame_get_flags): use new macros to get whether we can move/resize correct, considering maximized/fullscreen for the move case. * src/window.h (META_WINDOW_ALLOWS_RESIZE, META_WINDOW_ALLOWS_MOVE): new macros * src/keybindings.c (process_keyboard_resize_grab): finish the right/left resize, patch from Jayaraj #78179. Has the same old move/resize bug, if it hits a constraint it starts to break because we move without resizing.
2002-07-03 02:32:40 +00: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;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
Optionally attach modal dialogs Add a preference /apps/mutter/general/attach_modal_dialogs. When true, instead of having independent titlebars, modal dialogs appear attached to the titlebar of the parent window and are moved together with the parent window. https://bugzilla.gnome.org/show_bug.cgi?id=612726
2010-09-10 09:55:20 +00:00
if (meta_window_appears_focused (frame->window))
...
2001-06-18 03:24:25 +00:00
flags |= META_FRAME_HAS_FOCUS;
if (frame->window->shaded)
flags |= META_FRAME_SHADED;
Split out on_all_workspaces and on_all_workspaces_requested Sometimes on_all_workspaces is requested by the client/user, and sometimes its calculated implicitly due to internal state. We split this up so that we know when the user has explicitly asked for sticky window, when e.g. setting wmspec properties or storing session info. on_all_workspaces means this window is visible on all workspaces. on_all_workspaces_requested, means the user explicitly made the window sticky somehow (via imported session, _NET_WM_STATE from another wm, toggled in the window menu, etc). It always implies on_all_workspaces is TRUE. Right now the only time we set on_all_workspaces is for override-redirect windows, but later we can add a "windows on non-primary monitor are not part of the workspace switching" feature. https://bugzilla.gnome.org/show_bug.cgi?id=609258
2011-02-28 10:41:23 +00:00
if (frame->window->on_all_workspaces_requested)
...
2001-06-18 03:24:25 +00:00
flags |= META_FRAME_STUCK;
...
2001-06-18 06:11:53 +00: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 14:58:50 +00: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))
short-circuit the "only one xinerama" case, and use outer rect of window 2002-06-08 Havoc Pennington <hp@pobox.com> * src/screen.c (meta_screen_get_xinerama_for_window): short-circuit the "only one xinerama" case, and use outer rect of window instead of window->rect, so we get root window coords. * src/theme.c (meta_frame_layout_get_borders): if fullscreen all frame edges are zero-width. * src/frame.c (meta_frame_get_flags): init fullscreen flag. * src/common.h (enum): add META_FRAME_FULLSCREEN frame flag * src/place.c: fix up calls to meta_window_get_work_area * src/window.c (meta_window_get_work_area): add an arg for whether the work area is for the screen or the xinerama subscreen. (constrain_position): fix up calls to meta_window_get_work_area (constrain_size): ditto * src/screen.c (meta_screen_new): add METACITY_DEBUG_XINERAMA environment variable which simulates xinerama on a single head.
2002-06-08 06:07:21 +00:00
flags |= META_FRAME_MAXIMIZED;
Revert "window: Remove old tiling code" This reverts commit 8bded7d497f493cf7c3c5bb0ff5a353e34981215.
2016-01-10 14:16:09 +00: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;
short-circuit the "only one xinerama" case, and use outer rect of window 2002-06-08 Havoc Pennington <hp@pobox.com> * src/screen.c (meta_screen_get_xinerama_for_window): short-circuit the "only one xinerama" case, and use outer rect of window instead of window->rect, so we get root window coords. * src/theme.c (meta_frame_layout_get_borders): if fullscreen all frame edges are zero-width. * src/frame.c (meta_frame_get_flags): init fullscreen flag. * src/common.h (enum): add META_FRAME_FULLSCREEN frame flag * src/place.c: fix up calls to meta_window_get_work_area * src/window.c (meta_window_get_work_area): add an arg for whether the work area is for the screen or the xinerama subscreen. (constrain_position): fix up calls to meta_window_get_work_area (constrain_size): ditto * src/screen.c (meta_screen_new): add METACITY_DEBUG_XINERAMA environment variable which simulates xinerama on a single head.
2002-06-08 06:07:21 +00:00
if (frame->window->fullscreen)
flags |= META_FRAME_FULLSCREEN;
...
2001-06-23 06:54:28 +00: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 16:56:47 +00:00
if (frame->window->wm_state_above)
flags |= META_FRAME_ABOVE;
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
...
2001-06-18 06:11:53 +00:00
return flags;
...
2001-06-18 03:24:25 +00:00
}
MetaFrameBorders: Add meta_frame_borders_clear Just a quick little commit to help clean things up for when we add invisible borders. Additionally, do a little housekeeping in preview-widget as well. https://bugzilla.gnome.org/show_bug.cgi?id=644930
2011-07-12 04:59:12 +00:00
void
meta_frame_borders_clear (MetaFrameBorders *self)
{
MetaFrameBorders: Add invisible borders This just adds the invisible border field and populates it with data but doesn't use it in any way. https://bugzilla.gnome.org/show_bug.cgi?id=644930
2011-07-12 04:55:50 +00: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;
MetaFrameBorders: Add meta_frame_borders_clear Just a quick little commit to help clean things up for when we add invisible borders. Additionally, do a little housekeeping in preview-widget as well. https://bugzilla.gnome.org/show_bug.cgi?id=644930
2011-07-12 04:59:12 +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
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)
{
core: Add a in-tree copy of GtkBorder Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
2022-05-09 09:24:23 +00:00
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)
{
core: Add a in-tree copy of GtkBorder Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
2022-05-09 09:24:23 +00:00
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);
core: Add a in-tree copy of GtkBorder Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
2022-05-09 09:24:23 +00:00
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
Replace public MetaFrameGeometry with MetaFrameBorders There were actually *two* MetaFrameGeometry structs: one in theme-private.h, one in frame.h. The latter public struct was populated by a mix of (void*) casting and int pointers, usually pulling directly from the data in the private struct. Remove the public struct, replace it with MetaFrameBorders and scrap all the pointer hacks to populate it, instead relying on both structs being used in common code. This commit should be relatively straightforward, and it should not do any tricky logic at all, just a sophisticated find and replace. https://bugzilla.gnome.org/show_bug.cgi?id=644930
2011-07-12 04:37:41 +00:00
meta_frame_calc_borders (MetaFrame *frame,
MetaFrameBorders *borders)
...
2001-06-18 03:24:25 +00:00
{
Simplify the frame testing logic in callers to grab borders A lot of code did something similar to: MetaFrameBorders borders; if (window->frame) meta_frame_calc_borders (window->frame, &borders); else meta_frame_borders_clear (&borders); Sometimes, the else part was omitted and we were unknowingly using uninitalized values for OR windows. Clean this up by just testing for a NULL frame in meta_frame_calc_borders and clearing for the caller if so. https://bugzilla.gnome.org/show_bug.cgi?id=643606
2012-03-13 03:11:07 +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
MetaFrame: Cache borders Cache the computed border size so we can fetch the border size at any time without worrying that we'll be spending too much time in the theme code (in some cases we might allocate a PangoFontDescription or do other significant work.) The main effort here is clearing the cache when various bits of window state change that could potentially affect the computed borders. https://bugzilla.gnome.org/show_bug.cgi?id=707194
2013-11-15 22:37:50 +00: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 08:35:47 +00:00
meta_frame_query_borders (frame, &frame->cached_borders);
MetaFrame: Cache borders Cache the computed border size so we can fetch the border size at any time without worrying that we'll be spending too much time in the theme code (in some cases we might allocate a PangoFontDescription or do other significant work.) The main effort here is clearing the cache when various bits of window state change that could potentially affect the computed borders. https://bugzilla.gnome.org/show_bug.cgi?id=707194
2013-11-15 22:37:50 +00:00
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
}
Only shadow ARGB windows with a frame outside the frame An ARGB window with a frame is likely something like a transparent terminal. It looks awful (and breaks transparency) to draw a big opaque black shadow under the window, so clip out the region under the terminal from the shadow we draw. Add meta_window_get_frame_bounds() to get a cairo region for the outer bounds of the frame of a window, and modify the frame handling code to notice changes to the frame shape and discard a cached region. meta_frames_apply_shapes() is refactored so we can extract meta_frames_get_frame_bounds() from it. https://bugzilla.gnome.org/show_bug.cgi?id=635268
2011-03-22 19:36:12 +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;
switch on the op passed in, not the active op. Gives us the right cursor 2002-02-24 Havoc Pennington <hp@pobox.com> * src/display.c (xcursor_for_op): switch on the op passed in, not the active op. Gives us the right cursor during resizing, etc. * src/errors.c: rearrange all the error stuff to adapt to the GDK change a while back, so now we print our X errors again * src/display.c (meta_display_begin_grab_op): remove KeyPressMask and KeyReleaseMask from the XGrabPointer(), this caused BadValue and kept the grab from ever succeeding. Fixes the problem with the GTK resize grip - this is why you shouldn't break your X error spew. ;-) * src/display.c: debug spew tweaks * src/window.c (meta_window_client_message): do some s/verbose/topic/ stuff
2002-02-24 19:58:27 +00:00
meta_topic (META_DEBUG_GEOMETRY,
Make meta_* logging utilities not require line break Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-02 15:47:22 +00:00
"Syncing frame geometry %d,%d %dx%d (SE: %d,%d)",
switch on the op passed in, not the active op. Gives us the right cursor 2002-02-24 Havoc Pennington <hp@pobox.com> * src/display.c (xcursor_for_op): switch on the op passed in, not the active op. Gives us the right cursor during resizing, etc. * src/errors.c: rearrange all the error stuff to adapt to the GDK change a while back, so now we print our X errors again * src/display.c (meta_display_begin_grab_op): remove KeyPressMask and KeyReleaseMask from the XGrabPointer(), this caused BadValue and kept the grab from ever succeeding. Fixes the problem with the GTK resize grip - this is why you shouldn't break your X error spew. ;-) * src/display.c: debug spew tweaks * src/window.c (meta_window_client_message): do some s/verbose/topic/ stuff
2002-02-24 19:58:27 +00: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-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
Only shadow ARGB windows with a frame outside the frame An ARGB window with a frame is likely something like a transparent terminal. It looks awful (and breaks transparency) to draw a big opaque black shadow under the window, so clip out the region under the terminal from the shadow we draw. Add meta_window_get_frame_bounds() to get a cairo region for the outer bounds of the frame of a window, and modify the frame handling code to notice changes to the frame shape and discard a cached region. meta_frames_apply_shapes() is refactored so we can extract meta_frames_get_frame_bounds() from it. https://bugzilla.gnome.org/show_bug.cgi?id=635268
2011-03-22 19:36:12 +00: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 08:35:47 +00: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 21:39:57 +00:00
}
Let the UI layer (via the core) construct the frame mask This essentially just moves install_corners() from the compositor, through the core, into the UI layer where it arguably should have been anyway, leaving behind stub functions which call through the various layers. This removes the compositor's special knowledge of how rounded corners work, replacing it with "ask the UI for an alpha mask". The computation of border widths and heights changes a bit, because the width and height used in install_corners() are the meta_window_get_outer_rect() (which includes the visible borders but not the invisible ones), whereas the more readily-available rectangle is the MetaFrame.rect (which includes both). Computing the same width and height as meta_window_get_outer_rect() involves compensating for the invisible borders, but the UI layer is the authority on those anyway, so it seems clearer to have it do the calculations from scratch. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
2013-04-12 17:00:15 +00:00
void
frame: Pass the frame area for get_mask() Currently, `meta_frame_get_mask()` and `meta_ui_frame_get_mask()` will return the frame mask applied to the current frame size, by querying the frame themselves. To be able to get the frame mask at an arbitrary size, change the API to take a rectangle representing the size at which the frame mask should be rendered. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
2020-01-16 10:42:04 +00:00
meta_frame_get_mask (MetaFrame *frame,
cairo_rectangle_int_t *frame_rect,
cairo_t *cr)
Let the UI layer (via the core) construct the frame mask This essentially just moves install_corners() from the compositor, through the core, into the UI layer where it arguably should have been anyway, leaving behind stub functions which call through the various layers. This removes the compositor's special knowledge of how rounded corners work, replacing it with "ask the UI for an alpha mask". The computation of border widths and heights changes a bit, because the width and height used in install_corners() are the meta_window_get_outer_rect() (which includes the visible borders but not the invisible ones), whereas the more readily-available rectangle is the MetaFrame.rect (which includes both). Computing the same width and height as meta_window_get_outer_rect() involves compensating for the invisible borders, but the UI layer is the authority on those anyway, so it seems clearer to have it do the calculations from scratch. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
2013-04-12 17:00: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
MetaFrameBorders borders;
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +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_frame_calc_borders (frame, &borders);
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +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
cairo_rectangle (cr,
compositor: Opt out compositor shadows from windows with frames Let the frames client render its own shadow. In order to do that, avoid double painting a shadow on the compositor side, and extend the mask area of the frame, so it does unveil the (so far) hidden frames-client-side shadows. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-12 10:27:03 +00:00
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);
Place cursors on frames, not root
2002-08-23 18:00:40 +00:00
}
src/include/frame.h src/include/display.h src/include/xprops.h 2008-05-19 Iain Holmes <iain@gnome.org> * src/include/frame.h * src/include/display.h * src/include/xprops.h * src/include/compositor.h * src/include/types.h * src/include/window.h * src/include/errors.h * src/include/screen.h: New basic public API for compositor. * src/compositor/*: Separate the compositor out into its own separate directory and set it up for backends. Initial XRender backend. * src/core/compositor.[ch]: Remove * src/core/frame.h * src/core/screen.h * src/core/display.h * src/core/window.h: Rename to -private.h so as not to clash with the new files in include * src/core/delete.c * src/core/workspace.h * src/core/stack.[ch] * src/core/keybindings.[ch] * src/core/errors.c * src/core/effects.[ch] * src/core/core.c * src/core/group.h * src/core/edge-resistance.[ch] * src/core/window-props.[ch] * src/core/constraints.h * src/core/bell.[ch] * src/core/iconcache.h * src/core/session.[ch] * src/core/main.c * src/core/place.h * src/core/xprops.c * src/ui/tabpopup.c: Use the new -private headers * src/core/display.c * src/core/frame.c * src/core/window.c * src/core/screen.c: Add the API functions required by the compositor * src/Makefile.am: Relocate the new files svn path=/trunk/; revision=3715
2008-05-19 00:00:09 +00:00
Window
meta_frame_get_xwindow (MetaFrame *frame)
{
return frame->xwindow;
}
Only poke the frames UI code from inside frame.c Add frame.c wrappers for the missing calls, then adapt.
2015-01-01 05:24:49 +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
gboolean
meta_frame_handle_xevent (MetaFrame *frame,
XEvent *xevent)
Only poke the frames UI code from inside frame.c Add frame.c wrappers for the missing calls, then adapt.
2015-01-01 05:24:49 +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;
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;
}
x11: Add frame synchronization to window frames There's two meanings of "frame" there! Since SSD frames are now rendered by an external client, and there are no actual mechanism that ensures the frame did already get painted when the client did respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be artifacts when resizing windows. In order to get always the best visual result, we should actually synchronize rendering with both the client window and the window frame window. This commit adds these mechanisms, so a sync alarm update is expected on both windows until further resizes are allowed, this ensures window and frame stay in sync, even after moving rendering elsewhere. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-09 13:54:28 +00:00
else if (xevent->xany.type == PropertyNotify &&
xevent->xproperty.state == PropertyNewValue &&
xevent->xproperty.atom == x11_display->atom__NET_WM_SYNC_REQUEST_COUNTER)
{
meta_window_reload_property_from_xwindow (window, frame->xwindow,
xevent->xproperty.atom, FALSE);
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;
Only poke the frames UI code from inside frame.c Add frame.c wrappers for the missing calls, then adapt.
2015-01-01 05:24:49 +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
GSubprocess *
meta_frame_launch_client (MetaX11Display *x11_display,
const char *display_name)
Only poke the frames UI code from inside frame.c Add frame.c wrappers for the missing calls, then adapt.
2015-01-01 05:24:49 +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
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;
Only poke the frames UI code from inside frame.c Add frame.c wrappers for the missing calls, then adapt.
2015-01-01 05:24:49 +00:00
}
core: Shuffle function to get description string from a frame This will remain used (and mildly useful), so move it outside of src/ui. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-06-08 14:10:59 +00: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>";
}
x11: Add frame synchronization to window frames There's two meanings of "frame" there! Since SSD frames are now rendered by an external client, and there are no actual mechanism that ensures the frame did already get painted when the client did respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be artifacts when resizing windows. In order to get always the best visual result, we should actually synchronize rendering with both the client window and the window frame window. This commit adds these mechanisms, so a sync alarm update is expected on both windows until further resizes are allowed, this ensures window and frame stay in sync, even after moving rendering elsewhere. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-09 13:54:28 +00:00
MetaSyncCounter *
meta_frame_get_sync_counter (MetaFrame *frame)
{
return &frame->sync_counter;
}
Copy permalink