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
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
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
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
"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
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
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
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
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
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
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
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
