Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
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
|
|
Origin commit :
https://gitlab.gnome.org/GNOME/metacity/commit/c87f73f3b4413720a2f3e6a672826d3fec7f77a9
"
XmbTextPropertyToTextList documentation says that XFreeStringList
should be used to free the storage for the list and its contents.
"
|
|
Eeeks, testing floating points for equality ...
upstream commit:
https://gitlab.gnome.org/GNOME/mutter/commit/0fccb0fc8
|
|
|
|
|
|
|
|
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.
|
|
Use the window's visual in all cases, fix problems with drivers forcing use of blit rather than pageflip mode when comppositing is not used or window is unredirected
Apply https://gitlab.gnome.org/GNOME/metacity/commit/5863176a2bd659c8d9a3d1c7b023a27c1a8c0aa5
|
|
Fixes condition duplicated:
/* If a contains b, just remove b */
if (meta_rectangle_contains_rect (a, b))
{
delete_me = other;
}
/* If b contains a, just remove a */
else if (meta_rectangle_contains_rect (a, b))
{
delete_me = compare;
}
|
|
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
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/ca475d44
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/74db1f11
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/cd383e72
|
|
We should still correct the coordinates for withdrawn windows.
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/9da3004e
|
|
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
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/9fe51fd0
|
|
_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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=656619
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/4674358f
|
|
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
|
|
This just adds the invisible border field and populates it with
data but doesn't use it in any way.
Based on mutter commit:
https://git.gnome.org/browse/mutter/commit/?id=a1a2527c75ab0c135f89396ea036336fb67ac538
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/bf02c7c3
|
|
MetaFrameBorders leaked when orig_borders != NULL and
window->fullscreen == TRUE
https://bugzilla.gnome.org/show_bug.cgi?id=679153
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/7e7f25f4
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=628195
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/3994d7a0
|
|
Since window->frame_bounds is used as a cache we need to invalidate it when
destroying the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=660773
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/330ff9b5
|
|
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/5404d8f2
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/67ddadf3
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/96d7a662
|
|
Based on a patch by Thomas Jaeger <[email protected]>
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/03e8e63d
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/5b880ff3
|
|
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
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/ee056853
|
|
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
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/8a779ab9
|
|
To associate frames with the correct style variant, the UI will
need access to the window's theme variant property.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/5c7403cc
|
|
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
|
|
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
NOTE: Patch copied from metacity and adapted for marco.
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/7d519b3f
|
|
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.
|
|
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;
^ ~~~~~~~~~~~~~~~~
|
|
This way the xserver never paints the frame background, even if
the client window is destroyed. This allows us to have clean
destroy window animation.
There is no problem with interactive resizing because applications
are using the XSync protocol, so we're not painting unless the
client has redrawn.
https://bugzilla.gnome.org/show_bug.cgi?id=734054
origin commit:
https://gitlab.gnome.org/GNOME/metacity/commit/78c283c
|
|
|
|
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
|
|
|
|
Fixes Clang static analyzer warning:
core/screen.c:754:16: warning: Use of memory after it is freed
result = g_list_prepend (result, info);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
Fixes Clang static analyzer warnings:
warning: Call to function 'strcpy' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcpy'. CWE-119
|
|
Since xinerama already contains information on the monitor and its rectangle, there is no need to go through Gdk to get this information again.
|
|
Alt+Tab and Workspace popups should be sized relative to the monitor size.
This way they look nice and large regardless of the display resolution.
Also, given much larger modern resolutions, icon sizes should be larger by default.
|
|
Fixes https://github.com/mate-desktop/marco/issues/445
|
|
|
|
both functions have the same code
|