The style context of the widget is rarely what we want. We won't
fix this to be a MetaFrames style context yet; this just changes
the internal API.
https://bugzilla.gnome.org/show_bug.cgi?id=690317
Currently, we ping windows only when attempting to delete them, but
if the application is not responding, we want to show the dialog
as soon as possible. Given that we cannot be passively notified that
the window stopped responding with the current X11 protocol, a good
workaround is to ping the window when activating it.
If the window stops responding while active, it is expected the user
will try to switch window or open the overview, and when coming back
he'll get the failure dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=684340
Add meta_window_check_alive(), which is a simple wrapper over
meta_display_ping_window(), and takes care of showing the "Application
is not responding dialog" if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=684340
We want to maintain the invariant that an attached modal dialog is always
of type MODAL_DIALOG, so recompute is_attached_dialog() when the window
type changes.
https://bugzilla.gnome.org/show_bug.cgi?id=690454
This removes our final dependency on Core Events, meaning
we can remove support code for them soon.
This commit is a bit ugly as it requires ui having a dependency on
core, but this is already a hack, so this is thus a hack inside a
hack, and two hacks make a right or however that goes.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
In random places that are not grabs, we selected for events on
things like the root window, stage window, COW and more. Switch
these over to using the proper XI2 APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
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
Since we want nice alt-tab applications for gnome-shell, we should up the
limit to 96. In the future, we probably want to get rid of the icon-cache,
and allow looking up a correctly sized icon directly from the window.
To prevent app breakage, set the legacy WM_HINTS pixmap size directly to
32x32.
https://bugzilla.gnome.org/show_bug.cgi?id=689651
Add an additional "switcher" keybinding for switching between
applications rather than windows (like the existing 'switch-windows'
and 'switch-group' bindings).
The purpose of the new keybinding is to be taken over by gnome-shell's
application-based alt-tab popup, so rather than actually implementing
an application switcher in mutter, let it duplicate the normal window
switcher when run standalone.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
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
The window positioning is delayed in idle_move_resize() in case the application
resizes/maximizes its window quickly after its creation. The delayed
positioning uses window->user_rect because of bug 426519 comment 3 (see
meta_window_move_resize_now()).
user_rect was not set in the initial positioning, causing the delayed
positioning unable to know which monitor we use for this window. As a
consequence, the window could jump spontaneously from one monitor to another.
With this patch, the window does not jump anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=556696
As the overlay key works differently from normal keybindings, it
requires special treatment. However, by adding a rudimentary
MetaKeyBinding for it, we will be able to confine the special
handling to mutter and treat it like any other keybinding in
the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
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
Since GTK+ commit b1ad5c8abc2c, GtkSetting's CSS provider uses a
priority of GTK_STYLE_PROVIDER_PRIORITY_SETTINGS, which means it
will overwrite the ones we create ourselves.
Bump the priority to fix dark window decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=688182
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
Using ClutterEffect is not pratical on MetaBackgroundActor, as the FBO
redirection has a noticeable performance impact. Instead, allow adding
GLSL code directly to the pipeline used to draw the background texture.
At the same time, port MetaBackgroundActor to modern Cogl API.
https://bugzilla.gnome.org/show_bug.cgi?id=669798
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
When using the show-desktop shortcut with no desktop window, unshowing
will focus the second-most-recently-used window. If we find a desktop
window, it will be focused explicitly and everything works as expected;
however without a desktop window, we end up hiding the focus window,
which will use focus_default_window() with the not_this_one parameter
to move focus away. We used to get away with this, as the not_this_one
parameter was ignored until commit e257580b94, now with bug 675982
fixed, we need to explicitly handle the show-desktop case.
https://bugzilla.gnome.org/show_bug.cgi?id=686928
On startup, workspaces are initialized according to the num-workspaces
preference. However when using dynamic workspaces, the actual number
of workspaces in use might be greater than the preference (when
replacing the window manager), forcing windows on those workspaces
to the first workspace.
To fix, ignore the preference completely when using dynamic workspaces
and try to restore the previous number of workspaces (as read from
_NET_NUMBER_OF_DESKTOPS).
https://bugzilla.gnome.org/show_bug.cgi?id=685439
Fixes bug #670396. Without this fix the guard window may not
extend over the whole area of the screen after a XRandR
reconfiguration. The effect being that mouse events are
delivered to invisible windows.
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
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
If someone plugs in a new monitor, while all their regular windows
should move in absolute X coordinates to ensure they stay on the
same monitor, the desktop window should stay put.
https://bugzilla.gnome.org/show_bug.cgi?id=681159
Simplify the set of window-property functions to remove the
unused functions:
meta_window_reload_properties_from_xwindow()
meta_window_reload_properties()
And to make:
meta_window_reload_property()
static. The code is considerably simplified by removing the
plural variants.
https://bugzilla.gnome.org/show_bug.cgi?id=587255
Plenty of ugly here, but it works; revert when the zenity version
we depend on stops being bleeding-edge (or we can assume a zenity
version that does not error out on unknown options).
https://bugzilla.gnome.org/show_bug.cgi?id=684306
Quotes should definitively part of the translation, but we are in
string freeze now - revert this when we get a string freeze approval
or after the freeze ends.
https://bugzilla.gnome.org/show_bug.cgi?id=684306
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
meta_window_group_paint tries to carefully figure out which parts of the
scene it can avoid painting. One area it avoids painting is the region of
the screen occupied by an unredirected window (if there's one present).
When subtracting from the visible region, it gets the coordinate spaces
confused, and ends up subtracting the area at the wrong offset. Fix this
by translating the rectangle subtracted from the visible region.
https://bugzilla.gnome.org/show_bug.cgi?id=677116
When changing the overlay-key setting, the change only takes effect
on restart - there are actually two bugs involved:
(1) the test whether the key has changed is located in the
else part of a test for string settings (and overlay-key happens
to be a string settings ...)
(2) with (1) fixed, a change signal is emitted, which triggers a
reload of all keybindings - unfortunately, the actual value
of overlay-key is only read on startup, so the key is reloaded
using the old value
Fix both issues by replacing the custom handling of the overlay-key
with the regular handling of string preferences.
https://bugzilla.gnome.org/show_bug.cgi?id=681906
Instead of getting the x/y of the MetaBackgroundActor with respect to the
parent, use the same logic that we do for windows, fixing the case
where there is a more complex transformation involved.
https://bugzilla.gnome.org/show_bug.cgi?id=681221
Currently when the window group is moved, the visible region set
on the background actor no longer matches the actually visible
region, resulting in flickering around window actors.
Fix by translating the visible region with the window group.
https://bugzilla.gnome.org/show_bug.cgi?id=681221
When we consider tiling a special case of maximization, it makes
more sense to always unmaximize to the normal state rather than
restoring a previous tile state.
https://bugzilla.gnome.org/show_bug.cgi?id=677565
Currently we decide whether a modal dialog should be attached or not
when mapping it, i.e. we don't pick up preference changes that happen
while the dialog is up. It's not really a big deal given that modal
dialogs are usually transitory, but it's easy enough to add a bit of
extra polish ...
https://bugzilla.gnome.org/show_bug.cgi?id=679904
Side-by-side tiling is conceptually very close to maximization
("half-maximized"), so it makes sense to also hide the titlebar
in this state if requested by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=679290
There was a potential case where we were trying to use uninitialized memory,
in the case where the X server threw an error during XShapeGetRectangles.
In this case, we need to use the implicit shape for the window, which means
we need to rearrange code flow to make it work.
https://bugzilla.gnome.org/show_bug.cgi?id=677977
fixes 4595209346
We're supposed to return an index from here now, no longer a pointer
to the current monitor.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Similar to meta_screen_get_primary_monitor, this returns a monitor index.
The monitor that the pointer is on. The previous private implementation
has been renamed to meta_screen_get_current_monitor_info.
https://bugzilla.gnome.org/show_bug.cgi?id=642591
If a window has its BoundingRegion shaped, we shouldn't unredirect it,
as it expects the rest of the windows from being shown under it. This
prevents applications like the Skype screen recorder or gtkRecordMyDesktop
which want to show a "border" around the recorded area from being
unredirected, giving the appearance of making the desktop freeze.
https://bugzilla.gnome.org/show_bug.cgi?id=677657
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
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
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
It is impossible to switch to other windows when keep-on-top is set
for maximized windows; given that keep-on-top is only ever useful
to keep a window visible while focusing a different window, the
current behavior is pointless. So ignore keep-on-top while a window
is maximized.
https://bugzilla.gnome.org/show_bug.cgi?id=673581
This effectively makes MetaShapedTexture not a MetaShapedTexture, but a simple
and dumb MetaMaskedTexture, with an optimization for clipped regions.
We're doing this as the mask may need to be more complicated than made of
a cairo path -- we eventually want GTK+ to draw the entire frame background,
which we'll then scan.
https://bugzilla.gnome.org/show_bug.cgi?id=676052
As we want GTK+ to paint the mask on an A8, we can't simply use a cairo
path. A later commit will make this into a simple masked texture, and
meta-window-actor will be in control of the mask.
https://bugzilla.gnome.org/show_bug.cgi?id=676052
The concept of a clip region doesn't make sense now that we have anti-aliased
corners and a full alpha channel. Once the theme transition is complete,
creating a preview image with an alpha channel will be possible by passing
an ARGB surface to gtk_widget_draw(preview_widget, ...);
https://bugzilla.gnome.org/show_bug.cgi?id=676052
These queued redraws, which is a problem when we want to know exactly
what changed when we redraw, so we do minimal effort. We're eventually
going to replace the queue_redraw API with something a lot better, so
let's just get these out of the way now.
https://bugzilla.gnome.org/show_bug.cgi?id=676052
Since we now cache windows in the X server, we don't really need to cache
them here. Since we are redirecting windows in most cases, we're not gaining
anything except added memory usage. Additionally, remove the clip to screen
optimization - if a window is partially off-screen, we still need to draw
the entire thing as redirection means we won't get an expose event for it.
Additionally, when introducing invisible borders, something accidentally
slipped through: we were getting expose events on the invisible borders,
and they weren't in the cached pixels rect, so we were painting the theme
for them, even if we didn't actually paint anything with cairo. Make sure
to clip out the invisible borders instead of just the client rect so that
we don't draw if our expose event is on the invisible borders.
https://bugzilla.gnome.org/show_bug.cgi?id=675111
The EXPORT_PACKAGES variable to the GIR makefile should be the
packages needed to use this gir. It's also unnecessary to set PACKAGES
(which is just used for CFLAGS at scan-time) since CFLAGS is already
pulls in all necessary CFLAGS.
https://bugzilla.gnome.org/show_bug.cgi?id=671092
==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
If we explicitly check for a NULL pointer, clang will assume
that the pointer may be NULL at some point. We clearly rely
on the pointer being non-NULL earlier, so fix this guy up.
https://bugzilla.gnome.org/show_bug.cgi?id=674876
meta_window_actor_has_shadow() is called for every paint for every
window, verbosely logging in it makes the output of MUTTER_VERBOSE
pretty much useless.
All animations use the constants directly, so this is just declaring
a bunch of local variables and then doing nothing with it.
Another clang warning.
https://bugzilla.gnome.org/show_bug.cgi?id=674876
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
Cogl now has public experimental API to create a rectangle texture
which we can use instead of creating a foreign texture with GL. This
avoids Mutter depending on Cogl including a GL header from its public
headers which it might not do in future.
https://bugzilla.gnome.org/show_bug.cgi?id=672711
Since Cogl doesn't support multi-texturing with sliced textures and the
shape texture is combined with the texture-from-pixmap texture we need
to make sure we never construct a sliced mask texture. This patch simply
passes the COGL_TEXTURE_NO_SLICE flag to cogl_texture_from_data when
creating the shape mask texture.
https://bugzilla.gnome.org/show_bug.cgi?id=674731
It seems that the only usage of the "widget" parameter throughout
the entire call chain was to pass between two function calls as
mutual recursion.
https://bugzilla.gnome.org/show_bug.cgi?id=671104
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
If we want to support keybindings from extensions installed in the user's
directory, we can't take a schema, as the GSettings object needs to have
a special GSettingsSchemaSource.
https://bugzilla.gnome.org/show_bug.cgi?id=673014
Starting the auto-maximize process on a window like a
META_WINDOW_DESKTOP window that is not maximizable gets placement into
a confused state and eventually results in the window being positioned
at the wrong position (the position that an auto-maximized window would
be restored to.)
https://bugzilla.gnome.org/show_bug.cgi?id=673566
When mutter recognizes a full-screen window, it tries to raise it to the top
of the stack. Unfortunately, a recent rewrite of the stack code didn't do
well with raising a window to the top of the stack if the stack wasn't in
a consistent state -- it would crash. Ensure that the stack is in a consistent
state at the top of meta_stack_raise/meta_stack_lower.
https://bugzilla.redhat.com/show_bug.cgi?id=806437https://bugzilla.gnome.org/show_bug.cgi?id=672797
Commit 2fc880db switched from focusing the topmost window as the default
window to focusing the MRU window. This was done in alignment with the
introduction of per-workspace MRU lists to avoid problems where the window
stack was inadvertently changed when focusing windows during window switches.
Now that focusing windows don't have as big an impact on the stacking order,
we can revert back to focusing the top window, which is less confusing to the
user.
For now, leave per-workspace MRU lists, as they're a pretty good approximation
of a global MRU list, and it works well enough.
https://bugzilla.gnome.org/show_bug.cgi?id=620744
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
"warning: 'match_tile_mode' may be used uninitialized in this function", it
complains. It thinks it's not unused because of other values of
window->tile_mode, but other complex logic ensures that it can't be
META_TILE_MAXIMIZED, so this is a safe commit.
Windows that have minimum widths larger than the screen can't be maximized,
even though we put them in a maximized state and allow users to do so:
the window just won't change size and position. Fix this by simply not giving
the option to maximize, like what happens for non-resizable windows.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
A lot of code did something similar to:
MetaFrameBorders borders;
if (window->frame)
meta_frame_calc_borders (window->frame, &borders);
else
meta_frame_borders_clear (&borders);
Sometimes, the else part was omitted and we were unknowingly using
uninitalized values for OR windows. Clean this up by just testing
for a NULL frame in meta_frame_calc_borders and clearing for the
caller if so.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
Since we're going to be evaluating the work area at startup now, we need
to make sure that we don't iterate over workspaces before they're assigned.
The easiest way to do this is to make sure that meta_window_get_workspaces
doesn't crash.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
Returns the matching tiled window. This is the topmost tiled window in a
complementary tile mode that is:
- on the same monitor;
- on the same workspace;
- spanning the remaining monitor width;
- there is no 3rd window stacked between both tiled windows that's
partially visible in the common edge.
https://bugzilla.gnome.org/show_bug.cgi?id=643075
After the changes in style handling in GTK+, mutter's tooltips no
longer match the tooltip style used in applications. Given that
all buttons in the default layout are well-known, killing tooltips
altogether rather than fixing the styling issues looks like a valid
approach.
https://bugzilla.gnome.org/show_bug.cgi?id=645101
Windows that start up in a size that is almost as big as the workarea create
extra work for the user (resizing or maximizing) so save the user's time by
detecting such windows and automaximize them.
https://bugzilla.gnome.org/show_bug.cgi?id=671677
Basically we don't really want to create windows that are almost maximized in
size but not actually maximized. This creates work for the user and makes it
very difficult to use and resize manually.
So set the newly unmaximized window size to the previously used size or 80% of the
size of the current workarea (attempting to retain natural aspect ratio if
possible), whichever is smaller.
https://bugzilla.gnome.org/show_bug.cgi?id=671677
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
The move-to-corner keybindings weren't treated as user actions, which
resulted in them not affecting the saved position - they weren't
always being treated as sticky. Marking them as a user action revealed
bugs in the positioning logic that were hidden by the constraint
code applied to automated moves. Fix those as well. Bug tracked
down by Mariusz Libera.
https://bugzilla.gnome.org/show_bug.cgi?id=661256
