1
0
Fork 0
Commit graph

8 commits

Author SHA1 Message Date
Owen W. Taylor
1920f211b0 Remove Mutter namespace prefix
Move all objects and functions namespaced with Mutter into the Meta namespace
to get a single consistent namespace. Changes that aren't simply changing mutter
to meta:

 MutterWindow              => MetaWindowActor
 mutter_get_windows        => meta_get_window_actors
 mutter_plugin_get_windows => meta_plugin_get_window_actors

https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-23 15:48:29 -04:00
Maxim Ermilov
13ad103823 Clean up MutterPlugin effect interface
The current effect API passes an unnecessary list of windows to
switch_workspace() and forces a window to be passed in when killing
the switch_workspace() effect.

We can simplify the interface to correspond more closely to how
it is actually used and fix these problems:

Remove the actors parameter to plugin->switch_workspace
Remove the events parameter to plugin->kill_effect and rename it to kill_window_effects
Add plugin->kill_switch_workspace

Remove mutter_plugin_manager_kill_effect
Add mutter_plugin_manager_kill_window_effects
Add mutter_plugin_manager_kill_switch_workspace

Remove mutter_plugin_effect_completed
Add mutter_plugin_[minimize/map/destroy/maximize/unmaximize]_completed
https://bugzilla.gnome.org/show_bug.cgi?id=621082
2010-06-17 01:40:43 +04:00
Owen W. Taylor
b77b0a3d81 Load one copy of plugins early
Although multi-screen support has not been tested and probably
doesn't fully work, the basic setup for multi-screen is that
we have the same list of plugins for all screens, but a different
instance of the plugins for each screen.

To allow plugins to do setup that is screen independent and needs
to occur early in the setup process, we identify a "default plugin
manager" and load (but not start) that plugin manager's plugins
immediately after we know our list of plugins.

That plugin manager is then reused for the first screen we open
and the plugins are started at that time. Separate plugin managers
are loaded and started for any other screens we open.

(A plugin could keep track of whether the screen-independent
setup has been done in a static variable, or it could do everything
in a way that is safe to do repeatedly.)

https://bugzilla.gnome.org/show_bug.cgi?id=615586
2010-04-13 13:53:55 -04:00
Owen W. Taylor
97a9726845 Add an explicit start() method for plugins
Rather than using the plugin objects constructed() method for doing
setup that requires the MetaScreen, add an explicit start() method
that is called after the screen is set.

The reason for this is that this allows plugin objects to be created
early before the bulk of Metacity setup, which then allows plugins
to affect how the setup happens. (For example, to change the way
that preferences are loaded.)

This is an incompatible change, since 'screen' is now not set in the
constructed method, so the plugin API version is bumped.

https://bugzilla.gnome.org/show_bug.cgi?id=615586
2010-04-13 13:40:16 -04:00
Owen W. Taylor
67682a2683 Add a modal mode for plugins
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
2009-08-26 12:26:58 -04:00
Tomas Frydrych
2c8df7d12e Do not run effects during WM startup
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.
2009-08-12 07:45:03 +01:00
Owen W. Taylor
d91d503eb2 Pass event to clutter when the plugin doesn't have xevent_filter
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
2009-07-28 16:00:24 -04:00
Jon Nettleton
0b8a57bcba There can be only one compositor engine
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
2009-06-30 09:34:03 -04:00
Renamed from src/compositor/mutter/mutter-plugin-manager.c (Browse further)