Move the last piece of monitor grid getter API to the monitor manager
away from MetaScreen. The public facing API are still there, but are
thin wrappers around the MetaMonitorManager API.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
We currently only focus unfocused windows on button press if no
modifiers (or just ignored modifiers) are in effect. This behavior
seems surprising and counter-intuitive so let's do it for any modifier
combination instead.
https://bugzilla.gnome.org/show_bug.cgi?id=746642
There's no reason to keep this ~15 year old piece of code around as
well as the preference handling that would only make sense if this
hunk was actually enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=746642
meta_parse_accelerator() considers 0 length accelerator strings as
valid, meaning that the keybinding should be disabled. Unfortunately,
it doesn't initialize the MetaKeyCombo so if the caller doesn't
initialize it either, we end up using random values and possibly
grabbing random keys.
https://bugzilla.gnome.org/show_bug.cgi?id=766270
The new tiling code, instead of based around "tiling states", is instead
based around constrained edges. This allows us to have windows that have
three constrained edges, but keep one free-floating, e.g. a window tiled
to the left has the left, top, and bottom edges constrained, but the
right edge can be left resizable.
This system also is easily extended to support corner tiling. We also,
using the new "size state" system, also keep normal, tiled, and
maximized sizes independently, allowing the maximize button to bounce
between maximized and tiled states without reverting to normal in
between. Dragging from the top will always restore the normal state,
though.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
The main monitor of a window is maintained as 'window->monitor' and is
updated when the window is resized or moved. Lets avoid calculating it
every time it`s needed.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
MetaKeyCombo is about the *unresolved* keybinding, which can either be a
"keysym" (<Ctrl>F) or a "keycode" (<Ctrl>0x21). When we resolved the
keysym to a keycode, we stuffed it back in the same MetaKeyCombo, which
confused about what the "keycode" field was for. Thus, we often stomped
on the user's explicit choice if they chose a keycode binding value.
To solve this, create a separate structure, the "devirtualized key combo"
or MetaKeyDevirtCombo, which contains a resolved keycode from the
keysym, and a devirtualized modifier mask. The MetaKeyCombo is now
always a "source" value, and the MetaKeyDevirtCombo is now always what
the user chose.
This also lets us significantly clean up the overlay and ISO key binding
paths.
The reason MetaKeyCombo has a keycode value at all is *not* to store the
devirtualized keycode from the keysym, but instead to allow people that
type in "0x55" into the preference. Everything except the overlay-key
respected this. Make the overlay-key binding respect this.
Since we now directly expose the reverses bindings directly, we
don't have to have this special-case in do_choose_window.
More importantly, if the backwards binding is pressed and has the Shift
key included, this will actually revert it
This doesn't matter for Alt-Tab in gnome-shell, which already replaces
it with a better Alt-Tab replacement, but it does matter for Alt-Esc,
which switches between windows directly.
Commit 1af0033368 made a subtle change
regarding how XKeysymToKeycode behaves. It does a depth first search
while XKeysymToKeycode is documented to do a breadth first search:
"this function looks in each column of the core keyboard mapping in
turn and returns the lowest numbered key that matches in the lowest
numbered group" - from the XKB library documentation
Looping over all keycodes for each layout and level index makes us go
back to the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=737134
Commit 2f229c3928 removed the code to compute the above-tab
keycode and replaced it with a simple constant from linux/input.h.
We obviously cannot depend on linux headers on non-linux systems,
so provide a fallback definition in that case (which is expected
to work assuming the system is using the Xorg xf86-input-keyboard
driver).
https://bugzilla.gnome.org/show_bug.cgi?id=737135
Clutter events include the layout index codified into modifier_state,
unlike XI2 device events, which means that we need to mask it out so
that we can match successfully.
This removes our Xwayland dependency in the native path. The direct
grabs are still there for the X11 backend and are a bit disgusting,
but that's OK. We can refactor it out later.
This introduces some pretty lousy hackery because it depends on
https://github.com/xkbcommon/libxkbcommon/pull/10 , and I really
don't want to wait on that to squash this dep.
Now that the internal mutter bindings and gnome-shell stopped using
META_KEY_BINDING_REVERSES, and after moving the 'adding shift reverses
the keybinding action' logic to gnome-control-center, we can remove
META_KEY_BINDING_REVERSES from mutter.
Plugin API is broken as this constant is removed from the exported
headers. ABI is broken as using this flag is now a noop.
https://bugzilla.gnome.org/show_bug.cgi?id=732385
Currently the bindings for {switch,cycle}.* actions are created with the
META_KEY_BINDING_REVERSES flag so that <shift>+binding triggers the
reverse action. However, gnome-control-center does not know about this
kind of implicit bindings, and, for example, cannot warn when the user
tries to setup a conflicting <shift>+xxx binding.
These backward <shift> bindings are being explicitly set in
gsettings-desktop-schemas, so the META_KEY_BINDING_REVERSES annotation
can be removed for them from mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=732385
MetaKeyBinding can be marked as being reversed
(META_KEY_BINDING_IS_REVERSED), but MetaKeyHandlerFunc callbacks
cannot check whether this flag was set or not on the MetaKeyBinding
which triggered the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=732295
MetaGrabOp is painful and tedious to work with, because it's a
sequential series of values, meaning we have to use a giant unreadable
switch statement to figure out some basic things about the value.
To solve this, modify the encoding for MetaGrabOp and for the specific
window grab operations so that they're a set of bitflags that we can
easily check.
Now that we always use XKB, it's very unlikely that we'll get a
MappingNotifier without a subsequence XkbKeymapNotify event. Just
do all the work always.
This will also help us considerably for the future when we'll be
putting the keymap event in the backend.
At this point there shouldn't be any system capable of running mutter
that doesn't have it and we're introducing functionality like setting
the keymap that has an hard requirement on it.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
We really can't do this unless the backend X server is the same as the
frontend X server, as we pass a frontend XID to the backend, which is
only the case when we're not a Wayland compositor.
For Wayland, we want to have everything possible in terms of the frame
rect, or "window geometry" as the Wayland protocol calls it, in order
to properly eliminate some flashing when changing states to fullscreen
or similar.
For this, we need to heavily refactor how the code is structured, and
make it so that meta_window_move_resize_internal is specified in terms
of the frame rect coordinate space, and transforming all entry points
to meta_window_move_resize_internal.
This is a big commit that's hard to tear apart. I tried to split it
as best I can, but there's still just a large amount of changes that
need to happen at once.
Expect some regressions from this. Sorry for any temporary regression
that this might cause.
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
meta_window_get_position() returns the client rect position, which
we then pass to meta_window_move_frame. Just use the existing frame
rect coordinates.
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.
If we exit early as not handled, then the normal process_event
handler will fire, and trigger the overlay-key binding. As that's
a special binding that doesn't have a handler, trying to trigger
that handler will crash mutter.
Instead of returning early, just check for xdisplay every time
we try to drive the X grab state machine. We really need a better
solution for this on the Wayland side.
Commit 585fdd781c not only removed the tabpopup, but set invalid
handlers (a.k.a. NULL) for those shortcuts; add back handling of
basic handling of those shortcuts by switching instantly without any
popups.
https://bugzilla.gnome.org/show_bug.cgi?id=728423
A careful analysis of mutter's codebase shows that nothing actually
passes anything but 0 to this. gnome-shell has one instance, but it's
most likely a mistake.
Remove the grab_mask field and the one place in keybindings.c that uses it.
The parameter to begin_grab_op is left in for API compatibility reasons.
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.
We previously separated out MetaDisplay and MetaScreen. mutter
would only manage one screen, but we still kept a list of screens
for simplicity.
With Wayland support, we no longer care about the ability to
manage more than one screen at a time. Remove this by killing
the list of screens, in favor of having just one MetaScreen
in MetaDisplay.
We also kill off active_screen at the same time, since it's
not necessary anymore.
A future cleanup should merge MetaDisplay and MetaScreen. To avoid
breaking API, we should probably keep MetaScreen around as a dummy
type.
We need to resolve the keycode from the keysym again since the keycode
might have changed if there was a keymap switch between the grab and
the ungrab.
Before starting to use display_get_keybinding() we could compare
MetaKeyBinding.modifiers with MetaKeyCombo.modifiers directly. Now, we
need to resolve the virtual modifiers to match with the mask.
This allows us to look for a match with an O(1) search instead of O(n)
which is nice, particularly when running as a wayland compositor in
which case we have to do this search for every key press event (as
opposed to only when our passive grab triggers in the X compositor
case).
We actually need two hash tables. On one we keep all the keybindings
themselves which allows us to add external grabs without constantly
re-allocating the array we were using previously.
The other hash table is an index of the keybindings in the first table
by their keycodes and mask which is how we actually match the key
press events. This second table thus needs to be rebuilt when the
keymap changes since keycodes have to be resolved then but since we're
only keeping pointers to the first table it's a fast operation.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
Instead of looping over an array of keybindings to find the correct
binding, just use display_get_keybinding().
In the next commit, we'll change the array to be a hash map, so this
helps the patch be cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
We don't want to match the keysym so that e.g. an accelerator
specified as "<Super>a" works if the current keymap has a keysym other
than 'a' for that keycode which means that the accelerator would
become inaccessible in a non-latin keymap.
This is inconvenient for users that often switch keyboard layouts, or
even have different layouts in different windows, since they expect
system-level keybindings to not be affected by the current layout.
https://bugzilla.gnome.org/show_bug.cgi?id=678001
We must spoof events to clutter even if they are associated
with a MetaWindow, because keyboard events are always associated
with one (the focus window), and we must process keybindings
for window togheter with the global ones if they include Super,
because we're not going to see them again.
The handler pointer is dangling in MetaKeyBinding until
rebuild_key_binding_table() is run, so we can't dereference it.
Because we only need the flags at ungrab time, store a copy
in the MetaKeyBinding structure.
https://bugzilla.gnome.org/show_bug.cgi?id=724402
This reverts commit ebe6e3180e.
This is wrong, as mutter's controlling TTY may not be the same
as the active VT, and in fact won't be in the case of systemd
spawning us.
The "correct" API for this is to use David Herrmann's
"Session Positions" system to switch to another VT:
http://lists.freedesktop.org/archives/systemd-devel/2013-December/014956.html
Currently the only way to move a window to another monitor via
keyboard is to start a move operation and move it manually using
arrow keys. We do have all the bits of a dedicated keybinding in
place already, so offer it as a more comfortable alternative.
https://bugzilla.gnome.org/show_bug.cgi?id=671054
For clarity, rename meta_window_get_outer_rect() to match terminology
we use elsewhere. The old function is left as a deprecated
compatibility wrapper.
Warnings that are going to the journal should be not translated:
they're not user visible, and translating them would just make
bug reporting harder (as now the developers need to understand
what the warning is saying)
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Switching meta/util.h to gi18n.h was wrong, mutter is a library
and needs gi18n-lib.h, but that cannot be included from a public
header (since it depends on config.h or command line options),
so split util.h into a public and a private part.
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Once mutter is started from weston-launch on its own VT, there is
no way to change VT again (for example to actually start an application),
because the keyboard is put in raw mode.
So introduce some keybindings mimicking the standard X ones (Ctrl+Alt+Fn)
that switch the VT manually when activated.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
We have no need for normally reported events during grabs. In fact, it
might be harmful. A plugin might grab the keyboard through
meta_begin_modal_for_plugin() and then expect events to be reported to
the grab window they provide. If meanwhile this XIGrabDevice is
issued, events might start being reported normally to one other of our
windows breaking the plugin event processing.
In particular, on an empty workspace, we set input focus to our
no_focus_window. Then, if gnome-shell calls
meta_begin_modal_for_plugin() and meta_display_freeze_keyboard(), in
that order, input events will start being reported to no_focus_window.
There are two issues with this. One is that no_focus_window isn't
selecting for XI input events and thus the server discards them
completely. But even if that is fixed, events being reported to any
window other than the one gnome-shell expects - the clutter stage
window - means that events will stop reaching it.
https://bugzilla.gnome.org/show_bug.cgi?id=701219
This will make it possible to implement input source switching in
gnome-shell using the popular modifiers-only keybinding that's
implemented on the X server through an XKB option.
https://bugzilla.gnome.org/show_bug.cgi?id=697002
