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
