Commit Graph

11 Commits

Author SHA1 Message Date
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
75f3ae14b5 MetaPlugin: simplify the modal API
Remove grab window and cursor from the API, and just grab always
on the stage window with no cursor.
This is mainly to remove the X11 usage in the public API, in preparation
for implementing this in wayland.

https://bugzilla.gnome.org/show_bug.cgi?id=705917
2013-08-20 14:25:49 +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
Tomeu Vizoso
e0b698d365 Fix gobs of gtk-doc warnings
https://bugzilla.gnome.org/show_bug.cgi?id=676856
2013-03-14 18:02:43 -04: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
Evan Broder
99cbe762d7 Expose MetaPlugin to introspection
Add a type annotation on the xevent_filter vfunc. This is sufficient
to remove the skip annotation on MetaPlugin and MetaPluginClass
without triggering scan errors.

https://bugzilla.gnome.org/show_bug.cgi?id=671098
2012-10-08 17:05:11 -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
Jasper St. Pierre
5e3d93da87 plugin: Remove unneeded wrapper APIs
Mutter originally started out with the idea that only a subset of the total
API was exposed to plugins, so some APIs are duplicated on MutterPlugin.
We've long since abandoned that idea; remove these wrappers.

https://bugzilla.gnome.org/show_bug.cgi?id=671103
2012-03-08 16:52:44 -05: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