Age | Commit message (Collapse) | Author | Files | Lines |
|
find . -name "*.png" -exec mogrify -strip {} \;
|
|
|
|
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.
|
|
|
|
It removes --enable-more-warnings, since it is recommended to use
--enable-compile-warnings=maximum
|
|
Eeeks, testing floating points for equality ...
upstream commit:
https://gitlab.gnome.org/GNOME/mutter/commit/0fccb0fc8
|
|
core/testboxes.c:34:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:103:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:120:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:148:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:167:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:190:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:589:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:681:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:725:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:842:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:904:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:1021:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:1154:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:1243:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:1344:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
core/testboxes.c:1396:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
|
|
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);
| ^~~
|
|
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 Clang static analyzer warning:
core/async-getprop.c:277:11: warning: Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption
reply = (xGetPropertyReply *)
^~~~~~~~~~~~~~~~~~~~~
|
|
Fixes Clang static analyzer warnings:
core/xprops.c:761:9: warning: Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption
raw = (xPropWMHints*) results->prop;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
core/xprops.c:883:9: warning: Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption
raw = (xPropSizeHints*) results->prop;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
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
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
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
|
|
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/ca475d44
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/72003d38
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/74db1f11
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=656619
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/4674358f
|
|
upstream commit:
https://gitlab.gnome.org/GNOME/metacity/commit/9fd053da
|
|
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
|
|
... 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
|