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
These functions duplicate existing properties; they are added for
convenience and to avoid the GObject property code on some
performance critical painting paths.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
While the Meego developers agreed to switching mutter to GTK+-3.0
unconditionally a while ago, Canonical used a GTK+-2.0 build for their
Unity project. As Canonical now announced a switch to compiz as their
window manager, there is no longer a reason to maintain GTK+-2.0
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=633133
Remove --allow-unprefixed option to the scanner, and fix resulting
problems:
* theme.h and boxes.h are split into a main -header and a private
header that includes stuff that is not generally useful and
hard to introspect. Merge theme-parser.h into theme.h.
* meta_display_get_atom() and meta_window_get_window_type_atom()
are marked as (skip)
* Fix annotation: (element-type Strut) => (element-type Meta.Strut)
https://bugzilla.gnome.org/show_bug.cgi?id=632494
For functions (but not callback types), '(closure)' is used on the
callback parameter, and takes the name of the parameter which is
the closure/user data.
A maximized window can't be resized from the screen edges (preserves
Fitts law goodness for the application), but it's still possible
to start a resize drag with alt-middle-button. Currently we just
don't let the user resize the window, while showing drag feedback;
it's more useful to let the user "break" out from the resize.
This provides a fast way to get a window partially aligned with
the screen edges - maximize, then alt-drag it out from one edge.
Behavior choices in this patch:
- You can drag out a window out of maximization in both directions -
smaller and larger. This can be potentilaly useful in multihead.
- Dragging a window in only one direction unmaximizes the window
fully, rather than leaving it in a horizontally/vertically
maximized state. This is done because the horizontally/vertically
maximzed states don't have clear visual representation and can
be confusing to the user.
- If you drag back to the maximized state after breaking out,
maximization is restored, but you can't maximize a window by
dragging to the full size if it didn't start out that way.
A new internal function meta_window_unmaximize_with_gravity() is
added for implementing this; it's a hybrid of
meta_window_unmaximize() and meta_window_resize_with_gravity().
Port of the metacity patch from Owen Taylor in bug 622517.
https://bugzilla.gnome.org/show_bug.cgi?id=629931
When dragging a window over a screen edge and dropping it there,
maximize it vertically and scale it horizontally to cover the
corresponding half of the current monitor.
Whenever a "hot area" which triggers this behavior is entered, an
indication of window's target size is displayed after a short delay
to avoid distraction when moving a window between monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=606260
Add a preference /apps/mutter/general/attach_modal_dialogs. When true, instead
of having independent titlebars, modal dialogs appear attached to the titlebar
of the parent window and are moved together with the parent window.
https://bugzilla.gnome.org/show_bug.cgi?id=612726
Cleanly build with --warn-fatal. Implementation:
* Liberally apply (skip) where the API is clearly C only, e.g. uses
XLib. The theming code and MutterPlugin are skipped too.
* Add missing (transfer) and (element-type) annotations
For a few functions that had a comment, I turned it into gtk-doc, but
I didn't (with a few exceptions) try to write new documentation in
this pass.
When we do pseudo-management on an override-redirect window, we have to be
careful to augment the existing event mask, not replace it, or
delivery of pointer events will be disrupted.
When we unmanage a window, we shouldn't try to unselect events at all,
since that will interfere with event selection done by GDK.
http://bugzilla.gnome.org/show_bug.cgi?id=597763
A mismerge of the Metacity commit "4943d79 Prevent window self-maximisation"
caused the window's user set size and position to be saved *before*
actually resizing the window to the unmaximized position rather than after.
This meant that after unmaximization the window was in an inconsistent
state and anything that caused a resize to be queued (like a change in
window properties by the application) would cause it to pop back to
the maximized size and position.
https://bugzilla.gnome.org/show_bug.cgi?id=621413
It's useful for plugins to be able to easily detect whether
or not a window is from a remote host. Also, make use of this
in the window delete codepath, instead of looking up the hostname
each time.
https://bugzilla.gnome.org/show_bug.cgi?id=620585
A per-window _MUTTER_HINTS property allowing plugins to use custom hints. The
property holds a colon separated list of key=value pairs; plugin-specific keys
must be suitably namespaced, while 'mutter-' prefix is reserved for internal
Mutter use only.
This commit adds MetaWindow::mutter-hints property, and
meta_window_get_mutter_hints() accessor, as well as the internal machinery for
reading and updating of the hints.
https://bugzilla.gnome.org/show_bug.cgi?id=613123
Whether Metacity honors a raise request from an application should
not be affected by the raise_on_click setting; remove a check that
seems to have been added in error.
https://bugzilla.gnome.org/show_bug.cgi?id=445447
We currently allow XRaiseWindow when the same application (defined
by the window group) is focused, but the kind of old applications
that XRaiseWindow are frequently not setting the window group.
Expand the check to allow the same X client (defined by the looking
at client ID) to raise windows above the focus window.
https://bugzilla.gnome.org/show_bug.cgi?id=567528
Having a MetaDisplay::window-demands-attention signal allows to deal with
windows demanding attention in a cetralized fashion.
The signal is emitted when a window is created with initial demands-attention
state and/or when the state changes later on.
Based on original patch by Jon Nettleton.
https://bugzilla.gnome.org/show_bug.cgi?id=597052
With the change from bug 582639, we no longer call the reload
functions for properties that are not initially set, so the
initialization of fields in window.c has to match what
window-props.c would set for a missing property.
There was only one discrepancy, window->input, which needs
to be set to TRUE by default (or a window missing a WM_HINTS
property won't get focus); we also add explicit initializers
for a couple of fields that were getting 0-initialized
to the correct default value of FALSE for consistency with
the explicit intialization of the rest of the fields.
Bug reported by Dominique Leuenberger
https://bugzilla.gnome.org/show_bug.cgi?id=601228
For some consumers it's significantly more convenient to be able
to directly connect to a signal on the Window to know when
Mutter is done with it, rather than having to connect to each
Workspace object (and handle workspace additions, etc.).
Similarly, add window-created which acts globally.
https://bugzilla.gnome.org/show_bug.cgi?id=598289
When we focus a window on a different desktop, and the calc_showing
idle that hides/shows the windows gets run before we get focus events
back from X, we think that we are hiding the window with the focus
so we focus a "random" window to avoid leaving the user with no focus.
Work around this temporarily by checking display->expected_focus_window;
this isn't a perfect fix because there are cases where
display->expected_focus_window corresponds to a window we tried to
focus in the past but failed, but it makes things work fairly well.
https://bugzilla.gnome.org/show_bug.cgi?id=597352
There was a problem where if, for example, a restack was triggered
out of a clutter event handler, then after Clutter processed the
events, it would proceed immmediately on to repaint the stage without
ever returning control to the GLib main loop. So even though we
had an idle handler installed with a higher priority than the
Clutter stage repainting the clutter stage repainting would happen
first and we'd get a wrong frame.
Fix this by introducing the idea of "later functions", which abstract
the idea of "doing something later" away from g_idle_add() and use
a combination of GLib idle functions and Clutter "repaint functions"
to get our callbacks triggered at the right time, even when they
are installed from a clutter event handler.
https://bugzilla.gnome.org/show_bug.cgi?id=596334
This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW
could starve stage repainting.
mutter-window.c originally grew an #include "window-private.h" for
window->override_redirect, but that was just fixed. However since
then it also ended up relying on a few other minor private bits.
To fix that, add meta_window_is_mapped, promote meta_window_toplevel_is_mapped
to public, and use the public MetaDisplay accessor.
