Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
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
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/5404d8f2
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/67ddadf3
|
|
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
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/96d7a662
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/d982d0a5
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
|
|
upstream commits:
https://gitlab.gnome.org/GNOME/metacity/commit/71d5decc
https://gitlab.gnome.org/GNOME/metacity/commit/127638ca
https://gitlab.gnome.org/GNOME/metacity/commit/fc1a21ea
https://gitlab.gnome.org/GNOME/metacity/commit/431e0418
|
|
upstream commits:
https://gitlab.gnome.org/GNOME/metacity/commit/3932dca0
https://gitlab.gnome.org/GNOME/metacity/commit/10240013
https://gitlab.gnome.org/GNOME/metacity/commit/3fa97193
|
|
|
|
|
|
mate-session[1210]: WARNING: Could not parse desktop file /usr/share/applications/marco.desktop: El fitxer de claus no conté una clau «Name» en el grup «Desktop Entry»
mate-session[1210]: GLib-GObject-CRITICAL: object GsmAutostartApp 0x7f158800ede0 finalized while still in-construction
mate-session[1210]: GLib-GObject-CRITICAL: Custom constructor for class GsmAutostartApp returned NULL (which is invalid). Please use GInitable instead.
mate-session[1210]: WARNING: could not read /usr/share/applications/marco.desktop
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
origin commit by:
https://gitlab.gnome.org/GNOME/metacity/commit/542a2b4
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|