summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2019-06-16libmarco-private: add version informationraveit651-1/+1
2019-06-16theme: Fix window state when tiling from maximizedVictor Kareh1-0/+2
2019-06-16compositor: fix possible crash closing/destroying windowVictor Kareh3-9/+32
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 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/a9f28dbc
2019-06-16update window->has_resize_func at the right time when unfullscreeningVictor Kareh1-3/+5
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
2019-06-16frames: include invisible area in cacheVictor Kareh1-11/+11
GTK+ theme might use this area to paint box-shadow. Also use CAIRO_CONTENT_COLOR_ALPHA for cairo surfaces. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/13137b1d
2019-06-16frames: Rename layout to text_layoutVictor Kareh2-25/+19
... to differentiate PangoLayout from MetaFrameLayout. https://bugzilla.gnome.org/show_bug.cgi?id=741917 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/8e5781bc
2019-06-16theme: fix warningVictor Kareh1-0/+1
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3a3c47e3
2019-06-16frames: again change meta_frames_applet_shapesVictor Kareh2-64/+29
With compositing manager: 1. Apply only client shape. Without compositing manager: 1. Apply client shape. 2. Apply shape around visible frame. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3913dcf1
2019-06-16Fix scaling overcorrection when caching frame bordersVictor Kareh1-18/+16
2019-06-16frame: remove uneeded includeVictor Kareh1-4/+0
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/ca475d44
2019-06-16compositor: fix border_sizeVictor Kareh1-0/+23
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/72003d38
2019-06-16frame: make frame window transparentVictor Kareh1-6/+20
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/74db1f11
2019-06-16frames: apply shapes in different wayVictor Kareh3-4/+77
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/cd383e72
2019-06-16frames: add dest_kind to apply_cairo_region_to_windowVictor Kareh1-3/+4
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/94c8d620
2019-06-16frames: Fall back to title bar if nothing else matchedVictor Kareh1-1/+4
The condition got removed in eeb2efe01001fef7655b2ba95ca1456f7fe9214b but that had a side effect of adding a couple of rows of dead pixels so add it back. https://bugzilla.gnome.org/show_bug.cgi?id=658069 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/37e1fa8c
2019-06-16theme-viewer: Fix invisible bordersVictor Kareh2-10/+11
https://bugzilla.gnome.org/show_bug.cgi?id=662895 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/6836a621
2019-06-16window: Correct coordinates for the configure eventVictor Kareh1-4/+8
We should still correct the coordinates for withdrawn windows. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/9da3004e
2019-06-16frame: Make sure to offset by invisible borders when unmanaging windowsVictor Kareh1-2/+5
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
2019-06-16window: Fix _NET_FRAME_EXTENTS to work properlyVictor Kareh1-4/+7
_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
2019-06-16theme: don't add invisible borders for windows that can't be resizedVictor Kareh1-7/+14
Invisible borders are all about resizing -- in the case that a window cannot be resized, it makes no sense to add them. https://bugzilla.gnome.org/show_bug.cgi?id=659854 Based on mutter commit: https://git.gnome.org/browse/mutter/commit/?id=be9f7d77292c1dfd868640fe95f7223fbbfd4273 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/64615667
2019-06-16window: Fix window placement to exclude invisible bordersVictor Kareh1-4/+4
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
2019-06-16theme: Don't add any bottom border to shaded windowsVictor Kareh1-4/+4
Shaded windows are assumed to be reduced to the titlebar: the current code enforces a visible bottom border of 0 and only takes the size of the title bar (+ invisible top border) into account when resizing the frame. However, we still add an invisible border at the bottom, which is than subtracted from the title bar, resulting in shaded windows being cut off. Fix by forcing both visible and invisible bottom borders to 0. https://bugzilla.gnome.org/show_bug.cgi?id=659266 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/7a80fcfd
2019-06-16Account for invisible borders when constraining modal dialogsVictor Kareh1-1/+1
https://bugzilla.gnome.org/show_bug.cgi?id=656619 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/4674358f
2019-06-16compositor: fix shadow size and placementVictor Kareh1-6/+9
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/9fd053da
2019-06-16MetaWindow: Repurpose get_outer_rect and add get_input_rectVictor Kareh2-10/+50
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
2019-06-16MetaWindow: Compensate for invisible border changesVictor Kareh1-20/+20
https://bugzilla.gnome.org/show_bug.cgi?id=644930 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/85e15225
2019-06-16ui: Replace inline borders in MetaFrameGeometry with MetaFrameBorderVictor Kareh3-172/+198
... and start compensating for invisible borders in all of the math. https://bugzilla.gnome.org/show_bug.cgi?id=644930 NOTE: Updated for marco... upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/daf6bc08
2019-06-16MetaFrameBorders: add invisible bordersVictor Kareh4-4/+29
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
2019-06-16theme: add invisible_border to metacity themeVictor Kareh1-0/+5
This adds 'invisible_border' to be used for resize cursor area.
2019-06-16compositor: don't draw shadow under decorationsVictor Kareh1-54/+56
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/215dd8e9
2019-06-16compositor: add function to convert cairo region to xserver regionVictor Kareh1-0/+29
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/28970472
2019-06-16constraints: fix mem leak in meta_window_constrain()Victor Kareh1-3/+10
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
2019-06-16MetaFrames: factor out MetaUIFrame accessors for borders, corner radiusesVictor Kareh1-15/+38
This makes it a bit simpler for other functions on a MetaUIFrame to get this information. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758 Reviewed-by: Jasper St. Pierre <[email protected]> Signed-off-by: Simon McVittie <[email protected]> upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/79384de0
2019-06-16frame: Add "get_corner_radiuses" chainVictor Kareh6-0/+83
https://bugzilla.gnome.org/show_bug.cgi?id=628195 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3994d7a0
2019-06-16frame: destroy window->frame_bounds when destroying the frameVictor Kareh1-0/+5
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
2019-06-16Only shadow ARGB windows with a frame outside the frameVictor Kareh9-79/+203
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
2019-06-16Fix XShapeVictor Kareh1-1/+1
Commit https://gitlab.gnome.org/GNOME/metacity/commit/c3a04bf unintentionally broke XShape handling. By studying the code extremely carefully, I found this inconsistency with the code that was there before. https://bugzilla.gnome.org/show_bug.cgi?id=635268 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/2b1c6443
2019-06-16compositor: don't draw shadow under windowsVictor Kareh3-11/+66
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/5404d8f2
2019-06-16constraints: initialize window->user_rect in initial placementVictor Kareh1-0/+1
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/67ddadf3
2019-06-16theme: Make meta_frame_draw_theme take a GtkStyleContext instead of a widgetVictor Kareh5-56/+21
The style context of the widget is rarely what we want. We won't fix this to be a MetaFrames style context yet; this just changes the internal API. https://bugzilla.gnome.org/show_bug.cgi?id=690317 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/76aa0704
2019-06-16remove common.cVictor Kareh3-35/+9
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/96d7a662
2019-06-16build everything as libraryVictor Kareh1-23/+11
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/d982d0a5
2019-06-16Allow raise_on_click to be set independent of focus_modeVictor Kareh2-6/+2
Based on a patch by Thomas Jaeger <[email protected]> upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/03e8e63d
2019-06-16window: initialize few variablesVictor Kareh1-0/+2
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/5b880ff3
2019-06-16frames: Explicitly initialize style contextsVictor Kareh1-0/+1
We were relying on GTK+ emitting GtkWidget::style-updated during widget initialization to create the GtkStyleContexts used for window decorations. A recent GTK+ update broke this assumption, so do the necessary initialization ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=671796 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/e4fde7b0
2019-06-16fix a crash-on-exitVictor Kareh1-0/+9
meta_frames_destroy() was not safe to be called multiple times, which was causing a crash on exit due to something else changing somewhere that makes it get called multiple times. https://bugzilla.gnome.org/show_bug.cgi?id=654489 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/e35be641
2019-06-16ui-frame: Add support for style variantsVictor Kareh2-4/+93
Rather than sharing a single style context between all frames, use a default style and one style per encountered variant. The value of the _GTK_THEME_VARIANT property should determine which style is attached to a particular frame, though for the time being the default style is used for every frame, as the window property cannot be accessed at the time the style is attached. This will be fixed in a later commit. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/04d8135f
2019-06-16ui-frames: Delay attaching the style to new framesVictor Kareh2-1/+4
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
2019-06-16core: Update frame style when _GTK_THEME_VARIANT changesVictor Kareh1-0/+2
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
2019-06-16ui: Add meta_ui_update_frame_style()Victor Kareh4-0/+25
This method allows forcing a style update of a particular frame from the core, so that it can pick up style variants. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/97554dc4
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-27 18:07:53 +0000