Age | Commit message (Collapse) | Author | Files | Lines |
|
When tiling a maximized window, we should keep track of the saved
rectangle so that tiling does not reset our window size. Otherwise,
untiling the previously maximized window will end up with an unmaximized
full-size window, rather than the original window size.
|
|
When handling a ClientMessage event that removes _NET_WM_STATE_MAXIMIZED_HORZ
or _NET_WM_STATE_MAXIMIZED_VERT from _NET_WM_STATE, marco always restore the
window rectangle to the saved rectangle. So if an application window is already
unmaximized and the application sends such a ClientMessage event, marco will
reset the window rectangle regardless. EWMH doesn't specify what must be done
when handling such events. It seems best to avoid restoring window rectangles
like other window managers in this case.
Fix a related bug: https://bugs.winehq.org/show_bug.cgi?id=50381
This revert a change introduced by 6219f8e8bcaeefb9185a3c3f5f20de4e2fa8f18f.
Signed-off-by: Zhiyi Zhang <[email protected]>
|
|
|
|
|
|
Fix keyboard input on fullscreen VLC.
Based on Metacity commit https://gitlab.gnome.org/GNOME/metacity/-/commit/bf17c79
|
|
|
|
find . \( -name '*.h' -o -name '*.c' \) -exec sed -i 'N;/^\n$/D;P;D;' {} \;
|
|
find . \( -name '*.h' -o -name '*.c' \) -exec sed -i 's/[[:space:]]*$//' {} \;
find . \( -name '*.h' -o -name '*.c' \) -exec sed -i 's/\t*$//' {} \;
|
|
A prior commit 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
Based on commit https://gitlab.gnome.org/GNOME/metacity/-/commit/f628d8f8901f46fa9e00707ae9d7ccfd1e85f427
|
|
commit.
Partially restore call to destroy_win in compositor when calling
meta_window_free. This is needed to ensure that we never call
meta_window_get_frame_bounds while windows is destroying.
https://bugzilla.gnome.org/show_bug.cgi?id=751833
Based on commit https://gitlab.gnome.org/GNOME/metacity/-/commit/a9f28dbc26f5211ef08889109db3dc8c7ba76aca
|
|
Based on commit https://gitlab.gnome.org/GNOME/metacity/-/commit/24d35569bdb78d1da3b53ed1a6d81d365d60bed0
|
|
|
|
https://gitlab.gnome.org/GNOME/metacity/commit/1fafd279006ece8cf664fd777143cdfafbefad6d
window: handle legacy fullscreen requests
Doing this on the actual resize requests makes more sense
than handling it as a window-manager imposed constraints,
so move the code accordingly.
Adapted from mutter patch by Florian Müllner:
https://git.gnome.org/browse/mutter/commit/?id=fba022cc06b8c7e80ef36f48d6577a251384cc4b
https://bugzilla.gnome.org/show_bug.cgi?id=781946
Bug 781946 - Non-native decorated windows stuck maximised on secondary screen with Marco/Metacity
|
|
Adding a new option to allow tile size cycling. When enabled, using the
keyboard shortcut for tiling multiple times in a row cycles the window
through different sizes (1/2 -> 1/3 -> 1/4 -> 3/4 -> 2/3 -> Untiled).
|
|
|
|
|
|
|
|
When changing window state, we want to change the allowed action hints
so that other applications, mainly the taskbar, can disable menu entries
that do not make much visual sense. For example, unmaximizing
a minimized window: even though this operation is possible, it causes
user confusion as there is no visibility until the user unminimizes it.
|
|
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
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/c66d83a7
|
|
We should still correct the coordinates for withdrawn windows.
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/9da3004e
|
|
_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
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/a3630d7c
|
|
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
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/95373187
|
|
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
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/dfedc7df
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=644930
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/85e15225
|
|
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
NOTE: Applied only partially, compositor part is still missing...
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/0f2e32d1
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/5b880ff3
|
|
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
NOTE: Patch is adapted for marco.
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/341d0945
|
|
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
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/72224a165
NOTE: Patch copied from metacity and adapted for marco.
|
|
|
|
Set the NET_WM_STATE_FOCUSED property on windows of type dock or
spashscreen so that they don't get the state GTK_STATE_FLAG_BACKDROP
set by default.
Based on:
https://gitlab.gnome.org/GNOME/metacity/commit/b3ef887
origin xfwm4 commit:
https://git.xfce.org/xfce/xfwm4/commit/?id=0feb29e78bb3
|
|
|
|
Use g_slist_free_full
|
|
|
|
avoid Clang static analyzer warning:
core/window.c:3580:34: warning: The right operand of '+' is a garbage value
new_w = window->rect.width + fgeom.left_width + fgeom.right_width;
^ ~~~~~~~~~~~~~~~~
|
|
Since xinerama already contains information on the monitor and its rectangle, there is no need to go through Gdk to get this information again.
|
|
both functions have the same code
|
|
|
|
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
NOTE: Patch copied from mutter and adapted for metacity.
|
|
NOTE: Patch copied from mutter and adapted for metacity.
|
|
|
|
ported from:
https://github.com/GNOME/metacity/commit/4ccb99a50c54f345c4c7d9ac77f1ea76bc6c7c74
|
|
|
|
|
|
frame
|
|
|
|
|
|
After resizing a tiled window, tile_resized gets set to true. Since it
never got set back to false when fullscreening, it lead to weird
behavior when unfullscreening the window.
|
|
|
|
|
|
|