When we create the timeline dummy timeline to ensure that our later
functions that should be run during repaint get called called, pass in
G_MAXUINT to make the duration very long, not 0. (It will get reset
whenever there is no repaint later to run, so the fact that G_MAXUINT
is only ~40 days isn't a problem.)
This fixes a warning from Clutter, but also a real problem.
There was a problem where if, for example, a restack was triggered
out of a clutter event handler, then after Clutter processed the
events, it would proceed immmediately on to repaint the stage without
ever returning control to the GLib main loop. So even though we
had an idle handler installed with a higher priority than the
Clutter stage repainting the clutter stage repainting would happen
first and we'd get a wrong frame.
Fix this by introducing the idea of "later functions", which abstract
the idea of "doing something later" away from g_idle_add() and use
a combination of GLib idle functions and Clutter "repaint functions"
to get our callbacks triggered at the right time, even when they
are installed from a clutter event handler.
https://bugzilla.gnome.org/show_bug.cgi?id=596334
This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW
could starve stage repainting.
The return value of XGrabKeyboard() wasn't actually being assigned
to the 'result' variable so we didn't notice when grabbing the
keyboard failed.
https://bugzilla.gnome.org/show_bug.cgi?id=596343
We need a way to indicate to gnome-control-center that we want the
keybindings capplet to show the Window Manager keybindings for Metacity;
do this through a _GNOME_WM_KEYBINDING property we put on the
_NET_SUPPORTING_WM_CHECK window and set to Mutter,Metacity.
See http://bugzilla.gnome.org/show_bug.cgi?id=594066 for the
gnome-control-center part of this.
http://bugzilla.gnome.org/show_bug.cgi?id=594067
It seems a bit cleaner to make the MUTTER_DEBUG_XINERAMA variable
that sets up fake Xinerama take effect even if Xinerama is active;
this means we don't count on Xinerama (or Xrandr if we switch tot
that) special casing the case of one monitor.
http://bugzilla.gnome.org/show_bug.cgi?id=593404
Unminimize minimized windows passed to meta_workspace_activate_with_focus()
by calling meta_window_activate() on them instead of meta_window_focus()
and meta_window_raise(). This fix makes sense because for the existing
usage inside Mutter meta_workspace_activate_with_focus() is never called
on a minimized window and for calls from outside Mutter there is no
point in focusing a minimized window without unminimizing it first.
Add a doc comment to meta_workspace_activate_with_focus().
http://bugzilla.gnome.org/show_bug.cgi?id=592393
The changes to enforce single handling of all key events were breaking
custom-alt-tab keypress handlers, since that code was assuming that
key event would get to process_tab_grab(), and then maybe to
process_event() and then to the plugin's xevent_filter to detect a
key release.
We centeralize all of this handling into process_tab_grab() and either
- Invoke a custom handler for the key press
- Select the current window on modifier release by calling a new
pseudo-binding "tab_popup_select"
- Cancel the grab on an unbound key by calling a new pseudo-binding
"tab_popup_cancel"
http://bugzilla.gnome.org/show_bug.cgi?id=590754
mutter_plugin_begin_modal() and mutter_plugin_begin_modal() allow putting
a plugin into a "modal" state. This means:
- The plugin has the keyboard and mouse grabbed
- All keyboard and mouse events go exclusively to the plugin
mutter-plugin.[ch]: Add public API
compositor.c compositor-private.h: Implement the API
mutter-plugin-manager.c: When reloading plugins, make sure none of them
are modal at that moment, and if so force-unmodal them.
common.h: Add META_GRAB_OP_COMPOSITOR
display: When display->grab_op is META_GRAB_OP_COMPOSITOR forward relevant
events exclusively to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=590754
Only process each key event once. If all keys are grabbed, then
don't also look for handlers for a key shortcut after processing
the grab op. If all keys are grabbed or we find a key shortcut,
don't pass the event on to the compositing mananger.
http://bugzilla.gnome.org/show_bug.cgi?id=590754
The previous notification code was attempting to use the "modified"
boolean returned from set_title_text, but "that boolean doesn't mean
what you think it means". It actually means "I truncated the title".
Just always notify, it's far simpler than trying to compute
when we don't need to, and callers can compress if they really need
to.
mutter-window.c originally grew an #include "window-private.h" for
window->override_redirect, but that was just fixed. However since
then it also ended up relying on a few other minor private bits.
To fix that, add meta_window_is_mapped, promote meta_window_toplevel_is_mapped
to public, and use the public MetaDisplay accessor.
The functionality to propagate errors for other displays to other
a "foreign error handler" was Soeren's compositor and is no longer
being used. Remove it.
(Now that error.h is being installed and scanned, we need to either
do this or add XErrorEvent to xlib-2.0.gir and rename ErrorHandler
to MetaErrorHandler. This way is a bit simpler.)
When we first start up, we do not want to run effects on any pre-exising
windows (this is either the case we are starting up and there are no windows,
or we are replacing an exisint window manager, or worse, we crashed, and we
just want to get to the desired desktop as quick as possible).
Dithered about where to place the check; putting into the plugin manager
reduces the number of places (and files) in which it needs to be done.
It's useful for plugins to be able to get access to the
startup-notification data that Mutter already has. Add
an accessor and change signal when recieve an event.
When window initially maps, use the more recent of NET_WM_USER_TIME and
startup notification timestamps to compare against last known user action to
decide whether to focus the window or not. Once we show the window, clear
the initial_timestamp_set flag, so the startup notification timestamp is not
taken into account again.
Based on patch for metacity by Alexander Larsson
http://bugzilla.gnome.org/show_bug.cgi?id=573922
We store a pointer to the texture independently of the ClutterContainer
internals, and rely on the pointer remaining valid until we run dispose.
Since we also provide public API to access this pointer, we should not
rely on the reference ClutterContainer holds to ensure that texture will
not be destroyed (e.g., some nasty developer could reparent the texture).
We were freeing the description string in dispose and not setting it to NULL,
thus leaving around a dangling pointer for the duration of the disposal.
This commit moves the free into the finalize vfuction, where it belongs.
Many override-redirect windows (including the Metacity UI windows!)
will have NET_WM_WINDOW_TYPE_NORMAL set on them because of shared
code paths with normal windows in toolkits.
Some current Compositor plugins (default plugin and gnome-shell)
check type == NORMAL to determine if to run effects. While fixing
such plugins to also check if the window is override-redirect is
posisble, it seems cleanest to simply not allow any of the decorated
window types to be set on an override-redirect window and to force
these types to META_WINDOW_OVERRIDE_OTHER. This will prevent other
similar problems from showing up in the future.
http://bugzilla.gnome.org/show_bug.cgi?id=590971
When calculating maximum permissible size of our frame window, we need to
avoid an overflow if the application set its max size hint to INT_MAX.
http://bugzilla.gnome.org/show_bug.cgi?id=590627
As a sideffect of commit a576f7a1ea, override
redirect windows of type _NET_WM_WINDOW_TYPE_NORMAL do not have their
features recalculated during MetaWindow construction (same as regular
windows of type _NET_WM_WINDOW_TYPE_NORMAL), so we need to set the initial
values accordingly.
Although the spec designates some window types as typically used for
override redirect windows, it does not prohibit the use of these with
managed windows, so we should not abort if we encounter one of these.
http://bugzilla.gnome.org/show_bug.cgi?id=583870
As with other events, we want to pass through scroll events (button 4/5 presses)
to the compositor, whether or not they are associated with a particular MetaWindow;
do this by simply falling through to the normal code path instead of
separately delivering the events to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=588232
Setting the size of the texture causes the minimum and preferred width and
height values to be fixed at the set value. The normal requisition functions
of ClutterTexture will already report the size of the texture pixmap as the
natural size, but also allow scaling down as needed if less space is
available. We don't need that here, but we want to allow someone to make
a ClutterClone of the texture actor.
With recent changes, Clutter no longer sets up the viewport correctly,
unless it receives ConfigureNotify events. If there is a plugin with
an xevent_filter function, then it's that plugins responsibility to pass
the event to Clutter if it doesn't want it. If there is no plugin,
or the plugin doesn't have an xevent_filter function, then we should
call clutter_x11_handle_event() ourselves.
http://bugzilla.gnome.org/show_bug.cgi?id=589419
When a windows contents or shape changes, we schedule a redraw
with clutter_actor_queue_redraw(); we need to queue the redraw
on the shaped texture rather than on the window actor to support
cloning of just the shaped texture without the shadow: that
is, the shaped is what is really changing and it may be
visible via a clone even if the MutterWindow itself is not
visible.
http://bugzilla.gnome.org/show_bug.cgi?id=589429
MetaPreview is only built into libmutter-private, and not included in
the mutter executable. Linking mutter against libmutter-private was
inadvertently added when the introspection build process was set up,
but isn't actually needed, and if -Wl,-as-needed is added during the
build process, then the libmutter-private dependency will be skipped.
* Don't link mutter (or the test programs) against libmutter-private
* Exclude meta-preview.h from the set of headers we feed into the
introspection build process
Reported by Patryk Zawadzki
http://bugzilla.gnome.org/show_bug.cgi?id=587975
* Make generation of the .gir file work for srcdir != builddir
* Add files to CLEANFILES as needed
* Don't distribute the generated file mutter.schemas
When we are painting a stack of 5-10 maximized windows, the
standard bottom-to-top method of drawing every actor results
in a tremendous amount of overdraw and can easily max out
the available memory bandwidth on a low-end* graphics chipset.
It's even worse if window textures are being accessed over
the AGP bus.
When we have opaque windows, we can go ahead and compute visibility
ourselves (in classic X-server fashion) and use that information to
restrict drawing obscured actors.
* Add MutterWindowGroup - a ClutterGroup subclass with logic
for figuring out obscured regions.
* Add mutter_window_get_obscured_region() to get the region
obscured by that window.
* Add mutter_shaped_texture_set_clip_region() to hint
a clip region to the painting code; this is set based on
the computed visible region of MutterWindowGroup.
* Add tidy_texture_frame_set_needs_paint() to hint that the
paint can be skipped entirely; this is used when we detect
that the window shadow is entirely obscured.
http://bugzilla.gnome.org/show_bug.cgi?id=587344
If we are starting on something other than the first workspace,
meta_compositor_switch_workspace() will be called before
meta_compositor_manage_screen(); guard against that.
Previously, changes to the visibility of a window could be indicated
by meta_compositor_map_window(), meta_compositor_unminimize_window(),
meta_compositor_set_window_hidden(), etc, with the exact behavior
depending on the 'live_hidden_windows' preference.
Simplify this so that visibility is controlled by:
meta_compositor_show_window()
meta_compositor_hide_window()
With an 'effect' parameter provided to indicate the appropriate
effect (CREATE/UNMINIMIZE/MINIMIZE/DESTROY/NONE.)
The map state of the window is signalled separately by:
meta_compositor_map_window()
meta_compositor_unmap_window()
And is used only to control resource handling.
Other changes:
* The desired effect on show/hide is explicitly stored in
MetaWindow, avoiding the need for the was_minimized flag.
At idle, once we calculate the window state, we pass the
effect to the compositor if it matches the new window
state, and then clear the effect to start over for future
map state changes.
* meta_compositor_switch_workspace() is called before any windows
are hidden or shown, allowing the compositor to avoid hiding
or showing an effect for windows involved in the switch.
http://bugzilla.gnome.org/show_bug.cgi?id=582341
* Handling of post-effect cleanups for MutterWindow are
simplified - instead of trying to do different things based
on the individual needs of different effects, we just wait until
all effects complete and sync the window state to what it
should be.
* On unmap, once we destroy the pixmap, we tell ClutterX11Pixmap
that we've done so, so it can clean up and unbind. (The
unbinding doesn't seem to be working properly because of
ClutterGLXPixmap or video driver issues.)
http://bugzilla.gnome.org/show_bug.cgi?id=587251
Clean up mutter_window_effect_in_progress() by removing the
include_destroy parameter which was used only in one place that
could be easily done otherwise. (There was another use in
mutter_window_sync_actor_position() that had no point and looked
unintended.)
http://bugzilla.gnome.org/show_bug.cgi?id=587251
Add a paint function that checks all windows for repair and
shape updates; this:
- simplifies the logic for when a window needs to be repaired
- avoids duplicate work when we get multiple damage effects
- avoids the need to look ahead in the event queue
Instead of relying on repair to implicitly resize the
MutterWindow actor, set the size explicitly when the core
code updates the geometry. (This is needed because we haven't
repaired yet when we start an animation, and the animation
may depend on the size to, e.g., rescale from the center.)
Because the core geometry update happens before we start
maximize/unmaximize effects we need to work around this by
passing both the old and new geometry to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=587251
Putting hidden windows in the desktop layer is pointless - in
the desktop layer isn't necessary below all visible windows,
and we are hiding the windows by other means. And the movement
isn't reliable because nothing sets stack->needs_relayer, so
windows can get stuck in the desktop layer after being
rehidden.
http://bugzilla.gnome.org/show_bug.cgi?id=587251
compositor.c: Move MutterWindow code to mutter-window.c;
rename map_win() to mutter_window_map(), etc.
mutter-window-private.h: New private header file for
MutterWindow functions used internally to the compositor.
compositor-mutter.h: Move MutterWindow declarations to
mutter-window.h; move a couple of private functions to
compositor-private.h
compositor-private.h: Move MetaCompScreen declaration to here:
Conceptually it's private to compositor.c, but MutterWindow
manipulates some of the lists directly for now.
mutter-plugin.c compositor.c: Don't call mutter_window_effect_completed()
for MUTTER_PLUGIN_SWITCH_WORKSPACE, but use a new
mutter_switch_workspace_completed(), since the window is
just used to identify a screen.
http://bugzilla.gnome.org/show_bug.cgi?id=587251
Separate code related to creating the gaussian-blurred shadow texture
into a separate file.
Move the definition of MetaCompositor into a compositor-private.h
so that the shadow code can cache the source in the compositor
structure.
http://bugzilla.gnome.org/show_bug.cgi?id=587251
The patch adds GLib marshalling code to Mutter, since it's required for the "workspace-switched" signal.
The definition of MetaMotionDirection enum is moved to common.h since it's now used in workspace.c.
A little cleaning is done in workspace.c:meta_workspace_activate_with_focus(), where compositor-specific code is merged with the rest of the function (required to emit signal), removing #ifdefs.
Remove a number of functions that were either entirely unimplemented
or had empty implementations for the Clutter-compositor.
meta_compositor_begin_move()
meta_compositor_update_move()
meta_compositor_end_move()
meta_compositor_set_active_window()
meta_compositor_free_window()
http://bugzilla.gnome.org/show_bug.cgi?id=581813
Now that we only have one compositor, there's no reason to access the
compositor functions through a vtable. Remove the MetaCompositor virtualization
and make the clutter code implement the meta_compositor_* functions
directly.
Move the checks for the compositor being NULL from the vtable wrappers
to the calling code (most of them were already there, so just a few
needed to be added)
Note: the compositor is actually hard-coded on at the moment and the plan
is to remove the non-composited code entirely, so the checks are
added only to keep things neat: they have no practical effect.
http://bugzilla.gnome.org/show_bug.cgi?id=581813
Mutter is a Clutter-based compositing manager. So, remove the code for
the XRender-based compositor, and make it mandatory to have XComposite,
XRender and Clutter.
Run-time support for non-composited operation is left for now.
* src/compositor/mutter/: Move files from this subdirectory into
the main compositor/ directory.
* compositor/compositor-xrender.ccompositor/compositor-xrender.h:
Remove
* include/compositor-clutter.h: Remove this stray file, it had been
replaced with compositor-mutter.h some time back.
http://bugzilla.gnome.org/show_bug.cgi?id=581813
Since the stack passed to the compositor now accurately reflects
the X stacking order, we need to treat hidden windows (which are
at the bottom of the X stacking order) specially - when the
compositor stacking order is synced, try to keep animating hidden
actors in their old positions in the stack.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
With MetaStackTracker, it's no longer necessary to XQueryTree to
get a reasonably-up-to-date view of the server stacking order.
Add some comments explaining unclear aspects of
raise_window_relative_to_managed_windows() and with future possible
improvements.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
Don't add override-redirect windows to MetaStack; we shouldn't
be restacking them.
Since we *aren't* stacking the override-redirect windows, we need to
be careful that to ignore them when looking for the top managed
window.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
In order to properly track the stacking order for override-redirect
windows, move meta_compositor_sync_stack() call into MetaStackTracker.
In the new location, we sync the stack as a before-redraw idle function,
rather then using the freeze-thaw facilities of MetaStack. This is
simpler, and also properly compresses multiple stack changes on
notifications received from the X server.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
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
Override-redirect windows should not be moved or resized by the
window manager.
- Mark override-redirect windows as already placed to avoid
placing them when first shown.
- Don't move-resize newly created override-redirect MetaWindow
- Don't queue a resize on override-redirect windows when reading
their WM_TRANSIENT_FOR hint.
- Add g_return_if_fail (!window->override_redirect) to catch
unexpected code paths that might result in override-redirect
windows being moved or resized.
http://bugzilla.gnome.org/show_bug.cgi?id=582639
Normally a window that is "on all workspaces", is also on a particular
workspace (to deal with being unstuck.) This is pointless for
override-redirect windows.
http://bugzilla.gnome.org/show_bug.cgi?id=582639
Don't include override-redirect windows when iterating the windows
in the screen. We don't need them for any of the current uses:
- Queueing redraws and resizes on managed windows
- Checking which windows should be added to a new workspace
http://bugzilla.gnome.org/show_bug.cgi?id=582639
Don't include override-redirect windows in the list return by
meta_display_list_windows(), since we almost never want to handle
them when considering "all window" for the display. Add a separate
meta_display_list_all_windows() that includes override-redirect
windows.
http://bugzilla.gnome.org/show_bug.cgi?id=582639
