As calling XIGrabDevice multiple times will change it, just
drop the XChangeActivePointerGrab path and just go down the
XIGrabPointer path always.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
It's unlikely that we'll ever want to support multiple pointer
devices. Multiple keyboard devices may become useful in the future,
but for now, only care about the core keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
Mechanically transform the event processing of mutter to care
about XI2 events instead of Core Events. Core Events will be left
in the dust soon, and removed entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
This removes some duplicate event type checks, and will make
the code cleaner in the future when we want to make the grab_op_event
handler take an XIDeviceEvent directly.
Based on a patch by Owen Taylor <otaylor@fishsoup.net>
https://bugzilla.gnome.org/show_bug.cgi?id=688779
In order to make the XI2 handling easier on us in the future, we now
split input events from non-input events. This will allow one code path
to use XIEvent, and the other to use XEvent in the future. This commit
has involved plenty of indenting changes, so it's better seen with
git diff -b or &ignorews=1
https://bugzilla.gnome.org/show_bug.cgi?id=688779
Currently meta_display_get_tab_list() will only return windows on
a single workspace. Make the workspace parameter optional to allow
requesting windows from all workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
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
The X server sends a XkbNewKeyboardNotify event for each keyboard
device when a new keyboard description is loaded. These days a typical
computer has several keyboard devices, e.g. xinput on this laptop
lists 8. Since the work we do on these events is relatively expensive
and we are only really interested in changes to the virtual core
keyboard we can skip other devices' events to cut on needless work.
https://bugzilla.gnome.org/show_bug.cgi?id=674859
Moving focus immediately on crossing events as we currently do
in focus-follows-mouse mode may trigger a lot of unwanted focus
changes when moving over unrelated windows on the way to a target.
Those accidental focus changes prevent features like GNOME Shell's
application menu from working properly and are visually expensive
since we now use a very distinct style for unfocused windows.
Instead, delay the actual focus change until the pointer has stopped
moving.
https://bugzilla.gnome.org/show_bug.cgi?id=678169
As plugins can now define their own keyboard shortcuts via
meta_display_add_keybinding(), it makes sense for them to
expose those shortcuts to System Settings, so add some API
to set the properties gnome-control-center uses to pick up
wm keybinding settings.
https://bugzilla.gnome.org/show_bug.cgi?id=671010
We may not show the backtrace, but it's prohibitly expensive to generate,
so don't. If someone wants a backtrace they can use the appropriate G_DEBUG
environment variable plus GDB.
https://bugzilla.gnome.org/show_bug.cgi?id=676855
==31043== 7 bytes in 1 blocks are definitely lost in loss record 213 of 6,861
==31043== at 0x402B018: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==31043== by 0x417789A: ??? (in /usr/lib/libglib-2.0.so.0.3122.0)
==31043== by 0x4177C42: g_malloc (in /usr/lib/libglib-2.0.so.0.3122.0)
==31043== by 0x418DC3A: g_strdup (in /usr/lib/libglib-2.0.so.0.3122.0)
==31043== by 0x408C470: meta_display_open (display.c:475)
==31043== by 0x40A4D42: meta_run (main.c:552)
==31043== by 0x8048A74: main (mutter.c:96)
https://bugzilla.gnome.org/show_bug.cgi?id=672640
Require the headers for "XFree86" Xinerama to be present at compile
time. The older "Solaris" Xinerama is only needed for versions of
Solaris where Mutter is unlikely to work. Solaris 10 and 11 include
the XFree86 Xinerama libraries, and apparently that's the only version
that will actually work for Solaris 11, which uses Xorg.
https://bugzilla.gnome.org/show_bug.cgi?id=674727
Currently pressing the overlay key only triggers the overview if
no other key is pressed between KeyPress and KeyRelease. Extend
this logic to pointer events, so that KeyPress + ButtonPress actions
are treated explicitly different from "pure" overlay key presses.
In particular, this change allows to re-use the overlay key as mouse
button modifier.
https://bugzilla.gnome.org/show_bug.cgi?id=662476
This is a new value, not associated with any keybindings, useful
when the WM needs to order the applications by last-interaction,
taking into account all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=667552
Some modifiers like NumLock and ScrollLock don't make sense in
keybindings, which is why we ignore them when matching keybindings
to events. We should do the same in Javascript, so add an accessor
function.
https://bugzilla.gnome.org/show_bug.cgi?id=665215
When meta_display_unmanage_window_for_screen() is called, it gets a list
of windows and iterates over them and unmanages them, but unmanaging a
window with attached modal dialogs also unmanages those attached modal
dialogs (in the normal case, temporarily), so we need to guard against
such cases by ref'ing the windows in the list and checking if they have
already been unmanaged.
https://bugzilla.gnome.org/show_bug.cgi?id=668299https://bugzilla.redhat.com/show_bug.cgi?id=760918
Move preferences to GSettings, using mainly shared schemas from
gsettings-desktop-schemas.
Unlike GConf, GSettings support is not optional, as Gio is already
a hard dependency of GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=635378
meta_window_get_current_tile_area() computes the area where the tiled window
should be based on the current pointer position but that's only meaningful
when the user is actually dragging the window.
When running the tiling constrain the pointer might be on other monitor and at
that point the window jumps to this other monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=642580
The ignored_serials member of Display refers explicitly to crossing
serials - rename the member and associated functions and constants
for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=597190
* Export meta_display_add_ignored_crossing_serial()
* Add the serial for reshaping the stage
* Increase the size of the "ignored_serials" array a bit to
try to avoid the possibility of losing serials from multiple
reshapes happening close together.
https://bugzilla.gnome.org/show_bug.cgi?id=597190
Different bits of code were using slightly different checks to test
whether a window was an attached dialog. Add a new
meta_window_is_attached_dialog(), and use that everywhere.
Also, freeze the is-attached status when the window is first shown,
rather than recomputing it each time the caller asks, since this could
cause problems if a window changes its type after it has already been
attached, etc. However, if an attached window's parent is destroyed,
or an attached window changes its transient-for, then fix things up by
destroying the old MetaWindow and creating a new one (causing
compositor unmap and map events to be fired off, allowing the display
of the window to be fixed up).
Remove some code in display.c that tried to fix existing windows if
the gconf setting changed, but which didn't actually do anything (at
least under gnome-shell). However, if 654643 was fixed then the new
behavior with this patch would be that changing the gconf setting
would affect new dialogs, but not existing ones.
https://bugzilla.gnome.org/show_bug.cgi?id=646761
There were actually *two* MetaFrameGeometry structs: one in theme-private.h,
one in frame.h. The latter public struct was populated by a mix of (void*)
casting and int pointers, usually pulling directly from the data in the private
struct.
Remove the public struct, replace it with MetaFrameBorders and scrap all
the pointer hacks to populate it, instead relying on both structs being used
in common code.
This commit should be relatively straightforward, and it should not do any
tricky logic at all, just a sophisticated find and replace.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
Since we're not setting the frame's output shape any more, it doesn't
make sense to calculate the output shape based on the frame window.
Instead, track the client window directly and calculate the output shape
based on that.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
In preparation for switching to handling the output shape purely by what we
paint, stop applying a shape to the frame of the window. Even when we restore
handling the output shape, this will change the behavior with respect to input;
transparent areas between the frame and the contents will stop clicks rather
than passing them through, but that is arguably at least as expected
considering how that we decorate shaped windows with a frame all around.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
Don't set a window's xtransient_for if it would create a loop. Since
this is the only place we ever set xtransient_for, we can therefore
assume everywhere else that it does not loop.
https://bugzilla.gnome.org/show_bug.cgi?id=647712
