Commit Graph

26 Commits

Author SHA1 Message Date
Cosimo Cecchi
cd84317346 compositor: add support for unminimize compositor effects
https://bugzilla.gnome.org/show_bug.cgi?id=733789
2014-07-26 17:26:40 +02:00
Florian Müllner
b64548ee1f Pass button_rect when opening window menu from button
When opening the window menu without an associated control - e.g.
by right-clicking the titlebar or by keyboard - using coordinates
for the menu position is appropriate. However when the menu is
associated with a window button, the expected behavior in the
shell can be implemented much easier with the full button geometry:
the menu will point to the center of the button's bottom edge
rather than align to the left/right side of the titlebar as it
does now, and the clickable area where a release event does not
dismiss the menu will match the actual clickable area in mutter.

So add an additional show_window_menu_for_rect() function and
use it when opening the menu from a button.

https://bugzilla.gnome.org/show_bug.cgi?id=731058
2014-06-02 23:49:48 +02:00
Florian Müllner
31db32e826 Actually implement opening the app menu
The last commit added support for the "appmenu" button in decorations,
but didn't actually implement it. Add a new MetaWindowMenuType parameter
to the show_window_menu () functions and use it to ask the compositor
to display the app menu when the new button is activated.

https://bugzilla.gnome.org/show_bug.cgi?id=730752
2014-05-27 19:40:06 +02:00
Jasper St. Pierre
6513cbb470 Add back coordinates to the window menu
It looks weird to have Alt+Space pop up under the cursor instead
of the top-left corner of the window, and the Wayland request will
pass through the coordinates as well.

Add it to the compositor interface, and extend the
_GTK_SHOW_WINDOW_MENU ClientMessage to support it as well.
2014-05-22 10:50:57 -04:00
Jasper St. Pierre
8640982e68 Convert window menus to a compositor implementation 2014-05-17 15:16:23 -04:00
Jasper St. Pierre
cd905a34fb compositor: Kill off MetaCompScreen
Compositors haven't been able to manage more than one screen for
quite a while. Merge MetaCompScreen into MetaCompositor, and update
the API to match.

We still keep MetaScreen in the public compositor API for compatibility
purposes.
2014-03-26 12:04:48 -04:00
Jasper St. Pierre
4fdbb466e1 meta-plugin: Remove some unused features
And don't use properties for no reason.
2014-03-18 18:25:31 -04:00
Stefano Facchini
4de3f7ca29 Make tile preview a compositor plugin effect
https://bugzilla.gnome.org/show_bug.cgi?id=665758
2014-02-19 21:55:35 +01:00
Andika Triwidada
9b21346427 Changed obsolete FSF postal address into generic URL.
Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-13 11:35:47 -05:00
Giovanni Campagna
004ee2d3b5 MetaPluginManager: don't require plugins to pass events to clutter
We don't want the shell to know if it's running on ClutterX11 or
not, so we should forward the event ourselves.

https://bugzilla.gnome.org/show_bug.cgi?id=707482
2013-09-10 17:26:15 +02:00
Giovanni Campagna
aa15c09d54 Merge tag 'xrandr_branch_point' into wayland-kms-base
Conflicts:
	src/Makefile.am
	src/core/display.c
	src/core/screen-private.h
	src/core/screen.c
2013-08-27 10:07:39 +02:00
Giovanni Campagna
5086626805 MetaPlugin: add a UI hook for confirming display changes
We want to show a dialog when a display change happens from the
control center. To do so, add a new vfunc to MetaPlugin and
call it when a configuration change is requested via DBus.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-18 00:47:53 +02:00
Robert Bragg
f9a11b3b18 wayland: Adds basic hybrid X + Wayland support
This adds support for running mutter as a hybrid X and Wayland
compositor. It runs a headless XWayland server for X applications
that presents wayland surfaces back to mutter which mutter can then
composite.

This aims to not break Mutter's existing support for the traditional X
compositing model which means a single build of Mutter can be
distributed supporting the traditional model and the new Wayland based
compositing model.

TODO: although building with --disable-wayland has at least been tested,
I still haven't actually verified that running as a traditional
compositor isn't broken currently.

Note: At this point no input is supported

Note: multiple authors have contributed to this patch:
Authored-by: Robert Bragg <robert@linux.intel.com>
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Rico Tzschichholz.
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
2013-08-10 19:13:48 -04:00
Jasper St. Pierre
9596c24f83 plugin-manager: Remove a bogus check
We dereference the plugin_mgr in the initializer above,
so it's wrong.

