Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Commit 6b05da5e49996a2101edfd703dd3f5d91011d726 introduced a Cairo
surface leak, by calling gdk_cairo_surface_create_from_pixbuf() but then
never freeing those surfaces with cairo_surface_destroy().
This manifested in leaking resources when switching between virtual
desktops, as observed using xrestop ("Pxms" column), which made the
desktop slow and ultimately unusable after a few weeks of uptime.
Fixes #685
|
|
Some files do not report their application icons correctly in the window
properties. This patch allows the marco UI to search for the
corresponding .desktop file and render the icon in the desktop info on
both the alt-tab popup and the window mini-icon.
|
|
|
|
|
|
|
|
Based on Metacity commit https://gitlab.gnome.org/GNOME/metacity/-/commit/0b2f5ad0a2f30726ac0dc59aa59f7f513e91c832
Fixes transparent windows.
|
|
|
|
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 dark color when compositing is disabled. Updates #566 which changed
the selected workspace to a light color on a light background.
|
|
https://gitlab.gnome.org/GNOME/glib/commit/6554c91b
https://gitlab.gnome.org/GNOME/glib/commit/6e4a7fca
based on https://gitlab.gnome.org/GNOME/metacity/commit/359f60a6
|
|
GDK (and also GTK+!) do this for us already.
based on https://gitlab.gnome.org/GNOME/metacity/commit/1dcde194
|
|
By scaling the pixbuf when loading, existing assets can be used.
|
|
|
|
When drawing the workspace switcher OSD, we want it to be slightly
transparent to match the OSD style. Also changed how the popup size is
calculated and changed window icons to cairo surfaces.
|
|
Instead of converting from surface to a GdkPixbuf and then back to
a surface, we keep it as a surface for the entire manipulation flow.
This improves rendering speed a bit and sets the ground for a higher
resolution thumbnail in the future.
|
|
|
|
When loading window control buttons and icon as pixbufs, we just set
them as the source for the cairo context used to paint them. Instead, we
now convert them to cairo surfaces and scale them to the correct display
density before painting them.
This allows us to load higher resolution assets (i.e. at twice the size)
and by explicitly setting the intended size in the theme draw_ops, we
can then scale them down to fit lower resolution displays, or render
them at full density for HiDPI displays.
|
|
ui/tabpopup.c:176:7: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
176 | tmp = g_markup_printf_escaped (formatter, str);
| ^~~
|
|
finally, apps that prefer dark theme variant (gtk-application-prefer-dark-theme
in GtkSettings) should also have dark window decorations
taken from:
https://github.com/GNOME/metacity/commit/6b0d325442b995a78b8783384f7ec370db1369a4
|
|
- this will be needed for proper window decoration color updates on theme change
when theme variants fixes are applied
- realize/unrealize functions are dropped instead of map/unmap ones, because
we didn't change these during GTK+3 porting
- MetaFrames now has GtkWindow as parent instead of GtkInvisible, otherwise
the hack doesn't work (revert part of 96c7256d638b8c76c8abf786ba307e82a595dd67)
adapted from:
https://github.com/GNOME/metacity/commit/ba8500663457ad9f18ebfdf405162c2cb5caf88f
|
|
and make variable names less similar
taken from:
https://github.com/linuxmint/muffin/commit/6120bddefd709d3f1
|
|
guess it was overlooked when porting to GTK+3
|
|
|
|
|
|
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
|
|
... to differentiate PangoLayout from MetaFrameLayout.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/8e5781bc
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/3a3c47e3
|
|
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
|
|
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/cd383e72
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/94c8d620
|
|
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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=662895
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/6836a621
|
|
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
|
|
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
|
|
... 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
|
|
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
|
|
This adds 'invisible_border' to be used for resize cursor area.
|
|
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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=628195
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/3994d7a0
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|