Dialogs that don't have a parent should not be skip-taskbar,
otherwise they get lost and there is no way to recover them
(because they're not autoraised when activating the parent),
but toolkits and applications set the hint anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=673399
If we're attempting to reconfigure the CRTCs to the same parameter,
skip the X call, as in some drivers a modeset can take time and
cause flicker.
https://bugzilla.gnome.org/show_bug.cgi?id=706672
To allow other clients (gnome-session, gnome-settings-daemon)
to monitor user activity, introduce a DBus interface for the
idle monitor inside mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=706005
When running as a wayland compositor, we can't use the xserver's
IDLETIME, because that's updated only in response to X events.
But we have all the events ourselves, so we can just run the timer
in process.
https://bugzilla.gnome.org/show_bug.cgi?id=706005
We can't use the X11 stage window, if clutter is not using the X11
backend (and even if it was, it would be bogus when the xwayland
server is not the one clutter is talking to). Instead, we introduce
the concept of "focus type", which we use to differentiate the
various meanings of None in the focus_xwindow field.
https://bugzilla.gnome.org/show_bug.cgi?id=706364
Using out-of-band notifications from the wayland protocol or from
X is racy, in that the client could ask for the new resources before
we have them.
Instead, with a signal, we are sure that when the client asks for
it, it will get the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=706382
Under X, we need to use XFixes to watch the cursor changing, while
on wayland, we're in charge of setting and painting the cursor.
MetaCursorTracker provides the abstraction layer for gnome-shell,
which can thus drop ShellXFixesCursor. In the future, it may grow
the ability to watch for pointer position too, especially if
CursorEvents are added to the next version of XInput2, and thus
it would also replace the PointerWatcher we use for gnome-shell's
magnifier.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
The value passed to XRRCrtcSetGamma must be allocated with
XRRAllocGamma (because it relies on the locations of green and blue),
otherwise garbage is sent on the wire.
https://bugzilla.gnome.org/show_bug.cgi?id=706231
We were relying on the XRandR events from the X server to update
the configuration, but we were calling meta_monitor_config_update_current()
immediately after, so the MonitorConfig would be updated with the
old configuration (and we would save that to disk!)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
First disable CRTCs that should be off in the new configuration,
then resize the framebuffer, then enable the new CRTCs.
If we don't do that, and we're making the screen smaller, X complains
with a BadMatch.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Add "edid-file", if we have one (in the KMS case, where we can point
people to the right sysfs file), or "edid" with inline data.
These are needed by colord to build the default ICC profile for
uncalibrated displays.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Instead of keeping a forest of if backend else ..., use a subclass
and virtual functions to discriminate between XRandR and the
dummy backend (which lives in the parent class togheter with the
common code)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
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
Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly
named XRandR API. These are used by GnomeRR inside the color
plugin of the control center (and may go away if the color
plugin decides to do something different under wayland)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
GnomeRR needs that too.
The backlight is exported as a normalized 0-100 value, or -1 if not
supported. Clamping to HW limits is handled by the backend.
Changing backlight uses a different method call, to avoid recomputing
the full display configuration every time the user presses the
backlight keys.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
The default configuration is extended, which is only possible
if there are as many CRTCs as outputs, so make sure that's true.
Also, add more and bigger modes, so that different sizes will
be chosen for the three outputs.
A nice side effect of this is that with a real 1920x1080 + 1600x900
layout, if you disable the VGA you get a stage that matches the
screen size, which triggers the legacy fullscreen path in the
outside mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Use a private output property to store if the output is in
presentation mode or not, so that this information is not lost
after the configuration read back from the server.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Ripped off libgnome-desktop, trimming the parts that checked
that the configuration was plausible, as that should be done
in gnome-control-center before asking mutter for a change.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Add a new object, MetaMonitorConfig, that takes care of converting
between the logical configurations stored in monitors.xml and
the HW resources exposed by MonitorManager.
This commit includes loading and saving of configurations, but
still missing is the actual CRTC assignments and a default
configuration when none is found in the file.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Read the current transform from XRandR, and expose the transforms
that are really supported on the bus.
The dummy backend now advertises all transforms, since it doesn't
actually apply them.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Add a number of dummy outputs and modes to the dummy backend,
and implement the writing bits.
The only visible effect is that you can change the screen size,
which resizes the output window.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Now MonitorManager does its own handling of XRandR events, which
means we no longer handle ConfigureNotify on the root window.
MetaScreen reacts to MonitorManager::monitor-changed and updates
its internal state, including the new size.
This paves the way for doing display configuration using only
the dummy backend, which would allow testing wl_output interfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Implement ApplyConfiguration in terms of XRandR calls.
Error checking is done before actually committing the configuration.
If mutter is using one of the other monitor config backends, an
error is reported and nothing happens.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Turns out that even if two outputs say that they can be controlled
by a given CRTC, you can't configure them in the same CRTC unless
they are marked as "possible clones" one of the other.
This can further restrict the configuration options, so we need
to expose this limitation in the DBus API.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
This new interface will be used by the control center and possibly
the settings daemon to configure the screens. It is designed to
resemble a simplified XRandR, while still exposing all the quirks
of the hardware, so that the panel can limit the user choices
appropriately.
To do so, MetaMonitorMode needs to track CRTCs, outputs and modes,
so the low level objects have been decoupled from the high-level
MetaMonitorInfo, which is used by core and API and offers a simplified
view of HW, that hides away the details of what is cloned and how.
This is still not efficient as it should be, because on every
HW change we drop all data structures and rebuild them from scratch
(which is not expensive because there aren't many of them, but
at least in the XRandR path it involves a few sync X calls)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Consolidate all places that deal with output configuration in
MetaScreen, which gets it either from XRandR or from a dummy static configuration.
We still need to read the Xinerama config, even when running xwayland,
because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but
now we do it only when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
It is a very bad idea in a glib program (especially one heavily
using glib child watching facilities, like gnome-shell) to handle
SIGCHLD. While we're there, let's also use g_spawn_async, which
solves some malloc-after-fork problems and makes the code generally
cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=705816
The previous code was leaving focus fields dirty in MetaWaylandPointer
and MetaWaylandKeyboard at time (which could crash the X server
because of invalid object IDs)
The new code is more tighly integrated in the normal X11 code
for handling keyboard focus (meaning that the core idea of input
focus is also correct now), so that meta_window_unmanage() can
do the right thing. As a side benefit, clicking on wayland clients
now unfocus X11 clients.
For the mouse focus, we need to clear the surface pointer when
the metawindowactor is destroyed (even if the actual actor is
kept alive for effects), so that a repick finds a different pointer
focus.
https://bugzilla.gnome.org/show_bug.cgi?id=705859
This copies the basic input support from the Clayland demo compositor.
It adds a basic wl_seat implementation which can convert Clutter mouse
events to Wayland events. For this to work all of the wayland surface
actors need to be made reactive.
The wayland keyboard input focus surface is updated whenever Mutter
sees a FocusIn event so that it will stay in synch with whatever
surface Mutter wants as the focus. Wayland surfaces don't get this
event so for now it will just give them focus whenever they are
clicked as a hack to test the code.
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
This breaks down the assumptions in stack-tracker.c and stack.c that
Mutter is only stacking X windows.
The stack tracker now tracks windows using a MetaStackWindow structure
which is a union with a type member so that X windows can be
distinguished from Wayland windows.
Some notable changes are:
Queued stack tracker operations that affect Wayland windows will not be
associated with an X serial number.
If an operation only affects a Wayland window and there are no queued
stack tracker operations ("unvalidated predictions") then the operation
is applied immediately since there is no server involved with changing
the stacking for Wayland windows.
The stack tracker can no longer respond to X events by turning them into
stack operations and discarding the predicted operations made prior to
that event because operations based on X events don't know anything
about the stacking of Wayland windows.
Instead of discarding old predictions the new approach is to trust the
predictions but whenever we receive an event from the server that
affects stacking we cross-reference with the predicted stack and check
for consistency. So e.g. if we have an event that says ADD window A then
we apply the predictions (up to the serial for that event) and verify
the predicted state includes a window A. Similarly if an event says
RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for
that event) and verify that window B is above C.
If we ever receive spurious stacking events (with a serial older than we
would expect) or find an inconsistency (some things aren't possible to
predict from the compositor) then we hit a re-synchronization code-path
that will query the X server for the full stacking order and then use
that stack to walk through our combined stack and force the X windows to
match the just queried stack but avoiding disrupting the relative
stacking of Wayland windows. This will be relatively expensive but
shouldn't be hit for compositor initiated restacking operations where
our predictions should be accurate.
The code in core/stack.c that deals with synchronizing the window stack
with the X server had to be updated quite heavily. In general the patch
avoids changing the fundamental approach being used but most of the code
did need some amount of re-factoring to consider what re-stacking
operations actually involve X or not and when we need to restack X
windows we sometimes need to search for a suitable X sibling to restack
relative too since the closest siblings may be Wayland windows.
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>
This adds a --nested option to request that mutter no longer run as a
classic X compositor with an output window mapped on the X Composite
Overlay Window and also not assume it is running directly under X.
The intention is that in this mode Mutter will itself launch a headless
X server and display output will be handled by Clutter and Cogl. This
will enable running Mutter nested as an application within an X session.
This patch introduces an internal meta_is_wayland_compositor() function
as a means to condition the way mutter operates when running as a
traditional X compositor vs running as a wayland compositor where the
compositor and display server are combined into a single process.
Later we also expect to add a --kms option as another way of enabling
this wayland compositor mode that will assume full control of the
display hardware instead of running as a nested application.
We now track whether a window has an input shape specified via the X
Shape extension. Intersecting that with the bounding shape (as required
by the X Shape extension) we use the resulting rectangles to paint
window silhouettes when picking. As well as improving the correctness of
picking this should also be much more efficient because typically when
only picking solid rectangles then the need to actually render and issue
a read_pixels request can be optimized away and instead the picking is
done on the cpu.
Originally attached dialogs did not have a titlebar, which the code
still assumes though it hasn't been true for a while; nowadays, the
actual look of attached dialogs is controlled by the theme.
As GTK+ recently gained the ability to set custom titlebars, we need
to support attached dialogs with either full borders (WM decorations)
or border-only (GTK+ titlebar).
Just remove the left-over assumption to make it work as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=702764
We need to update window->monitor on override_redirect windows as well, other
wise they may end up with an invalid struct which triggers and assert when
meta_window_is_monitor_sized is called.
https://bugzilla.gnome.org/show_bug.cgi?id=702564
Avoid a round trip to the xserver we already have the current position
anyway. Querying from the server on every move can cause the compositor to
stall during movement.
Add new api (meta_screen_get_current_monitor_for_pos and
meta_screen_get_current_monitor_info_for_pos) that allow querying the monitor
without a roundtrip by reusing the passed in cursor position.
gnome-shell needs to know whether the stage window is focused so
it can synchronize between stage window focus and Clutter key actor
focus. Track all X windows, even those without MetaWindows, when
tracking the focus window, and add a compositor-level API to determine
when the stage is focused.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
When we set the input focus, we first set the predicted window,
and then try to process focus events. But as XI_FocusOut on the
existing window comes before XI_FocusIn on the new window, we'll
see the focus out on the old window and think the focus is going
to nothing, which makes mutter think the prediction failed.
This didn't really matter as nothing paid attention to the focus
window changing, but with gnome-shell's focus rework, we'll try
and drop keyboard focus in events like these.
Fix this by making sure that we ignore focus window changes of our
own cause when updating the focus window field, by ignoring all
focus events that have a serial the same as the focus request or
lower. Note that if mutter doens't make any requests after the
focus request, this could be racy, as another client could steal
the focus, but mutter would ignore it as the serial was the same.
Bump the serial by making a dummy ChangeProperty request to a
mutter-controlled window in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=701017
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
We'll use this in gnome-shell to freeze the keyboard right before
switching input source and unfreeze it after that's finished so that
we don't lose any key events to the wrong input source.
https://bugzilla.gnome.org/show_bug.cgi?id=697001
If a binding is updated with a clear set of strokes (effectively
disabling it) we aren't signaling that the binding changed and thus
the previous strokes will continue to be grabbed.
This fixes that and tries to do a better effort at checking if the
binding changed or not.
https://bugzilla.gnome.org/show_bug.cgi?id=697000
gnome-shell has traditionally just called XSetInputFocus when wanting to
set the input focus to the stage window, but this might cause strange,
hard-to-reproduce bugs because of an interference with mutter's focus
prediction. Add API to allow gnome-shell to focus the stage window that
also updates mutter's internal focus prediction state.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
If an app pops up an OR window and sets input focus to it, like
Steam does, we'll think the focus window is null, causing us to
think the app is not focused.
OR windows should not be special if they get input focus, where
the input focus would be set to NULL. Instead, the window should
be marked as focused.
https://bugzilla.gnome.org/show_bug.cgi?id=647706
Mutter previously defined display->focus_window as the window that the
server says is focused, but kept display->expected_focus_window to
indicate the window that we have requested to be focused. But it turns
out that "expected_focus_window" was almost always what we wanted.
Make MetaDisplay do a better job of tracking focus-related requests
and events, and change display->focus_window to be our best guess of
the "currently" focused window (ie, the window that will be focused at
the time when the server processes the next request we send it).
https://bugzilla.gnome.org/show_bug.cgi?id=647706
Make it a static function for now, but this will be a private
function soon, replacing meta_window_lost_focus. This should
contain no functional changes, only cosmetic indentation changes,
so best viewed with ignorews=1 or -w or -b, you know the drill.
https://bugzilla.gnome.org/show_bug.cgi?id=647706
Clients using _NET_WM_MOVERESIZE to start a drag operation may encounter
a race condition if the user presses and releases a mouse button very
fast, getting "stuck" in a grab state. While this is easily fixed with
the user pressing the button or hitting Escape as the EWMH spec suggests,
its's still a bit of annoyance for users.
After starting a grab operation, check that the button is actually pressed
by the client, and if not, cancel the grab operation. This prevents the
stuck grab in a race-free way, although it requires an extra round-trip
to the server.
With client-side decorations becoming more popular, the use of
_NET_WM_MOVERESIZE is on the rise, thus this bug is seen more frequently
than before.
https://bugzilla.gnome.org/show_bug.cgi?id=699777
As we only had one string-array preference so far, we didn't bother
with adding a generic way to handle string-array preferences, and
just handled the preference in question explicitly. However we are
going to parse another string-array setting, so generalize the
existing code to make it reusable for that case.
https://bugzilla.gnome.org/show_bug.cgi?id=700223
This essentially just moves install_corners() from the compositor, through
the core, into the UI layer where it arguably should have been anyway,
leaving behind stub functions which call through the various layers. This
removes the compositor's special knowledge of how rounded corners work,
replacing it with "ask the UI for an alpha mask".
The computation of border widths and heights changes a bit, because the
width and height used in install_corners() are the
meta_window_get_outer_rect() (which includes the visible borders but not
the invisible ones), whereas the more readily-available rectangle is the
MetaFrame.rect (which includes both). Computing the same width and height
as meta_window_get_outer_rect() involves compensating for the invisible
borders, but the UI layer is the authority on those anyway, so it seems
clearer to have it do the calculations from scratch.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
XUngrabKey() doesn't work for XI2 grabs and XI2 doesn't provide API
with similar functionality. As such, we have to refactor the code a
bit to be able to call XIUngrabKeycode() for each key binding, then
reload keybindings and finally grab the new ones.
https://bugzilla.gnome.org/show_bug.cgi?id=697003
In 97a4cc8c, we accidentally lost the check that kept us from
sending multiple configures to a window before it responds to
_NET_WM_SYNC_REQUEST. So _NET_WM_SYNC_REQUEST stopped working
properly. Add a check back with the same effect.
https://bugzilla.gnome.org/show_bug.cgi?id=696091
During a resize, if we don't have a configure pending, then a counter
change shouldn't trigger anything other than the normal drawing:
it's just a spontaneous frame from the application. So don't try
to update the position or remove our timeout ID.
https://bugzilla.gnome.org/show_bug.cgi?id=696091
Trying to track the fullscreen status outside of Mutter, as GNOME Shell
was doing previously, was very prone to errors, because Mutter has a
very tricky definition of when a window is set to be fullscreen and
*actually* acting like a fullscreen window.
* Add meta_screen_get_monitor_in_fullscreen() and an
::in-fullscreen-changed signal. This allows an application to
track when there are fullscreen windows on a monitor.
* Do the computation of fullscreen status in a "later" function that
runs after showing, so we properly take focus into account.
* To get ordering of different phases right, add more values
to MetaLaterType.
* Add auto-minimization, similar to what was added to GNOME Shell
earlier in this cycle - if a window is set to be fullscreen, but
not actually fullscreen, minimize.
https://bugzilla.gnome.org/show_bug.cgi?id=649748
Since the tile mode is now always reset on maximize(), this code
no longer does anything (not to mention that side-by-side tiled
windows haven't snapped back for a while now).
https://bugzilla.gnome.org/show_bug.cgi?id=682779
We used to restore side-by-side tiling when unmaximizing, so we
kept the tile-mode during maximization. Since commit 10d53fc7d
there's no longer a good reason to do so, and it can result in
tile previews being shown erroneously on window drag operations
without motion (double-click on titlebar), so reset the tile
mode in maximize().
https://bugzilla.gnome.org/show_bug.cgi?id=682779
The tile preview is expected to be shown underneath the focus window.
However the code that restacks the preview broke when override-redirect
windows were moved to a separate window group.
To fix, special-case tile previews to put them in the NORMAL layer.
https://bugzilla.gnome.org/show_bug.cgi?id=696053
Previously, we were handling failure to respond to _NET_WM_SYNC_REQUEST
in the code path for throttling motion events. But this meant that
if a window didn't respond to _NET_WM_SYNC_REQUEST and there were no
motion events - for a keyboard resize, or after the end of the grab
operation - it would end up in a stuck state.
Use a separate per-window timeout to reliably catch the failure to respond
to _NET_WM_SYNC_REQUEST.
https://bugzilla.gnome.org/show_bug.cgi?id=694046
During resizing we froze window updates when configuring the
window, and unfroze the window updates when processing the
next resize. This wasn't absolutely reliable, because we might
not have a next resize. Instead tie window freezing more
directly to the current sync request value - a window is
frozen until it catches up with the last value we sent it
in _NET_WM_SYNC_REQUEST.
Testing with unresponsive clients showed that there was a bug
where window->disable_sync once set, would not actually disable
sync, but it *would* disable noticing that the client was
unresponsive for the next resize. Fix that by checking for
->disable_sync before sending _NET_WM_SYNC_REQUEST.
https://bugzilla.gnome.org/show_bug.cgi?id=694046
Send a _NET_WM_FRAME_DRAWN for each newly created window, as required
by the specification. This avoids a race where a window might be created
frozen but already unfrozen by the time we first see fetch the
counter value.
Remove a duplicate call to meta_compositor_set_updates_frozen() which
was called before the MetaWindowActor is created and hence did nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=694771
mutter currently only filters the overlay key through the shell
when there is a grab operation and that grab operation belongs to the
shell (because the shell is pushModal'd). This means the shell can't
filter out overlay key press events events at startup (since the shell
isn't normally modal).
This commit changes the code to always run the shell filtering code,
even when the shell is not modal.
https://bugzilla.gnome.org/show_bug.cgi?id=694837
gnome-shell shouldn't announce to the session manager it's
"ready" until it's fully initialized. It currently tells
the session manager it's ready as soon as it hits the main
loop. This causes nautilus in classic mode to start before
we have workspaces initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=694876
During compositor grabs, all global keybindings that don't go
through mutter's keybinding system are blocked. To allow other
processes to make use of it, gnome-shell will expose a simple
grab API on DBus; for this, add API to grab key combos directly
instead of parsing accelerators stored in GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=643111
meta_screen_get_monitor_for_rect will return the monitor that
a given rect belongs in (choosing the "best" monitor based on
overlap, if there are overlapping monitors).
It doesn't work with 0x0 rects, though.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=694725
meta_window_is_remote compares a cached copy of the system hostname
with the hostname of the client window
(as presented by the WM_CLIENT_MACHINE property).
Of course, the system hostname can change at any time, so caching
it is wrong. Also, the WM_CLIENT_MACHINE property won't necessarily
change when the system hostname changes, so comparing it with the
new system hostname is wrong, too.
This commit makes the code call gethostname() at the time
WM_CLIENT_MACHINE is set, check whether it's remote then, and cache
that value, rather than comparing potentially out of sync hostnames
later.
https://bugzilla.gnome.org/show_bug.cgi?id=688716
Window menus use the first key combination for a binding to show the
acceleration, so the list must be in the right configured order, which
is the opposite of what's built by g_slist_prepend()
https://bugzilla.gnome.org/show_bug.cgi?id=694045
The guard window is effectively the background window, as it sits
in between live windows and minimized windows. This gives us a nice
easy place to allow users to allow users to right-click or long-press
on the wallpaper.
https://bugzilla.gnome.org/show_bug.cgi?id=681540
We do, in fact, need freezing to affect window geometry, so that
move-resize operations (such as an interactive resize from the
left, or a resize of a popup centered by the application) occur
atomically.
So to make map effects work properly, only exclude the initial
placement of a window from freezing. (In the future, we may want
to consider whether pure moves of a window being done in response
to a user drag should also be excluded from freezing.)
Rename meta_window_sync_actor_position() to
meta_window_sync_actor_geometry() for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=693922
The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
During resizing, An odd counter value (indicating the beginning of a frame)
shouldn't cause us to redraw and start a new frame, only an even counter
value. This was causing the frozen state for the window frame counter to
overlap the frozen state for the resize, causing the window not to be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
In different places we checked the grab op differently when determing
whether we are using _NET_WM_SYNC_REQUEST. This was somewhat covered
up previously by the fact that we only had a sync alarm when using
_NET_WM_SYNC_REQUEST, but that is no longer the case, so consistently
use meta_grab_op_is_resizing() everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
When a client is drawing as hard as possible (without sleeping
between frames) we need to draw as soon possible, since sleeping
will decrease the effective frame rate shown to the user, and
can also result in the system never kicking out of power-saving
mode because it doesn't look fully utilized.
Use the amount the client increments the counter value by when
ending the frame to distinguish these cases:
- Increment by 1: a no-delay frame
- Increment by more than 1: a non-urgent frame, handle normally
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Use XSyncSetPriority() to prioritize the compositor above applications
for X server priority. In practice, this makes little difference because
the Xorg "smart scheduler" will schedule in a single application for
time slices that exceed the frame drawing time, but it's theoretically
right and might make a difference if the X server scheduler is improved.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Resizing the frame triggers creation of a new backing pixmap for the
window, so we should do that first before we resize the client window
and mess up the contents of the old backing pixmap.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
If an application provides two values in _NET_WM_SYNC_REQUEST_COUNTER,
use that as a signal that the applications wants an extended behavior
where it can update the counter as well as the window manager. If the
application updates the counter to an odd value, updates of the
window are frozen until the counter is updated again to an even value.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Instead of creating a new alarm each time we resize a window
interactively, create an alarm the first time we resize a window
and keep it around permanently until we unmanage the window.
Doing it this way will be useful when we allow the application to
spontaneously generate sync request updates to indicate
frames it is drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Replace the unused meta_compositor_set_updates() with
a reversed-meaning meta_compositor_set_updates_frozen(), and use
it to implement freezing application window updates during
interactive resizing. This avoids drawing new areas of the window
with blank content before the application has a chance to repaint.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
meta_screen_resize calls meta_window_update_for_monitors_changed for all
windows including OR windows when the monitors change (or screen size).
This calls meta_window_move_between_rects for the window which attempts to
move the OR window by calling meta_window_move_resize.
meta_window_move_resize refuses to do anything on OR windows (just returns
for OR windows).
This causes a storm of assert messages when the screen
resolution changes while an OR window is visible.
(like the one gnome-control-center displays with the monitor name).
Fix that by not calling meta_window_update_for_monitors_changed for OR windows
and let the applications handle them by themselves.
https://bugzilla.gnome.org/show_bug.cgi?id=693540
As the hash table no longer stores only window IDs, we should rename it so
that we make sure to check if something is actually a window before using it
as a window.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
XInput 2.3 adds support for "barrier events", which let us know when
a pointer barrier has been hit, and when the pointer has stopped
hitting the barrier, and lets us "release" the barrier, temporarily
letting the pointer pass through the barrier. These features can be
combined to allow for certain pointer gestures, such as "pushing"
against the bottom of the screen, or stopping the pointer on monitor
edges while dragging slowly for increased edge precision.
This commit should allow graceful fallback if servers with
XInput 2.3 aren't supported.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
Currently, we have a few function wrappers in the shell for pointer
barriers. If we want to implement interactive features on barriers,
we need some sort of signal to be notified of the interactivity.
In that case, we need to make a more sophisticated object-based wrapper
for a pointer barrier. Add one, and stick it in mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
Some windows may already have event masks on them that we've selected
for, especially if we're using GTK+ windows. In particular, this fixes
window menus in the XI2 port.
https://bugzilla.gnome.org/show_bug.cgi?id=690581
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
We want to put barrier wrappers in mutter, which requre XFixes 5.0.
XFixes 5.0 was released in March, 2011, which should be old enough
to mandate support for.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
Using a public method for setting the (cached) icon geometry rather
than accessing the struct members directly allows setting the icon
geometry from extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=692997
We have some code in gnome-shell that does the equivalent of:
window.get_workspace() == workspace || window.is_on_all_workspaces();
which is a bit unwieldy. We already have a method in mutter,
so use that and document it.
https://bugzilla.gnome.org/show_bug.cgi?id=691744
MetaButtonLayout is extremely unfriendly for introspection: its fields
are arrays of a fixed length, but the actual length is determined by
a custom stop value (e.g. not NULL / 0).
Without API changes this will never work nicely in introspection, but
we can at least make it work; start by filling up unused fields with
the stop value rather than leaving it at random values.
https://bugzilla.gnome.org/show_bug.cgi?id=689263
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
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
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
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
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
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
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
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
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 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
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
==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
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
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
We currently sync the number of workspaces with the corresponding
preference. This is not really useful with GNOME Shell's dynamic
handling of workspaces, not least as the setting is effectively
ignored. Worse, it will trigger writes to dconf on login, slowing
down startup, so add a setting to indicate that workspaces are managed
dynamically and really ignore the num-workspaces setting when set.
https://bugzilla.gnome.org/show_bug.cgi?id=671568
After _unmanage the object is semantically dead even if technically it's not,
so remove the prefs listener here to prevent it being called for a dead
object.
In particular this fixes a crash when starting up gnome-shell with at least
one gimp utility window opened which causes mutter to create a MetaWindow for
it only to immediately get an UnmapNotify afterwards which causes mutter to
unmanage the MetaWindow. Afterwards prefs_changed_callback is called for this
dead MetaWindow and tries to dereference the window->monitor pointer which is
already NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=671087
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
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
To account for this use case, a setting for requesting that windows'
titlebars should be hidden during maximization has been added to
GTK+, add support for this in the window manager.
https://bugzilla.gnome.org/show_bug.cgi?id=665617
Using an external application using libwnck an external application
can create a new workspace by moving a window into it. In this case we
are currently missing a "workspace-added" signal emission.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=666015
The current code requires windows to be resizable to be considered
for tiling, which excludes all maximized/tiled windows. While this
restriction concurs with the desired behavior for edge-tiling, it
feels overly restrictive for keybindings.
As the edge-tiling code in update_move() already ensures the above
restriction, it seems save to remove it from the can_tile_maximized()
function, assuming that windows that are not meant to be tiled or
maximized won't provide a maximize function.
https://bugzilla.gnome.org/show_bug.cgi?id=648700
Usually tiling involves a size change and the frame is redrawn
automatically, however this is not the case when switching directly
between left- and right-tiled.
Ensure that a redraw happens in that case as well.
https://bugzilla.gnome.org/show_bug.cgi?id=648700
Rather than defining keybindings in static arrays generated at compile
time, store them in a hash table initialized in meta_display_init_keys()
and filled in init_builtin_keybindings().
This is a prerequisite for allowing to add/remove keybindings at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=663428
Commit d0910da036 merged the visual-bell/visual-bell-type options,
but the change turned out too disruptive for gnome-control-center /
gnome-shell, so gsettings-desktop-schemas commit a5819b2a4e9 re-added
the separate option.
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_move_resize_frame operates much like
meta_window_move_resize, but ensures the window
and its frame (if present) will fit within the
specified dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=651899
We never destroy the later list that's added by meta_later_add.
==4289== 16 bytes in 1 blocks are definitely lost in loss record 1,632 of 7,258
==4289== at 0x4C2640D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4289== by 0x5178D9F: standard_malloc (gmem.c:88)
==4289== by 0x5178E37: g_malloc (gmem.c:164)
==4289== by 0x51924B5: g_slice_alloc (gslice.c:842)
==4289== by 0x5194521: g_slist_insert_sorted_real (gslist.c:900)
==4289== by 0x519465A: g_slist_insert_sorted (gslist.c:957)
==4289== by 0x4EA609A: meta_later_add (util.c:876)
==4289== by 0x4E9C330: meta_screen_queue_workarea_recalc (screen.c:2640)
==4289== by 0x4E9A360: update_num_workspaces (screen.c:1646)
==4289== by 0x4E99026: meta_screen_new (screen.c:924)
==4289== by 0x4E7AB51: meta_display_open (display.c:803)
==4289== by 0x4E9168E: meta_run (main.c:552)
https://bugzilla.gnome.org/show_bug.cgi?id=642652
If we are moving in snap mode (shift pressed) we don't want to tile. We must
also cancel any pending tiling if snap mode is activated during the move drag.
https://bugzilla.gnome.org/show_bug.cgi?id=662270
When we reparent a window to the root when we're exiting, we need to offset
the position by the invisible borders, otherwise windows will creep up and
to the left.
https://bugzilla.gnome.org/show_bug.cgi?id=660848
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
When using more than one monitor, tiled maximization can be triggered with the
pointer in one monitor while most of the window area remains in another. This
means that the maximization constraint would maximize the window into the wrong
monitor as it uses the work area size/position as target.
Fix this by using the current tile area as target size/position.
https://bugzilla.gnome.org/show_bug.cgi?id=657519
Since the frame window size that meta_window_move_resize() uses depends
on whether the window has horizontal/vertical resize functionality, we
need to update this flag before we resize the window.
https://bugzilla.gnome.org/show_bug.cgi?id=659854
If a window had a type hint intended for override-redirect windows
like NOTIFICATION, we ended up with a window that was decorated but
with a frame type of FRAME_TYPE_LAST, causing assertion failures.
Fix this by making recalc_window_features() just call
meta_window_get_frame_type().
https://bugzilla.gnome.org/show_bug.cgi?id=599988
_NET_FRAME_EXTENTS should contain the difference between where a window asked
to be placed, and where it is. Ideally, this should be the same as the visible
extents.
https://bugzilla.gnome.org/show_bug.cgi?id=659848
A window can specify geometry that it is placed at. We need to exclude invisible
borders when calculating where to place the window, otherwise the window will have
a strange offset.
https://bugzilla.gnome.org/show_bug.cgi?id=659848
If XRANDR is availible, we track the first (or primary) output per
crtc (== xinerama monitor) so when the monitors change we can try
to find the same output and move windows there. If we can't find the
original monitor in the new set (or XRANDR is not supported) we move
the window to the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=645408
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
This goes better with the general style of similar alerts throughout
GNOME 3, and as has been pointed out in bug 591735, 'Mutter' is
a somewhat unfortunate title in several lanuages, such as English
and German.
* At least one line (possibly blank) is required after a function name for a doc header
to be parsed correctly.
* SnStartupSequence isn't a type known to introspection
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
get_outer_rect now returns the visible region, and a new get_input_rect
method returns the boundaries of the full frame, including the possible
invisible regions. When undecorated, both do the samething.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
Just a quick little commit to help clean things up for when we add invisible
borders. Additionally, do a little housekeeping in preview-widget as well.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
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
We were leaving some members of the button_layout struct uninitialized if the
pref string didn't have at least one colon or if it was an empty string ("").
https://bugzilla.gnome.org/show_bug.cgi?id=654539
Calling meta_later_add() or meta_later_remove() from within a
META_LATER_BEFORE_REDRAW callback ended up being a no-op, because of
how run_repaint_laters() was fiddling with the laters list. (This
resulted in a crash in window.c:idle_calc_repaint(), which assumed it
would only be called when a certain queue was non-empty, but was
getting called anyway because of a failed meta_later_remove() call.)
Fix this by having run_repaint_laters() work on a copy of the laters
list instead, and add refcounting to MetaLater so that removing a
later that run_repaint_laters() hasn't gotten to yet won't cause
problems.
https://bugzilla.gnome.org/show_bug.cgi?id=642957
When we get a press of the overlay key, and then another key is pressed,
first try to handle the combination as a global keybinding. If that fails,
call XAllowEvents(..., ReplayKeyboard, ...) to let it be handled by
our per-window keybindings or by the application.
This requires restructuring things to call XAllowEvents a bit later
so we can pass the right mode.
https://bugzilla.gnome.org/show_bug.cgi?id=624869
The code assumed that the focus window was always the one at the
top of the window stack, which is not true if an unfocused window
has the above hint set.
Rather than fixing this assumption, rename the function to
lower_beneath_grab_window() and use the display's grab window - the
function is only used for displaying the tile previews, which means
that we want the grab window anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=650661
When detaching/attaching a dialog, we were only updating
appears-focused on the parent if the child itself was focused, but in
fact, we need to do it if the child has an attached child which is
focused too.
To simplify the case of detaching a focused subtree from its parent,
we change meta_window_propagate_focus_appearance() to use
@window->display->focus_window as the window to add/remove as the
attached_focus_window, and @window only as the starting point to
propagate from. That way we can propagate focus-removal up to
@window's (soon-to-be-ex-)ancestors without having to remove it from
its descendants as well.
https://bugzilla.gnome.org/show_bug.cgi?id=647712
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
meta_run() calls meta_finalize() after the main loop exits, which ends
up calling meta_display_close(), which calls
meta_quit(META_EXIT_SUCCESS), meaning that any exit status passed to
the original meta_quit() call is lost.
Fix this by ignoring meta_quit() calls after the main loop is no
longer running.
https://bugzilla.gnome.org/show_bug.cgi?id=652010
Like the setting of new frames' background is delayed until the
frame is associated with its window, delay attaching the initial
style, so that the correct style variant is picked.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
When the _GTK_THEME_VARIANT property changes, rather than just
updating the window's theme_variant property, update its frame
style as well, so that the window decoration reflects the requested
variant. As the initial properties of a window may be read before
its frame is created, there will be cases where the change is not
picked up initially.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
Since version 3.0, GTK+ has support for style variants. At the moment,
themes may provide a dark variant, which can be requested by
applications via GtkSettings. The requested variant is exported to
X11 via the _GTK_THEME_VARIANT property - support this property, in
order to pick up the correct style variant in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
To determine the correct background style, the UI needs to access
some frame properties via meta_core_get(); this call will bail out
early if window->frame is unset, so delay the call until the
association is made.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
For the purposes of window placement or arranging window manager or
plugin controls, screens that are just mirrors of other screens should
be ignored, so filter them out of the monitors list.
https://bugzilla.gnome.org/show_bug.cgi?id=649299
If a window is not maximizable, then that probably means it looks dumb
at very large sizes. Even if its hints would allow you to manually
resize it to a large size, don't allow automatically tiling it to half
the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=647901
If a window had no title property set, then the
application-not-responding dialog would cause Mutter to crash
because window->title was NULL; handle that case and use the
string "Application is not responding."
https://bugzilla.gnome.org/show_bug.cgi?id=649114
Command line arguments are supposed to be in the locale encoding,
not UTF-8, and Zenity decodes command line string command line
arguments with this assumption using GOption.
There was a half-hearted attempt to deal with this in delete.c,
but it wasn't correct since it immediately mixed the window title,
converted to the locale encoding with a UTF-8 message.
https://bugzilla.gnome.org/show_bug.cgi?id=649114
As a library, libmutter should not be setting the default translation
domain to point to itself.
Also, move the bindtextdomain() call earlier
(meta_get_option_context), so that translations of command-line
options will be available.
We could call textdomain() in mutter.c, but there's no need to, since
mutter uses dgettext() everywhere anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649202
Previously, the restart command hardcoded "mutter" as the binary name.
This commit changes it to use g_get_prgname() which has a better chance
of being correct (and it does fix session saving for gnome-shell).
Now that mutter is a library, it might be more correct (but also
much higher overhead) to add api for setting these things from
the outside.
https://bugzilla.gnome.org/show_bug.cgi?id=648828
An ARGB window with a frame is likely something like a transparent
terminal. It looks awful (and breaks transparency) to draw a big
opaque black shadow under the window, so clip out the region under
the terminal from the shadow we draw.
Add meta_window_get_frame_bounds() to get a cairo region for the
outer bounds of the frame of a window, and modify the frame handling
code to notice changes to the frame shape and discard a cached
region. meta_frames_apply_shapes() is refactored so we can extract
meta_frames_get_frame_bounds() from it.
https://bugzilla.gnome.org/show_bug.cgi?id=635268
If a window can not be tiled, e.g. due to its minimum size hints,
dragging away from the top after activating the maximize tile preview
does not cancel the maximization request, the only way to do so is by
hitting Escape.
To fix, reset the tiling state in the maximize-tile code path as
well if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=646149
Apparently the "fox" toolkit doesn't set WM_CLIENT_MACHINE; while we
could do gymnastics to attempt to figure this out (talk to the X
server?), better to just default to FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=647662
Since appears-focus only propagates up from modal dialogs, if an
application removed the modal hint from a dialog before destroying it,
then its parent would be left with a stray reference to it in
attached_focus_window, causing it to be permanently appears-focused.
The obvious fix, calling meta_window_propagate_focus_appearance() when
the modal hint is removed, tends to cause noticeable flashing, because
the window will get drawn unfocused and then focused again.
So instead we just change meta_window_propagate_focus_appearance() to
check the window type only when focusing in, not when focusing out.
This would also cause flashing, but in this case we can avoid it by
not notifying the change in appears-focus on the parent window if it
is the expected_focus_window (which it will be by this point). (This
does mean though that if something weird happens and the window
doesn't end up becoming the focus window, it won't get redrawn
unfocused until something else forces it to.)
https://bugzilla.gnome.org/show_bug.cgi?id=647613
We need to redraw a window's shadow any time the value of
meta_window_appears_focused() changes. So make that into a property so
we can get notifications on it.
https://bugzilla.gnome.org/show_bug.cgi?id=636904
This is necessary for gnome-shell to know whether it should try to
replace the org.gnome.Shell DBus name.
Note: We can't just #include <meta/util.h> because it #defines '_'
at least which obviously conflicts with core gettext. We should
un-export util.h or fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=645590
As the position of attached modal dialogs is determined entirely
by the position of the parent window, the dialog may end up
partially off-screen (especially if the dialog is wider than the
parent). In this case, diverge from the calculated position and
try to fit the dialog on-screen.
https://bugzilla.gnome.org/show_bug.cgi?id=631308
This is useful for DnD to another monitor in gnome-shell.
In addition to a normal move it corrects the saved rect for
maximized and fullscreened windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645032
Currently attached modal dialogs are not resizable, but we don't
communicate this to GTK+, so the dialog may end up with resize
grips anyway. As a fix, allow resizing, but account for the dialog
being centered to its parent.
https://bugzilla.gnome.org/show_bug.cgi?id=643597
Getting the contents of a depth-1 pixmap through cairo gives us
an alpha pixmap. We need to convert to a monochrome pixmap
as is expected by the ICCCM definition of WM_HINTS.
https://bugzilla.gnome.org/show_bug.cgi?id=641975
apply_mask made some wrong assumptions that became untrue
after rendering_cleanup landed, such as the number of channels
in the pixmap, causing corruption.
https://bugzilla.gnome.org/show_bug.cgi?id=641975
Currently, attached modal dialog can be grabbed (either by the
title bar, or using Alt+Button1), though they won't move when
dragged. To address this, grab the parent in that case, which
allows to move both the parent and the attached dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=638674
Commit 96c43866 changed the tiling behavior to prefer edge tiling
over maximization in corner cases (well, quite literally). As a
side effect, it only allows untiling of edge-tiled windows by
dragging the window towards the correct edge.
This patch restores the old behavior for untiling, while keeping
the new behavior for untiled windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645455
For tiling, we check whether the pointer is near the edges of
the monitor where the pointer is located, so checking that the
pointer is within the bounds of the monitor is unnecessary and
confusing.
Mark that the the third argument to meta_rectangle_union and
meta_rectangle_intersect is an (out) argument that should be created
by the language binding.
https://bugzilla.gnome.org/show_bug.cgi?id=645247
If dragging the title bar to the edge of the screen to side-tile,
it's easy to end up above the workarea and end up maximized instead.
Make the entire side of the screen act as edge-tiling.
https://bugzilla.gnome.org/show_bug.cgi?id=644961
In a performance or regression testing environment, we may want to
only manage windows from a particular test program, and ignore all
other windows. The MUTTER_WM_CLASS_FILTER environment variable is a
list of WM_CLASS values that should be managed; other windows will
be unmapped and ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=644252
gtk3 no longer has the --screen command-line argument, which mutter
was passing to zenity. Use --display (with an explicitly-specified
screen number) instead.
https://bugzilla.gnome.org/show_bug.cgi?id=643683
This made sense back in the day of stateless window managers,
but gnome-shell isn't. gnome-session will handle gnome-shell
crashing, since it's a required component.
https://bugzilla.gnome.org/show_bug.cgi?id=644529
This adds a preference that when enabled makes all windows not on
the primary monitor be visible on all workspaces (i.e. not part of the
workspace switching handling).
https://bugzilla.gnome.org/show_bug.cgi?id=609258
Sometimes on_all_workspaces is requested by the client/user, and sometimes
its calculated implicitly due to internal state. We split this up so that
we know when the user has explicitly asked for sticky window, when e.g.
setting wmspec properties or storing session info.
on_all_workspaces means this window is visible on all workspaces.
on_all_workspaces_requested, means the user explicitly made the window
sticky somehow (via imported session, _NET_WM_STATE from another wm,
toggled in the window menu, etc). It always implies on_all_workspaces is
TRUE.
Right now the only time we set on_all_workspaces is for override-redirect
windows, but later we can add a "windows on non-primary monitor are not
part of the workspace switching" feature.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
We don't actually use the full xrandr to get the primary monitor, we
just rely on the xrandr xinerama compat code to return the primary
monitor first. This lets us avoid adding unnecessary xrandr code and
avoids issues with _NET_WM_FULLSCREEN_MONITORS monitor indexes being
defined wrt xinerama monitor index order.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
The latter move method will place the window by the origin of the
enclosing window decoration/frame, while the former will place by the
origin of the inner window, itself.
(Also moved meta_window_showing_on_its_workspace comment into
gtk-doc)
https://bugzilla.gnome.org/show_bug.cgi?id=642355
When reload_net_wm_state() is called at startup to read the initial
value of _NET_WM_STATE, it was calling recalc_window_type(), but not
recalc_features(), which meant that, eg, meta->skip_taskbar would
never get initialized from meta->wm_state_skip_taskbar, which meant
that next time mutter went to update the window's _NET_WM_STATE, it
would overwrite the app-specified initial values. Fix that.
(In metacity, this bug is masked by the fact that recalc_features()
gets called when reading the intial value of WM_NORMAL_HINTS, which
comes after _NET_WM_STATE in metacity's prop_hooks_table. In mutter,
the table got reordered at some point, exposing the bug.)
https://bugzilla.gnome.org/show_bug.cgi?id=624360
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
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
meta_restart() was broken, in that it restarted mutter with what was
left of argv after GOption and Clutter had possibly modified it.
Rather than try to fix this, just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
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
It looks amazingly lame if we simply call exit() during logout. While
it's true that for applications that use XSMP, gnome-session will
close them before us, that doesn't do anything for non-XSMP apps,
which we really hope is the common case.
Instead, we just go away when the X server does.
https://bugzilla.gnome.org/show_bug.cgi?id=643437
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.
If we handle a key event then passing it to GTK+ as well can only
cause confusion. Normally GTK+ would do nothing with a key event for
some window it doesn't know about, but plugins might be doing more
things with the GTK+ event queue.
https://bugzilla.gnome.org/show_bug.cgi?id=642426
If we are previewing hidden windows, we might be previewing them in a context
like a thumbnail view of a workspace where we care about positioning. So, instead
of waiting until the window is first actually shown to place it, if
live_hidden_previews is set, place the window window when we first compute its
visibility, even if we don't end up showing it.
https://bugzilla.gnome.org/show_bug.cgi?id=641309
A plugin that does workspace management on its on may want to set the
workspace layout without having to deal with putting a property
on the root window to be read back and parsed.
Add meta_screen_override_window_layout() that allows the same types
of layouts as _NET_DESKTOP_LAYOUT but without setting a property.
https://bugzilla.gnome.org/show_bug.cgi?id=640552
When we delete a workspace before the active workspace, we need
to upate the _NET_CURRENT_DESKTOP since the active workspace index
changes. To do this workspace.c:set_active_space_hint() is moved
to screen.c:meta_screen_set_active_workspace_hint() so that it
can be shared.
https://bugzilla.gnome.org/show_bug.cgi?id=640581
On gcc-4.4 (void)<expr> doesn't suppress warnings from
__attribute__((warn_unused_result)), so use
G_GNUC_UNUSED (which expands to __attribute__((unused))) instead
of removing a dummy variable.
https://bugzilla.gnome.org/show_bug.cgi?id=640508
As the tile preview is shown or hidden when a window is dragged
around, it may stick around if the drag operation is cancelled.
Make sure that the preview is hidden in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
Drag operations may be cancelled, in which case the dragged window
should be restored to the position/state it had when the drag was
initialized. In order to do this for tiled states, the original
state has to be saved during the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
The previous tiling state of a grabbed window should be restored
if the drag operation is cancelled (by hitting the Escape key).
This might involve to meta_window_tile(), so export the function
in window-private.h.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
We want switching between the windows of an application to be an easily
accessible operation. The convenient and memorable keybinding is the
key above the tab key - but the keysym for that key isn't consistent
across different keyboard layouts.
Add code that figures out the key from the XKB geometry and a magic
keysym name "Above_Tab" that refers to this key and switch
the default binding for cycle_group to <Alt>Above_Tab. (This will
have no effect for the normal case of getting the key binding from
GConf until this patch is applied to Metacity as well.)
https://bugzilla.gnome.org/show_bug.cgi?id=635569
It may be desirable for theme authors to treat side-by-side tiled
windows differently, for instance to give the edge-touching border
a width of 0, so add additional frame states for tiled windows.
https://bugzilla.gnome.org/show_bug.cgi?id=637330
This patch removes the ability to disable compositing in mutter. As
clutter compositing was the reason for the fork from metacity, turning
compositing off does not make sense.
https://bugzilla.gnome.org/show_bug.cgi?id=626875
To deal with reentrancy from compositor plugins doing things like
moving windows between workspaces in an effect callback, update
the visible_to_compositor flag before calling into the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=613124
When a compositor is present, we keep the visibility state of the
compositor windows in sync with window->visible_to_compositor. We need
to do the same when enabling the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=613124
Maximized tiled windows end up with an inconsistent tile mode when
unmaximized by other means than dragging the window free (e.g.
using the unmaximize button or double clicking the title bar), so
reset the tile mode when unmaximizing.
This is not a problem for side-by-side tiling, as there are no
alternatives to dragging the window free.
When a tiled window is maximized (e.g. by clicking the title bar
button), unmaximizing the window restores the tiled state. While
this is reasonable for side-by-side tiling, it is confusing for
"maximize" tiled windows, as unmaximization has no visible effect.
Change unmaximize to only restore the tiled state of side-by-side
tiled windows.
The original patch triggered "maximize" when the window was dragged
to the top, so that the pointer was below or on the monitor edge and
above the work area's top.
If there's no chrome at the top of the monitor, so that monitor edge
and work area top fall together, the pointer cannot be moved above
the work area's top, so tiling was not triggered.
The old behavior of being able to shake loose a maximized window
overlaps with and is for the most part superceded by top edge tiling.
This commit changes the code to only enable shake loose behavior
when edge tiling is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
In addition to the existing side-by-side tiling modes, this commit
adds a new "maximize" tiling mode. It allows the user to maximize
their windows (in other words, tile with the edge panels) by dragging
their window to the top edge of the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
The meta_window_handle_mouse_grab_op_event function ensures
the tile_mode variable is in a consistent state after a drag
op is finished.
The way this is current done is:
if (!window->maximized_vertically &&
window->tile_mode != META_TILE_NONE)
window->tile_mode = META_TILE_NONE;
While valid, it doesn't "read" as well as using the
META_WINDOW_TILED_SIDE_BY_SIDE macro, since the macro is specifically
about side-by-side tiling.
This commit just changes things to use the macro and to not bother
checking the tile mode (since if we just reset it anyway, then it doesn't
matter if the value is right or wrong to begin with).
https://bugzilla.gnome.org/show_bug.cgi?id=630548
Currently, the new tiling feature, supports side-by-side, horizontal
tiling when dragging windows to one of the vertical edges of a monitor.
Other types of tiling (on other monitor edges) are potentially useful,
though.
This commit renames the preference from side_by_side_tiling to
edge_tiling.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
