Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
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;' {} \;
|
|
GDK (and also GTK+!) do this for us already.
based on https://gitlab.gnome.org/GNOME/metacity/commit/1dcde194
|
|
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
|
|
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
|
|
... 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 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
|
|
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
|
|
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.
|
|
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
|
|
|
|
based in the mutter commits:
https://gitlab.gnome.org/GNOME/mutter/commit/b8b0dc5c78008647f5833f63d88456025f17bd08
https://gitlab.gnome.org/GNOME/mutter/commit/669c9da2a48d9a5573edee09065b8558c1d07035
|
|
|
|
It's useful to get frame shapes and manipulate them within Mutter, for
example so that the compositor can use them to clip drawing.
For this, we'll need the regions as cairo regions not X regions, so
convert frame shaping code to work in terms of cairo_region_t.
https://bugzilla.gnome.org/show_bug.cgi?id=635268
|
|
Add app-menu button support in themes. This is done only to support
metacity theme format 3.5 version. Marco will not show this
button!
Based on metacity commit:
https://gitlab.gnome.org/GNOME/metacity/commit/6a2cc159
|
|
It's nice to indicate when a title is truncated with an ellipsis.
Because themes may draw a title multiple times to draw a shadow, or
may include the window icon within the title area, we can't determine
the proper ellipsization width automatically, so add an optional
attribute to the <title/> element "ellipsize_width" which, if set,
is the width to ellipsize at.
This is only enabled if a theme version of 3.1 is required.
When it's not set, we keep the old behavior of just letting the
title be clipped with a hard edge.
https://bugzilla.gnome.org/show_bug.cgi?id=591842
NOTE: Patch copied from mutter and adapted for metacity.
|
|
|
|
|
|
|
|
|
|
|
|
This legacy construct was carried over from the gtk2/gtk3 port, and
attempts to initialise MetaFrames with a GtkWindow `type` property.
This property doesn't actually exist, and will cause marco to completely
crash when running with `MARCO_DEBUG=1` for local build testing.
Signed-off-by: Ikey Doherty <[email protected]>
|
|
|
|
Direct struct access has been deprecated, so use the appropriate
replacements to build with GSEAL enabled.
|
|
Gnome bug: https://bugzilla.gnome.org/show_bug.cgi?id=683056
|
|
|
|
merge metacity(gtk3) changes
fix warnings
clean up unused variables
replace UNUSED_VARIABLE by G_GNUC_UNUSED
|
|
While the configured layout is taken into account for positioning
the buttons, the mapping from button function states to button
position states just assumed the default button layout in LTR
locales.
Do a proper mapping depending on the actual layout instead.
Based on metacity commit: 6a52883c2b670ad645257373515d1e704408b93d
From: Florian Müllner <[email protected]>
Gnome bug: https://bugzilla.gnome.org/show_bug.cgi?id=638700
|
|
|
|
|