https://bugzilla.gnome.org/show_bug.cgi?id=690609
2013-01-09 14:06:24 -05:00
Florian Müllner
424fc5245a Add compositor hook to process keybindings selectively
Currently keybindings are blocked while the compositor holds a grab; if
we want a keybinding to be available anyway, we use captured ClutterEvents
to determine the KeyBindingAction the event would have triggered and
run our own handlers (ugh).
Instead, provide a hook to allow the compositor to filter out keybindings
before processing them normally, regardless of whether the compositor
holds a grab or not.

https://bugzilla.gnome.org/show_bug.cgi?id=688202
2012-11-17 01:47:05 +01:00
Owen W. Taylor
f258556cec MetaPluginManager: don't send events to Clutter twice
When support for multiple plugins was removed, the logic that was
supposed to send events to Clutter directly *only if there is no filter
function from a plugin* was broken, so events were being sent to
Clutter twice if Clutter didn't consume them the first time.

https://bugzilla.gnome.org/show_bug.cgi?id=686406
2012-11-03 19:36:41 -04:00
Jasper St. Pierre
f5e48223c9 meta-plugin-manager: Guard against a NULL start vfunc
The default plugin has no such vfunc.

https://bugzilla.gnome.org/show_bug.cgi?id=678238
2012-06-25 13:52:47 -04:00
Jasper St. Pierre
f9454e29db meta-plugin-manager: Only allow one plugin to be loaded
The "multiple plugins loaded at once" strategy was always a big fiction:
while it may be viable if you're super careful, it's fragile and requires
a bit of infrastructure that we would be better off without.

Note that for simplicity, we're keeping the MetaPluginManager, but it only
manages one plugin. A possible future cleanup would be to remove it entirely.

https://bugzilla.gnome.org/show_bug.cgi?id=676855
2012-06-05 13:28:23 -04:00
Jasper St. Pierre
574c0c3287 meta-plugin: Remove "disabled" feature
It's just code cruft that nobody's using

https://bugzilla.gnome.org/show_bug.cgi?id=676855
2012-06-05 13:28:23 -04:00
Jasper St. Pierre
9fa5aa9889 meta-plugin: Kill off "features"
We already check that the plugin has the appropriate vfunc in the klass
structure, so we shouldn't need to check for the same data again with
a "features" long.

https://bugzilla.gnome.org/show_bug.cgi?id=676855
2012-06-05 13:28:23 -04:00
Dan Winship
c84da3ce1b 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-07 18:19:53 -05:00
Dan Winship
bb50f65532 Allow mutter to be used as a library
Move all of the mutter code into a new libmutter-wm.so, split its
main() method into meta_get_option_context(), meta_init() and
meta_run(), add methods for using in-process plugins, and add
libmutter-wm.pc pointing to the new library.

The mutter binary is now just a tiny program that links against
libmutter-wm. The --version and --mutter-plugins options are handled
at the mutter level, not in libmutter-wm, and a few strange unused
command-line options (--no-force-fullscreen and --no-tab-popup) have
been removed.

https://bugzilla.gnome.org/show_bug.cgi?id=643959
2011-03-07 18:19:53 -05:00
Dan Winship
4c76791d4c Remove some unused plugin functionality
Revert the early_initialize changes (which get in the way in the
"libmutter-wm" paradigm), remove the GConf key for setting plugins,
and remove plugin "params", which weren't being used. Also remove all
the logic for unloading and reloading plugins, since the list never
changes after startup now.

https://bugzilla.gnome.org/show_bug.cgi?id=643959
2011-03-07 10:01:37 -05:00
Colin Walters
f2158218be plugins: Add early_initialize vfunc
For GNOME Shell, we need to grab our DBus names *before* we talk XSMP.
gnome-session takes our XSMP connection as "I'm ready", and starts
running all the other random crud that people dropped in as autostart
files.  But for example, we need to have claimed
org.freedesktop.Notifications before a lot of said crud starts.

This requires a plugin API version bump.

Misc: Move handling of --version way earlier in main() where
it should be; no point having it wedged after plugin handling.
2011-02-25 14:38:04 -05:00
Colin Walters
1133a4ff9c Make plugin loading failure fatal
If a plugin was explicitly specified, falling back to the default
silently is bad; a manager component like gnome-session can
do a better job of handling this scenario.

An example we've hit in gnome-shell is where SpiderMonkey changes
without gjs being rebuilt, and loading the plugin fails due to
unresolved symbols.

But there are obviously others, like the file being missing or
corrupt.

https://bugzilla.gnome.org/show_bug.cgi?id=641384
2011-02-03 14:23:03 -05:00
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