isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-27 10:30:47 -05:00
Code Issues Packages Projects Releases Wiki Activity
c44b1d730d
mutter/src/core/frame.c

436 lines
14 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 18:30:10 -04:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
Comprehensively rename to Mutter Code: All references in the code not related to themes, keybindings, or GConf were changed from 'metacity' to 'mutter'. This includes, among other things, strings, comments, the atoms used in the message protocol, and the envvars used for debugging. The GConf schema file was reduced to the 3 settings new to mutter. The overall version was brought up to 2.27 to match current gnome. Structure: All files named '*metacity*' were renamed '*mutter*' with appropriate changes in the automake system. Files removed are doc/creating_themes, src/themes, doc/metacity-theme.dtd, metacity.doap. These files will eventually end up in an external gnome-wm-data module. Installation location: On the filesystem the mutter-plugindir was change from $(libdir)/metacity/plugins/clutter to just $(libdir)/mutter/plugins. The mutter-plugins.pc.in reflects these changes. Note: mutter.desktop.in and mutter-wm.desktop both continue to have X-GNOME-WMSettingsModule=metacity set. This allows gnome-control-center to continue using libmetacity.so for configuration. This is fine since most the general keybindings and wm settings are being read from /apps/metacity/* in gconf.
2009-06-10 06:29:20 -04:00
/* Mutter X window decorations */
...
2001-05-31 02:42:58 -04:00
/*
* 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-26 22:17:49 -04:00
* Copyright (C) 2003, 2004 Red Hat, Inc.
Merge of all the changes on the constraints_experiments branch. This is 2005-11-18 Elijah Newren <newren@gmail.com> Merge of all the changes on the constraints_experiments branch. This is just a summary, to get the full ChangeLog of those changes (approx. 2000 lines): cvs -q -z3 update -Pd -r constraints_experiments cvs -q -z3 diff -pu -r CONSTRAINTS_EXPERIMENTS_BRANCHPOINT ChangeLog Bugs fixed: unfiled - constraints.c is overly complicated[1] unfiled - constraints.c is not robust when all constraints cannot simultaneously be met (constraints need to be prioritized) unfiled - keep-titlebar-onscreen constraint is decoration unaware (since get_outermost_onscreen_positions() forgets to include decorations) unfiled - keyboard snap-moving and snap-resizing snap to hidden edges 109553 - gravity w/ simultaneous move & resize doesn't work 113601 - maximize vertical and horizontal should toggle and be constrained 122196 - windows show up under vertical panels 122670 - jerky/random resizing of window via keyboard[2] 124582 - keyboard and mouse snap-resizing and snap-moving erroneously moves the window multidimensionally 136307 - don't allow apps to resize themselves off the screen (*cough* filechooser *cough*) 142016, 143784 - windows should not span multiple xineramas unless placed there by the user 143145 - clamp new windows to screensize and force them onscreen, if they'll fit 144126 - Handle pathological strut lists sanely[3] 149867 - fixed aspect ratio windows are difficult to resize[4] 152898 - make screen edges consistent; allow easy slamming of windows into the left, right, and bottom edges of the screen too. 154706 - bouncing weirdness at screen edge with keyboard moving or resizing 156699 - avoid struts when placing windows, if possible (nasty a11y blocker) 302456 - dragging offscreen too restrictive 304857 - wireframe moving off the top of the screen is misleading 308521 - make uni-directional resizing easier with alt-middle-drag and prevent the occasional super annoying resize-the-wrong-side(s) behavior 312007 - snap-resize moves windows with a minimum size constraint 312104 - resizing the top of a window can cause the bottom to grow 319351 - don't instantly snap on mouse-move-snapping, remove braindeadedness of having order of releasing shift and releasing button press matter so much [1] fixed in my opinion, anyway. [2] Actually, it's not totally fixed--it's just annoying instead of almost completely unusable. Matthias had a suggestion that may fix the remainder of the problems (see http://tinyurl.com/bwzuu). [3] This bug was originally about not-quite-so-pathological cases but was left open for the worse cases. The code from the branch handles the remainder of the cases mentioned in this bug. [4] Actually, although it's far better there's still some minor issues left: a slight drift that's only noticeable after lots of resizing, and potential problems with partially onscreen constraints due to not clearing any fixed_directions flags (aspect ratio windows get resized in both directions and thus aren't fixed in one of them) New feature: 81704 - edge resistance for user move and resize operations; in particular 3 different kinds of resistance are implemented: Pixel-Distance: window movement is resisted when it aligns with an edge unless the movement is greater than a threshold number of pixels Timeout: window movement past an edge is prevented until a certain amount of time has elapsed during the operation since the first request to move it past that edge Keyboard-Buildup: when moving or resizing with the keyboard, once a window is aligned with a certain edge it cannot move past until the correct direction has been pressed enough times (e.g. 2 or 3 times) Major changes: - constraints.c has been rewritten; very few lines of code from the old version remain. There is a comment near the top of the function explaining the basics of how the new framework works. A more detailed explanation can be found in doc/how-constraints-works.txt - edge-resistance.[ch] are new files implementing edge-resistance. - boxes.[ch] are new files containing low-level error-prone functions used heavily in constraints.c and edge-resistance.c, among various places throughout the code. testboxes.c contains a thorough testsuite for the boxes.[ch] functions compiled into a program, testboxes. - meta_window_move_resize_internal() *must* be told the gravity of the associated operation (if it's just a move operation, the gravity will be ignored, but for resize and move+resize the correct value is needed) - the craziness of different values that meta_window_move_resize_internal() accepts has been documented in a large comment at the beginning of the function. It may be possible to clean this up some, but until then things will remain as they were before--caller beware. - screen and xinerama usable areas (i.e. places not covered by e.g. panels) are cached in the workspace now, as are the screen and xinerama edges. These get updated with the workarea in src/workspace.c:ensure_work_areas_validated()
2005-11-19 09:58:50 -05:00
* Copyright (C) 2005 Elijah Newren
...
2001-05-31 02:42:58 -04:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* 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-11 20:42:06 -05:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
...
2001-05-31 02:42:58 -04:00
*/
include config.h 2002-10-26 Havoc Pennington <hp@pobox.com> * src/iconcache.c: include config.h * src/group.c: include config.h * src/frame.c: include config.h * src/core.c: include config.h so it doesn't crash all over the place due to #ifdef HAVE_STARTUP_NOTIFICATION * src/util.c (meta_print_backtrace): export from this file * src/main.c (log_handler): print backtrace here
2002-10-26 23:03:32 -04:00
#include <config.h>
Move the installed includes to a subdir If mutter is going to be a "real" library, then it should install its includes so that users can do #include <meta/display.h> rather than #include <display.h> So rename the includedir accordingly, move src/include to src/meta, and fix up all internal references. There were a handful of header files in src/include that were not installed; this appears to have been part of a plan to keep core/, ui/, and compositor/ from looking at each others' private includes, but that wasn't really working anyway. So move all non-installed headers back into core/ or ui/. https://bugzilla.gnome.org/show_bug.cgi?id=643959
2011-03-05 19:29:12 -05:00
#include "frame.h"
Reinstated visual-bell patch, fix for bug 99886.
2003-01-28 10:07:43 -05:00
#include "bell.h"
Move the installed includes to a subdir If mutter is going to be a "real" library, then it should install its includes so that users can do #include <meta/display.h> rather than #include <display.h> So rename the includedir accordingly, move src/include to src/meta, and fix up all internal references. There were a handful of header files in src/include that were not installed; this appears to have been part of a plan to keep core/, ui/, and compositor/ from looking at each others' private includes, but that wasn't really working anyway. So move all non-installed headers back into core/ or ui/. https://bugzilla.gnome.org/show_bug.cgi?id=643959
2011-03-05 19:29:12 -05:00
#include <meta/errors.h>
Rename keybindings.h to keybindings-private.h
2009-01-29 09:16:01 -05:00
#include "keybindings-private.h"
...
2001-06-03 17:39:57 -04:00
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-26 22:17:49 -04:00
#include <X11/extensions/Xrender.h>
...
2001-06-19 23:01:26 -04:00
#define EVENT_MASK (SubstructureRedirectMask | \
StructureNotifyMask | SubstructureNotifyMask | \
ExposureMask | \
ButtonPressMask | ButtonReleaseMask | \
PointerMotionMask | PointerMotionHintMask | \
...
2001-06-23 01:49:35 -04:00
EnterWindowMask | LeaveWindowMask | \
window: Kill off the rest of colormaps I removed the XInstallColormap / XUninstallColormap but forgot to remove the fields in MetaWindow and the code to set them.
2014-03-20 16:26:14 -04:00
FocusChangeMask)
...
2001-06-19 23:01:26 -04:00
...
2001-06-02 21:33:27 -04:00
void
meta_window_ensure_frame (MetaWindow *window)
{
MetaFrame *frame;
XSetWindowAttributes attrs;
Inherit visual from frame window so that metacity will work with the new 2003-11-15 Rob Adams <readams@readams.net> Inherit visual from frame window so that metacity will work with the new compositing manager extension work by Keith on freedesktop.org, so that ARGB windows can be full alpha-transparent without a metacity frame getting drawn in the background. In the long term, we need to actually set alpha values when drawing the frame so that it will really work; this is a stopgap solution. Patch from Keith Packard; see Bug 126875. * src/frame.c (meta_window_ensure_frame): pass client visual to frame. * src/ui.[ch] (meta_ui_create_frame_window): add new xvisual parameter and use it to create new window.
2003-11-15 23:19:18 -05:00
Visual *visual;
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 16:45:32 -04:00
gulong create_serial;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 06:22:13 -04:00
MetaStackWindow stack_window;
...
2001-06-02 21:33:27 -04:00
if (window->frame)
return;
Don't try to use an ARGB visual at all if the depth isn't 32-bit. This 2004-10-19 Anders Carlsson <andersca@gnome.org> * src/frame.c: (meta_window_ensure_frame): Don't try to use an ARGB visual at all if the depth isn't 32-bit. This caused major slowdowns with Composite enabled.
2004-10-19 01:18:11 -04:00
...
2001-06-02 21:33:27 -04:00
frame = g_new (MetaFrame, 1);
frame->window = window;
frame->xwindow = None;
...
2001-06-09 17:58:30 -04:00
frame->rect = window->rect;
frame->child_x = 0;
frame->child_y = 0;
frame->bottom_height = 0;
frame->right_width = 0;
Place cursors on frames, not root
2002-08-23 14:00:40 -04:00
frame->current_cursor = 0;
...
2001-06-09 17:58:30 -04:00
Reinstated visual-bell patch, fix for bug 99886.
2003-01-28 10:07:43 -05:00
frame->is_flashing = FALSE;
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 17:37:50 -05:00
frame->borders_cached = FALSE;
...
2001-06-09 23:17:15 -04:00
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-08 23:44:42 -04:00
meta_verbose ("Framing window %s: visual %s default, depth %d default depth %d\n",
window->desc,
XVisualIDFromVisual (window->xvisual) ==
XVisualIDFromVisual (window->screen->default_xvisual) ?
"is" : "is not",
window->depth, window->screen->default_depth);
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 14:18:38 -04:00
meta_verbose ("Frame geometry %d,%d %dx%d\n",
frame->rect.x, frame->rect.y,
frame->rect.width, frame->rect.height);
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-08 23:44:42 -04:00
/* Default depth/visual handles clients with weird visuals; they can
* always be children of the root depth/visual obviously, but
* e.g. DRI games can't be children of a parent that has the same
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-26 22:17:49 -04:00
* visual as the client. NULL means default visual.
*
* We look for an ARGB visual if we can find one, otherwise use
* the default of NULL.
*/
/* Special case for depth 32 windows (assumed to be ARGB),
Don't try to use an ARGB visual at all if the depth isn't 32-bit. This 2004-10-19 Anders Carlsson <andersca@gnome.org> * src/frame.c: (meta_window_ensure_frame): Don't try to use an ARGB visual at all if the depth isn't 32-bit. This caused major slowdowns with Composite enabled.
2004-10-19 01:18:11 -04:00
* we use the window's visual. Otherwise we just use the system visual.
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-08 23:44:42 -04:00
*/
Inherit visual from frame window so that metacity will work with the new 2003-11-15 Rob Adams <readams@readams.net> Inherit visual from frame window so that metacity will work with the new compositing manager extension work by Keith on freedesktop.org, so that ARGB windows can be full alpha-transparent without a metacity frame getting drawn in the background. In the long term, we need to actually set alpha values when drawing the frame so that it will really work; this is a stopgap solution. Patch from Keith Packard; see Bug 126875. * src/frame.c (meta_window_ensure_frame): pass client visual to frame. * src/ui.[ch] (meta_ui_create_frame_window): add new xvisual parameter and use it to create new window.
2003-11-15 23:19:18 -05:00
if (window->depth == 32)
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-26 22:17:49 -04:00
visual = window->xvisual;
else
Don't try to use an ARGB visual at all if the depth isn't 32-bit. This 2004-10-19 Anders Carlsson <andersca@gnome.org> * src/frame.c: (meta_window_ensure_frame): Don't try to use an ARGB visual at all if the depth isn't 32-bit. This caused major slowdowns with Composite enabled.
2004-10-19 01:18:11 -04:00
visual = NULL;
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 12:32:10 -04:00
frame->xwindow = meta_ui_create_frame_window (window->screen->ui,
Inherit visual from frame window so that metacity will work with the new 2003-11-15 Rob Adams <readams@readams.net> Inherit visual from frame window so that metacity will work with the new compositing manager extension work by Keith on freedesktop.org, so that ARGB windows can be full alpha-transparent without a metacity frame getting drawn in the background. In the long term, we need to actually set alpha values when drawing the frame so that it will really work; this is a stopgap solution. Patch from Keith Packard; see Bug 126875. * src/frame.c (meta_window_ensure_frame): pass client visual to frame. * src/ui.[ch] (meta_ui_create_frame_window): add new xvisual parameter and use it to create new window.
2003-11-15 23:19:18 -05:00
window->display->xdisplay,
visual,
frame->rect.x,
frame->rect.y,
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 12:32:10 -04:00
frame->rect.width,
frame->rect.height,
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 16:45:32 -04:00
frame->window->screen->number,
&create_serial);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 06:22:13 -04:00
stack_window.any.type = META_WINDOW_CLIENT_TYPE_X11;
stack_window.x11.xwindow = 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 16:45:32 -04:00
meta_stack_tracker_record_add (window->screen->stack_tracker,
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 06:22:13 -04:00
&stack_window,
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 16:45:32 -04: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 12:32:10 -04:00
...
2001-06-09 17:58:30 -04:00
meta_verbose ("Frame for %s is 0x%lx\n", frame->window->desc, frame->xwindow);
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 12:32:10 -04:00
attrs.event_mask = EVENT_MASK;
XChangeWindowAttributes (window->display->xdisplay,
frame->xwindow, CWEventMask, &attrs);
...
2001-06-02 00:14:18 -04:00
...
2001-05-31 02:42:58 -04:00
meta_display_register_x_window (window->display, &frame->xwindow, window);
meta_error_trap_push (window->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-10 22:31:14 -05:00
if (window->mapped)
{
window->mapped = FALSE; /* the reparent will unmap the window,
* we don't want to take that as a withdraw
*/
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-07 22:34:26 -05:00
meta_topic (META_DEBUG_WINDOW_STATE,
"Incrementing unmaps_pending on %s for reparent\n", 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-10 22:31:14 -05: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-08 23:44:42 -04:00
/* window was reparented to this position */
...
2001-06-11 01:47:51 -04:00
window->rect.x = 0;
window->rect.y = 0;
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-08 23:44:42 -04:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 06:22:13 -04:00
stack_window.x11.xwindow = window->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 16:45:32 -04:00
meta_stack_tracker_record_remove (window->screen->stack_tracker,
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 06:22:13 -04:00
&stack_window,
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 16:45:32 -04:00
XNextRequest (window->display->xdisplay));
...
2001-05-31 02:42:58 -04:00
XReparentWindow (window->display->xdisplay,
window->xwindow,
frame->xwindow,
...
2001-06-11 01:47:51 -04:00
window->rect.x,
window->rect.y);
makefile tweak, add a comment to frame.c
2001-10-13 00:00:08 -04:00
/* FIXME handle this error */
Remove compatibility for GTK+-2.0 While the Meego developers agreed to switching mutter to GTK+-3.0 unconditionally a while ago, Canonical used a GTK+-2.0 build for their Unity project. As Canonical now announced a switch to compiz as their window manager, there is no longer a reason to maintain GTK+-2.0 compatibility. https://bugzilla.gnome.org/show_bug.cgi?id=633133
2010-10-25 14:44:30 -04:00
meta_error_trap_pop (window->display);
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-08 23:44:42 -04:00
...
2001-05-31 02:42:58 -04:00
/* stick frame to the window */
...
2001-06-04 02:17:52 -04: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 17:15:47 -04:00
/* Now that frame->xwindow is registered with window, we can set its
ui-frames: Delay attaching the style to new frames Like the setting of new frames' background is delayed until the frame is associated with its window, delay attaching the initial style, so that the correct style variant is picked. https://bugzilla.gnome.org/show_bug.cgi?id=645355
2011-03-20 18:20:51 -04:00
* style and background.
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 17:15:47 -04:00
*/
ui-frames: Delay attaching the style to new frames Like the setting of new frames' background is delayed until the frame is associated with its window, delay attaching the initial style, so that the correct style variant is picked. https://bugzilla.gnome.org/show_bug.cgi?id=645355
2011-03-20 18:20:51 -04:00
meta_ui_update_frame_style (window->screen->ui, frame->xwindow);
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 17:15:47 -04:00
meta_ui_reset_frame_bg (window->screen->ui, frame->xwindow);
...
2001-06-19 23:01:26 -04:00
if (window->title)
meta_ui_set_frame_title (window->screen->ui,
window->frame->xwindow,
window->title);
...
2001-06-23 01:49:35 -04:00
/* Move keybindings to frame instead of window */
meta_window_grab_keys (window);
Always map the client and frame windows Traditionally, WMs unmap windows when minimizing them, and map them when restoring them or wanting to show them for other reasons, like upon creation. However, as metacity morphed into mutter, we optionally chose to keep windows mapped for the lifetime of the window under the user option "live-window-previews", which makes the code keep windows mapped so it can show window preview for minimized windows in other places, like Alt-Tab and Expose. I removed this preference two years ago mechanically, by removing all the if statements, but never went through and cleaned up the code so that windows are simply mapped for the lifetime of the window -- the "architecture" of the old code that maps and unmaps on show/hide was still there. Remove this now. The one case we still need to be careful of is shaded windows, in which we do still unmap the client window. In the future, we might want to show previews of shaded windows in the overview and Alt-Tab. In that we'd also keep shaded windows mapped, and could remove all unmap logic, but we'd need a more complex method of showing the shaded titlebar, such as using a different actor. At the same time, simplify the compositor interface by removing meta_compositor_window_[un]mapped API, and instead adding/removing the window on-demand. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 19:06:51 -05:00
meta_ui_map_frame (frame->window->screen->ui, frame->xwindow);
...
2001-05-31 02:42:58 -04: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 17:18:50 -04:00
MetaFrameBorders borders;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 06:22:13 -04:00
MetaStackWindow stack_window;
...
2001-05-31 02:42:58 -04:00
if (window->frame == NULL)
return;
handle ReparentNotify, and add a lot of debug output. 2003-12-25 Havoc Pennington <hp@redhat.com> * src/compositor.c (process_reparent): handle ReparentNotify, and add a lot of debug output.
2003-12-25 21:42:38 -05:00
meta_verbose ("Unframing window %s\n", window->desc);
...
2001-05-31 02:42:58 -04: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 17:18:50 -04:00
meta_frame_calc_borders (frame, &borders);
...
2001-06-23 01:49:35 -04:00
Reinstated visual-bell patch, fix for bug 99886.
2003-01-28 10:07:43 -05:00
meta_bell_notify_frame_destroy (frame);
...
2001-05-31 02:42:58 -04:00
/* Unparent the client window; it may be destroyed,
* thus the error trap.
*/
meta_error_trap_push (window->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-10 22:31:14 -05:00
if (window->mapped)
{
window->mapped = FALSE; /* Keep track of unmapping it, so we
* can identify a withdraw initiated
* by the client.
*/
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-07 22:34:26 -05:00
meta_topic (META_DEBUG_WINDOW_STATE,
"Incrementing unmaps_pending on %s for reparent back to root\n", 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-10 22:31:14 -05:00
window->unmaps_pending += 1;
}
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 06:22:13 -04:00
stack_window.any.type = META_WINDOW_CLIENT_TYPE_X11;
stack_window.x11.xwindow = window->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 16:45:32 -04:00
meta_stack_tracker_record_add (window->screen->stack_tracker,
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 06:22:13 -04:00
&stack_window,
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 16:45:32 -04:00
XNextRequest (window->display->xdisplay));
...
2001-05-31 02:42:58 -04:00
XReparentWindow (window->display->xdisplay,
window->xwindow,
window->screen->xroot,
Make sure apps have correct info about their coordinates, even on unmap. 2007-04-11 Elijah Newren <newren gmail com> Make sure apps have correct info about their coordinates, even on unmap. Fixes temporary hang with libXt (XtVaSetValues setting x & y coordinates). #399552. * src/frame.c (meta_window_destroy_frame): Add a comment noting that the current choice causes the need for a ConfigureNotify event * src/window.c (meta_window_free): Send a configure notify event due to our XReparentWindow coordinate choices on withdrawal, (unmaximize_window_before_freeing): no need to send a configure notify from here since it is always done in meta_window_free new, (send_configure_notify): have to special case the coordinates used when withdrawing the window svn path=/trunk/; revision=3192
2007-04-12 00:02:57 -04:00
/* Using anything other than meta_window_get_position()
* coordinates here means we'll need to ensure a configure
* notify event is sent; see bug 399552.
*/
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 17:18:50 -04:00
window->frame->rect.x + borders.invisible.left,
window->frame->rect.y + borders.invisible.top);
Remove compatibility for GTK+-2.0 While the Meego developers agreed to switching mutter to GTK+-3.0 unconditionally a while ago, Canonical used a GTK+-2.0 build for their Unity project. As Canonical now announced a switch to compiz as their window manager, there is no longer a reason to maintain GTK+-2.0 compatibility. https://bugzilla.gnome.org/show_bug.cgi?id=633133
2010-10-25 14:44:30 -04:00
meta_error_trap_pop (window->display);
...
2001-05-31 02:42:58 -04:00
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 12:32:10 -04:00
meta_ui_destroy_frame_window (window->screen->ui, frame->xwindow);
...
2001-05-31 02:42:58 -04:00
meta_display_unregister_x_window (window->display,
frame->xwindow);
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 08:59:16 -04:00
if (window->frame_bounds)
{
cairo_region_destroy (window->frame_bounds);
window->frame_bounds = NULL;
}
...
2001-05-31 02:42:58 -04:00
...
2001-06-23 01:49:35 -04:00
/* Move keybindings to window instead of frame */
meta_window_grab_keys (window);
...
2001-05-31 02:42:58 -04:00
g_free (frame);
...
2001-06-04 02:17:52 -04:00
/* Put our state back where it should be */
Refactor thrice-duplicated queue code in window.c. Closes #376760. 2007-06-10 Thomas Thurman <thomas@thurman.org.uk> Refactor thrice-duplicated queue code in window.c. Closes #376760. * src/window.c (meta_window_queue, meta_window_unqueue): New functions. * src/window.[ch] (meta_window_unqueue_*, meta_window_queue_*): Removed functions. * src/window.c (meta_window_new_with_attrs, meta_window_free, meta_window_flush_calc_showing, queue_calc_showing_func, meta_window_minimize, meta_window_unminimize, meta_window_maximize, meta_window_make_fullscreen, meta_window_shade, meta_window_unshade, meta_window_move_resize_internal, window_stick_impl, window_unstick_impl, meta_window_client_message, process_property_notify): Modified to use new queueing functions. * src/window.c (idle_move_resize, idle_update_icon, idle_calc_showing): update to receive queue number from pointer. * src/window.h (MetaQueueType): new enum. * src/window.h (MetaWindow): *_queued replaced with is_in_queue bitfield. * src/core.c (meta_core_queue_frame_resize): * src/display.c (event_callback, meta_display_queue_retheme_all_windows): Using new queueing functions. * src/frame.c (meta_window_destroy_frame): Using new queueing functions. * src/screen.c (queue_resize, meta_screen_resize_func, queue_windows_showing): Using new queueing functions. * src/window-props.c (reload_mwm_hints, reload_wm_hints, reload_transient_for): Using new queueing functions. * src/workspace.c (meta_workspace_add_window, meta_workspace_remove_window, meta_workspace_queue_calc_showing, meta_workspace_invalidate_work_area): Using new queueing functions. svn path=/trunk/; revision=3236
2007-06-10 21:15:33 -04:00
meta_window_queue (window, META_QUEUE_CALC_SHOWING);
queue resize on window undecorate * src/core/frame.c: queue resize on window undecorate svn path=/trunk/; revision=4114
2009-02-04 20:06:15 -05:00
meta_window_queue (window, META_QUEUE_MOVE_RESIZE);
...
2001-05-31 02:42:58 -04:00
}
...
2001-06-17 23:24:25 -04:00
MetaFrameFlags
meta_frame_get_flags (MetaFrame *frame)
{
MetaFrameFlags flags;
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-21 23:23:02 -04:00
flags = 0;
...
2001-06-23 14:30:27 -04: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-21 23:23:02 -04:00
if (frame->window->border_only)
{
; /* FIXME this may disable the _function_ as well as decor
* in some cases, which is sort of wrong.
*/
}
else
{
flags |= META_FRAME_ALLOWS_MENU;
if (frame->window->has_close_func)
flags |= META_FRAME_ALLOWS_DELETE;
if (frame->window->has_maximize_func)
flags |= META_FRAME_ALLOWS_MAXIMIZE;
if (frame->window->has_minimize_func)
flags |= META_FRAME_ALLOWS_MINIMIZE;
if (frame->window->has_shade_func)
flags |= META_FRAME_ALLOWS_SHADE;
}
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-02 22:32:40 -04:00
if (META_WINDOW_ALLOWS_MOVE (frame->window))
...
2001-06-23 14:30:27 -04:00
flags |= META_FRAME_ALLOWS_MOVE;
...
2001-07-02 21:45:43 -04:00
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-02 22:32:40 -04:00
if (META_WINDOW_ALLOWS_HORIZONTAL_RESIZE (frame->window))
flags |= META_FRAME_ALLOWS_HORIZONTAL_RESIZE;
if (META_WINDOW_ALLOWS_VERTICAL_RESIZE (frame->window))
flags |= META_FRAME_ALLOWS_VERTICAL_RESIZE;
...
2001-06-17 23:24:25 -04: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 05:55:20 -04:00
if (meta_window_appears_focused (frame->window))
...
2001-06-17 23:24:25 -04:00
flags |= META_FRAME_HAS_FOCUS;
if (frame->window->shaded)
flags |= META_FRAME_SHADED;
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 05:41:23 -05:00
if (frame->window->on_all_workspaces_requested)
...
2001-06-17 23:24:25 -04:00
flags |= META_FRAME_STUCK;
...
2001-06-18 02:11:53 -04:00
Merge of all the changes on the constraints_experiments branch. This is 2005-11-18 Elijah Newren <newren@gmail.com> Merge of all the changes on the constraints_experiments branch. This is just a summary, to get the full ChangeLog of those changes (approx. 2000 lines): cvs -q -z3 update -Pd -r constraints_experiments cvs -q -z3 diff -pu -r CONSTRAINTS_EXPERIMENTS_BRANCHPOINT ChangeLog Bugs fixed: unfiled - constraints.c is overly complicated[1] unfiled - constraints.c is not robust when all constraints cannot simultaneously be met (constraints need to be prioritized) unfiled - keep-titlebar-onscreen constraint is decoration unaware (since get_outermost_onscreen_positions() forgets to include decorations) unfiled - keyboard snap-moving and snap-resizing snap to hidden edges 109553 - gravity w/ simultaneous move & resize doesn't work 113601 - maximize vertical and horizontal should toggle and be constrained 122196 - windows show up under vertical panels 122670 - jerky/random resizing of window via keyboard[2] 124582 - keyboard and mouse snap-resizing and snap-moving erroneously moves the window multidimensionally 136307 - don't allow apps to resize themselves off the screen (*cough* filechooser *cough*) 142016, 143784 - windows should not span multiple xineramas unless placed there by the user 143145 - clamp new windows to screensize and force them onscreen, if they'll fit 144126 - Handle pathological strut lists sanely[3] 149867 - fixed aspect ratio windows are difficult to resize[4] 152898 - make screen edges consistent; allow easy slamming of windows into the left, right, and bottom edges of the screen too. 154706 - bouncing weirdness at screen edge with keyboard moving or resizing 156699 - avoid struts when placing windows, if possible (nasty a11y blocker) 302456 - dragging offscreen too restrictive 304857 - wireframe moving off the top of the screen is misleading 308521 - make uni-directional resizing easier with alt-middle-drag and prevent the occasional super annoying resize-the-wrong-side(s) behavior 312007 - snap-resize moves windows with a minimum size constraint 312104 - resizing the top of a window can cause the bottom to grow 319351 - don't instantly snap on mouse-move-snapping, remove braindeadedness of having order of releasing shift and releasing button press matter so much [1] fixed in my opinion, anyway. [2] Actually, it's not totally fixed--it's just annoying instead of almost completely unusable. Matthias had a suggestion that may fix the remainder of the problems (see http://tinyurl.com/bwzuu). [3] This bug was originally about not-quite-so-pathological cases but was left open for the worse cases. The code from the branch handles the remainder of the cases mentioned in this bug. [4] Actually, although it's far better there's still some minor issues left: a slight drift that's only noticeable after lots of resizing, and potential problems with partially onscreen constraints due to not clearing any fixed_directions flags (aspect ratio windows get resized in both directions and thus aren't fixed in one of them) New feature: 81704 - edge resistance for user move and resize operations; in particular 3 different kinds of resistance are implemented: Pixel-Distance: window movement is resisted when it aligns with an edge unless the movement is greater than a threshold number of pixels Timeout: window movement past an edge is prevented until a certain amount of time has elapsed during the operation since the first request to move it past that edge Keyboard-Buildup: when moving or resizing with the keyboard, once a window is aligned with a certain edge it cannot move past until the correct direction has been pressed enough times (e.g. 2 or 3 times) Major changes: - constraints.c has been rewritten; very few lines of code from the old version remain. There is a comment near the top of the function explaining the basics of how the new framework works. A more detailed explanation can be found in doc/how-constraints-works.txt - edge-resistance.[ch] are new files implementing edge-resistance. - boxes.[ch] are new files containing low-level error-prone functions used heavily in constraints.c and edge-resistance.c, among various places throughout the code. testboxes.c contains a thorough testsuite for the boxes.[ch] functions compiled into a program, testboxes. - meta_window_move_resize_internal() *must* be told the gravity of the associated operation (if it's just a move operation, the gravity will be ignored, but for resize and move+resize the correct value is needed) - the craziness of different values that meta_window_move_resize_internal() accepts has been documented in a large comment at the beginning of the function. It may be possible to clean this up some, but until then things will remain as they were before--caller beware. - screen and xinerama usable areas (i.e. places not covered by e.g. panels) are cached in the workspace now, as are the screen and xinerama edges. These get updated with the workarea in src/workspace.c:ensure_work_areas_validated()
2005-11-19 09:58:50 -05:00
/* FIXME: Should we have some kind of UI for windows that are just vertically
* maximized or just horizontally maximized?
*/
if (META_WINDOW_MAXIMIZED (frame->window))
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 02:07:21 -04:00
flags |= META_FRAME_MAXIMIZED;
theme: Add tiled_left/tiled_right frame states It may be desirable for theme authors to treat side-by-side tiled windows differently, for instance to give the edge-touching border a width of 0, so add additional frame states for tiled windows. https://bugzilla.gnome.org/show_bug.cgi?id=637330
2010-12-07 20:16:35 -05:00
if (META_WINDOW_TILED_LEFT (frame->window))
flags |= META_FRAME_TILED_LEFT;
if (META_WINDOW_TILED_RIGHT (frame->window))
flags |= META_FRAME_TILED_RIGHT;
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 02:07:21 -04:00
if (frame->window->fullscreen)
flags |= META_FRAME_FULLSCREEN;
...
2001-06-23 02:54:28 -04:00
Reinstated visual-bell patch, fix for bug 99886.
2003-01-28 10:07:43 -05:00
if (frame->is_flashing)
flags |= META_FRAME_IS_FLASHING;
Added "above" to the list of flags a frame can have, so that we know when * common.h: Added "above" to the list of flags a frame can have, so that we know when to mark it as always on top. Added six grab ops, one to do and one to undo each of the three new titlebar buttons (shade, above, stick). Added six new button functions, similarly. (#96229) * frame.c (meta_frame_get_flags): If a frame has the WM_STATE_ABOVE X attribute, set META_FRAME_ABOVE in its flags. * frames.c (meta_frames_apply_shapes): Allow variable amounts of rounding. (#113162) * frames.c (show_tip_now, meta_frames_paint_to_drawable, control_rect, get_control): extend handling of existing buttons to the 3*2 new kinds of button. (#96229) * frames.c (meta_frames_button_press_event): translate clicks on the 3*2 new kinds of button to the new grab ops. (#96229) * frames.c (meta_frames_button_release_event): implement the various actions for the 3*2 new kinds of button. (#96229) * frames.c (meta_frames_update_prelit_control, meta_frames_motion_notify_event): extend existing motion notifications for buttons to the 3*2 new kinds of button. (#96229) * frames.c (meta_frames_set_window_background): handle specified background colours and alpha transparency. (#151261) * frames.h (MetaFrameControl): New control types for the 3*2 new kinds of button. (#96229) * iconcache.[ch] (meta_read_icons): use theme's fallback icons if a window has no icon; use metacity's fallback icons only if the theme does not provide any. (#11363) * iconcache.[ch] (meta_invalidate_default_icons (new function)): clear icon cache on windows using default icons, and update them. (#11363) * main.c (main): added \n to error message. * prefs.c (button_function_from_string): extend for 3 new button types. (#96229) * prefs.c (button_opposite_function (new function)): return a button function's inverse (shade -> unshade, etc) (#96229) * prefs.c (update_button_layout): allocate space for a button's inverse, if it has one. (#96229) * theme-parser.c (ParseState): add state for fallback icons (#11363) * theme-parser.c (ParseInfo): add format_version; remove menu_icon_* (#114305) * theme-parser.c (parse_positive_integer): add lookup for integer constants (#331356) * theme-parser.c (parse_rounding (new function)): parse window rounding amount (#113162) * theme-parser.c (parse_alpha): don't set error if the number can't be parsed since it'll already be set; change tolerance in comparison from 1e6 to 1e-6 * theme-parser.c (parse_color (new function)): parse colour, including possible constant lookup. * theme-parser.c (parse_toplevel_element): allow defining of various new kinds of constant; allow hide_buttons (#121639) and more detailed rounding attributes on <frame_geometry> (#113162); allow background and alpha attributes on <frame_style>; (#151261) remove support for <menu_icon> except as stub; (#114305) add support for loading stock images (#113465); add support for <fallback>. (#11363)) * theme-parser.c (parse_draw_op_element): add from and to attribute for arcs. (#121603) * theme-parser.c (parse_style_element): add check for theme version supporting a button function. (#96229) * theme-parser.c (parse_style_set_element): add ability for shaded windows to be resizable (#114304) * theme-parser.c (meta_theme_load): add theme versioning routine. * theme.c ( meta_frame_layout_get_borders): return rectangles for the new 3*2 kinds of button, except where they're inapplicable. (#96229) * theme.c (meta_frame_layout_calc_geometry): don't format buttons on windows with no buttons (#121639); strip the 3*2 new kinds of button correctly (#96229); allow variable amounts of rounding (#113162). * theme.c (meta_frame_style_new): set alpha to 255 by default. (#151261) * theme.c (meta_frame_style_unref): free colour spec if allocated. (#151261) * theme.c (meta_frame_style_validate): it's only an error not to include a button if that button is valid in the current theme. (#96229) * theme.c (button_rect): return rectangles for the new 3*2 kinds of button. (#96229) * theme.c (meta_frame_style_set_unref): free differently resizable shaded styles. (#114304) * theme.c (get_style): look up differently resizable styles for shaded windows. (#114304) * theme.c (free_menu_ops (removed function), get_menu_icon (removed function), meta_theme_draw_menu_icon (removed function), meta_menu_icon_type_from_string (removed function), meta_menu_icon_type_to_string (removed function), meta_theme_free, meta_theme_validate): removed menu icon code. (#114305) * theme.c (meta_theme_load_image): add size_of_theme_icons parameter. (#113465) * theme.c (meta_theme_define_color_constant (new function), meta_theme_lookup_color_constant (new function)): allow definition of colour constants. (#129747) * theme.c (meta_button_type_from_string, meta_button_type_to_string): add the 3*2 new kinds of button. (#96229) * theme.c (meta_theme_earliest_version_with_button (new function)): return the theme version each button was introduced in. (#96229) * theme.h ( MetaFrameLayout): add "hide_buttons" flag (#121639) and corner radiuses. (#113162) * theme.h (MetaFrameGeometry): add rectangles for the 3*2 new buttons. (#96229) * theme.h (MetaButtonType): the 3*2 new buttons. (#96229) * theme.h (MetaFrameStyle): add window_background_color and window_background_alpha so that we can specify background on a <frame_style>. (#151261) * theme.h (MetaFrameStyleSet): shaded_styles gets resize dimension. (#114304) * theme.h (MetaTheme): added format_version, color_constants hash, (#129747) fallback_icon and fallback_mini_icon, (#11363) and removed menu_icons. (#114305) * theme.h (META_THEME_ALLOWS (new macro)): return whether a theme supports a given feature. Also, several macros representing new features in v2. * ui.c (meta_ui_set_current_theme)): also invalidate default icons. (#11363) * window.[ch] (meta_window_update_icon_now)): became non-static. (#11363)
2006-10-07 12:56:47 -04:00
if (frame->window->wm_state_above)
flags |= META_FRAME_ABOVE;
...
2001-06-18 02:11:53 -04:00
return flags;
...
2001-06-17 23:24:25 -04: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 00:59:12 -04: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 00:55:50 -04:00
self->visible.top = self->invisible.top = self->total.top = 0;
self->visible.bottom = self->invisible.bottom = self->total.bottom = 0;
self->visible.left = self->invisible.left = self->total.left = 0;
self->visible.right = self->invisible.right = self->total.right = 0;
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 00:59:12 -04:00
}
...
2001-06-17 23:24:25 -04: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 00:37:41 -04:00
meta_frame_calc_borders (MetaFrame *frame,
MetaFrameBorders *borders)
...
2001-06-17 23:24:25 -04: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-12 23:11:07 -04:00
/* Save on if statements and potential uninitialized values
* in callers -- if there's no frame, then zero the borders. */
if (frame == NULL)
meta_frame_borders_clear (borders);
else
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 17:37:50 -05:00
{
if (!frame->borders_cached)
{
meta_ui_get_frame_borders (frame->window->screen->ui,
frame->xwindow,
&frame->cached_borders);
frame->borders_cached = TRUE;
}
*borders = frame->cached_borders;
}
}
void
meta_frame_clear_cached_borders (MetaFrame *frame)
{
frame->borders_cached = FALSE;
...
2001-06-17 23:24:25 -04: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 15:36:12 -04:00
gboolean
...
2001-06-09 23:17:15 -04:00
meta_frame_sync_to_window (MetaFrame *frame,
cheesy client with static bit gravity, used to test the below change. 2002-01-19 Havoc Pennington <hp@pobox.com> * src/wm-tester/test-resizing.c: cheesy client with static bit gravity, used to test the below change. * src/window.c (meta_window_move_resize_internal): implement Owen's proposal for window resizing. http://mail.gnome.org/archives/wm-spec-list/1999-November/msg00088.html Currently you have to do METACITY_USE_STATIC_GRAVITY=1 in order to use it, because some GDK bug is screwing up exposes on my frames when it's enabled. * src/display.c (meta_display_create_x_cursor): fix glyph for NE/NW cursors * src/frames.c (get_control): add ability to resize from top * src/frame.c (meta_frame_get_flags): can't resize shaded windows (meta_frame_sync_to_window): add gravity arg * src/common.h (MetaWindowType): move here from window.h so it can be used in themes stuff. (MetaFrameFlags): remove META_FRAME_TRANSIENT since it overlaps with window type and was unused.
2002-01-19 18:59:11 -05:00
int resize_gravity,
...
2001-06-09 23:17:15 -04:00
gboolean need_move,
gboolean need_resize)
...
2001-06-02 21:33:27 -04:00
{
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 14:58:27 -05:00
meta_topic (META_DEBUG_GEOMETRY,
"Syncing frame geometry %d,%d %dx%d (SE: %d,%d)\n",
frame->rect.x, frame->rect.y,
frame->rect.width, frame->rect.height,
frame->rect.x + frame->rect.width,
frame->rect.y + frame->rect.height);
...
2001-06-09 23:17:15 -04:00
/* set bg to none to avoid flicker */
...
2001-06-17 23:24:25 -04:00
if (need_resize)
verbose-log on startup whether we were compiled with various extensions 2002-05-30 Havoc Pennington <hp@redhat.com> * src/main.c (main): verbose-log on startup whether we were compiled with various extensions * src/display.c (meta_display_queue_retheme_all_windows): reapply shape mask when changing themes, sucks to do it here though, makes theme changing slower. Needs fixing. * src/theme-parser.c (parse_toplevel_element): parse rounded corner options to frame_geometry * src/frames.c (meta_frames_apply_shapes): apply rounded corners if requested by the theme * configure.in (HAVE_SHAPE): check for shape extension
2002-05-30 20:02:54 -04:00
{
meta_ui_unflicker_frame_bg (frame->window->screen->ui,
frame->xwindow,
frame->rect.width,
frame->rect.height);
}
handle the client having a shape mask, fixes #101806 2003-01-05 Havoc Pennington <hp@pobox.com> * src/frames.c (meta_frames_apply_shapes): handle the client having a shape mask, fixes #101806 * src/core.c (meta_core_get_client_xwindow): new function * src/frame.c, src/frame.h: keep a flag for whether we need to update the frame shape * src/window.c (meta_window_new): select for ShapeNotify * src/display.h, src/display.c: actually query the shape extension, instead of just using it all over the place. * src/prefs.c (update_application_based): don't let people turn on application_based, as it just causes funky bugs. We can reenable the pref when/if it ever does something useful.
2003-01-05 02:51:02 -05:00
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 12:32:10 -04:00
meta_ui_move_resize_frame (frame->window->screen->ui,
frame->xwindow,
frame->rect.x,
frame->rect.y,
frame->rect.width,
frame->rect.height);
...
2001-06-03 17:39:57 -04:00
...
2001-06-17 23:24:25 -04:00
if (need_resize)
DefaultScreen() returns the screen number not Screen* 2002-05-09 Havoc Pennington <hp@redhat.com> * src/frames.c (show_tip_now): DefaultScreen() returns the screen number not Screen* * src/frame.c (meta_frame_sync_to_window): immediately repaint frame whenever we resize it, if we're inside a grab operation. * src/frames.c (meta_frames_repaint_frame): new function * src/window.c (meta_window_new): initialize window's colormap (meta_window_notify_focus): install the colormap for a window when it gets focus, uninstall on unfocus. * src/window.h (struct _MetaWindow): store window's colormap * src/display.c (event_callback): note changes to window colormap * src/frame.c (EVENT_MASK): add ColormapChangeMask
2002-05-09 18:34:00 -04:00
{
meta_ui_reset_frame_bg (frame->window->screen->ui,
frame->xwindow);
/* If we're interactively resizing the frame, repaint
* it immediately so we don't start to lag.
*/
if (frame->window->display->grab_window ==
frame->window)
meta_ui_repaint_frame (frame->window->screen->ui,
frame->xwindow);
}
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 15:36:12 -04:00
return need_resize;
}
cairo_region_t *
meta_frame_get_frame_bounds (MetaFrame *frame)
{
return meta_ui_get_frame_bounds (frame->window->screen->ui,
frame->xwindow,
frame->rect.width,
frame->rect.height);
...
2001-06-03 17:39:57 -04: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 13:00:15 -04:00
void
meta_frame_get_mask (MetaFrame *frame,
cairo_t *cr)
{
meta_ui_get_frame_mask (frame->window->screen->ui, frame->xwindow,
frame->rect.width, frame->rect.height, cr);
}
...
2001-06-02 21:33:27 -04:00
void
meta_frame_queue_draw (MetaFrame *frame)
{
...
2001-06-17 23:24:25 -04:00
meta_ui_queue_frame_draw (frame->window->screen->ui,
frame->xwindow);
...
2001-06-09 02:08:44 -04:00
}
Place cursors on frames, not root
2002-08-23 14:00:40 -04:00
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 12:32:10 -04:00
void
meta_frame_set_screen_cursor (MetaFrame *frame,
MetaCursor cursor)
Place cursors on frames, not root
2002-08-23 14:00:40 -04:00
{
Cursor xcursor;
if (cursor == frame->current_cursor)
return;
frame->current_cursor = cursor;
if (cursor == META_CURSOR_DEFAULT)
XUndefineCursor (frame->window->display->xdisplay, frame->xwindow);
else
{
xcursor = meta_display_create_x_cursor (frame->window->display, cursor);
XDefineCursor (frame->window->display->xdisplay, frame->xwindow, xcursor);
Flush after setting cursor. (Rest of #149413). Sun Aug 8 14:20:00 2004 Soeren Sandmann <sandmann@daimi.au.dk> * src/frame.c (meta_frame_set_screen_cursor): Flush after setting cursor. (Rest of #149413).
2004-08-08 08:23:34 -04:00
XFlush (frame->window->display->xdisplay);
Place cursors on frames, not root
2002-08-23 14:00:40 -04:00
XFreeCursor (frame->window->display->xdisplay, xcursor);
}
}
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-18 20:00:09 -04:00
Window
meta_frame_get_xwindow (MetaFrame *frame)
{
return frame->xwindow;
}
Reference in New Issue Copy Permalink