summaryrefslogtreecommitdiff
path: root/src/core
AgeCommit message (Collapse)AuthorFilesLines
2019-09-24testboxes: Fix find_closest_point_to_line() testVictor Kareh1-4/+6
Eeeks, testing floating points for equality ... upstream commit: https://gitlab.gnome.org/GNOME/mutter/commit/0fccb0fc8
2019-09-19remove warnings: function declaration isn’t a prototyperbuj1-16/+16
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]
2019-09-10Fix use of RBGA visual in frame.c when compositing is not in uselukefromdc1-37/+1
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
2019-09-04window.c: remove unused variablePavel Shlyak1-3/+0
2019-08-31 display.c: add missing "break"Pavel Shlyak1-1/+1
2019-08-12async-getprop: Fix cast from non-struct type to struct typePablo Barciela1-1/+1
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 *) ^~~~~~~~~~~~~~~~~~~~~
2019-08-12xprops: Fix cast from non-struct type to struct typePablo Barciela1-2/+2
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; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-08-10window: add _GTK_THEME_VARIANT to initial window propertiesmonsta1-1/+2
2019-08-02Fixed moving windows to edges to work with CSD clients.Omar Zeidan1-10/+13
2019-07-13window: Update allowed action hintsVictor Kareh1-7/+30
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.
2019-06-07Make alt+tab max columns configurable and consider window label widthosch2-1/+39
2019-06-05update 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-05frame: remove uneeded includeVictor Kareh1-4/+0
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/ca475d44
2019-06-05frame: make frame window transparentVictor Kareh1-6/+20
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/74db1f11
2019-06-05frames: apply shapes in different wayVictor Kareh1-0/+24
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/cd383e72
2019-06-05window: 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-05frame: 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-05window: 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-05window: 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-05Account 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-05MetaWindow: 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-05MetaWindow: 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-05MetaFrameBorders: add invisible bordersVictor Kareh1-4/+4
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-05constraints: 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-05frame: Add "get_corner_radiuses" chainVictor Kareh2-0/+20
https://bugzilla.gnome.org/show_bug.cgi?id=628195 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3994d7a0
2019-06-05frame: 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-05Only shadow ARGB windows with a frame outside the frameVictor Kareh4-11/+61
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-05compositor: don't draw shadow under windowsVictor Kareh1-3/+0
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/5404d8f2
2019-06-05constraints: initialize window->user_rect in initial placementVictor Kareh1-0/+1
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/67ddadf3
2019-06-05remove common.cVictor Kareh2-34/+9
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/96d7a662
2019-06-05Allow 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-05window: initialize few variablesVictor Kareh1-0/+2
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/5b880ff3
2019-06-05ui-frames: Delay attaching the style to new framesVictor Kareh1-0/+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-05core: 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-05core: Allow retrieving the theme variant via core_get()Victor Kareh1-0/+3
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
2019-06-05window: Parse _GTK_THEME_VARIANT propertyVictor Kareh4-0/+27
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
2019-06-05MetaFrameBorders: Add meta_frame_borders_clearVictor Kareh1-0/+34
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
2019-06-05Replace public MetaFrameGeometry with MetaFrameBordersVictor Kareh8-213/+181
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.
2019-06-03alt+tab popup: bugfix mouse click handling for scale factor > 1osch1-9/+21
2019-06-03alt+tab popup: follow mouse while mouse button is pressedosch2-1/+26
2019-06-03Handle mouse clicks in Alt+Tab Popuposch1-17/+66
2019-06-03Allow use of up/down arrow keys in alt+tab popuposch2-10/+34
2019-04-23ui: always set the frame background to NoneGiovanni Campagna1-13/+0
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
2019-04-23window: set atom__NET_WM_STATE_FOCUSED for meta_window_appears_focusedraveit651-1/+1
2019-04-23window: make docks and spashscreens appear focusedraveit651-1/+9
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
2019-04-23scale icon down if icon is larger than alt+tab preview thumbnailosch1-4/+18
2019-04-23Limit icon size to 1024osch1-1/+1
2019-04-23reload icons if icon size preference changedosch4-4/+61
2019-04-23make icon size configurableosch3-5/+27
2019-04-11Replace meta_free_gslist_and_elements with g_slist_free_fullrbuj2-8/+2
Use g_slist_free_full
generated by cgit v1.2.1 (git 2.18.0) at 2024-06-23 23:47:11 +0000