Age | Commit message (Collapse) | Author | Files | Lines |
|
When the active workspace is changed, marco figures out which window
should get focus by calling `focus_ancestor_or_top_window`. In some
cases that call might include a window that should not get focus as
`not_this_one`.
When `not_this_one` refers to a window, the function will check to see
if it has a parent, and if it does, it will ignore the new workspace's
`mru_list` and will focus that parent window. However, it doesn't check
to see if the parent window is actually on the new workspace. If the
parent isn't on the new workspace, focusing it will drag it over,
including the transient window that was supposed to be ignored. This
isn't the result a user would likely expect, and is made more confusing
by the parent window being minimized, stuck that way until the user
switches to another workspace and back.
This change makes `focus_ancestor_or_top_window` ignore the
`not_this_one` window if it isn't on the new workspace's `mru_list`.
Instead it will just search the new workspace's `mru_list` for a window
to focus.
|
|
When composited, the tab popup uses an OSD style which typically has a
dark background, so we use a light background highlight color.
However, when not composited the popup uses a light color and should
thus use a dark highlight. This was done for the workspace popup, but
not for the window one, leading to the highlight being hardly visible
in several themes.
|
|
This is Metacity commit 50358a95 ("Allow applications to raise windows
when raise_on_click is off. Closes #445447.") applied to Marco without
modification.
It also includes a change to the GSettings key's description to remove
the now obsolete warning on the raise-on-click key, & replaces it with
an actually useful description. This is copied from the equivalent key
in gsettings-desktop-schemas.
Fixes: https://github.com/mate-desktop/marco/issues/762
|
|
|
|
|
|
Enabling code that is supposed to be used in compositing conditions is
harmful if compositing is not actually available. Just checking the
preference is not enough to make sure that compositing is available -
the X server might be missing crucial extensions for compositing to
work, which in turn correctly disables the internal compositor.
The end result is graphical issues like black borders around windows in
such situations.
Make sure that compositing is both requested AND available to fix this
bug.
|
|
Fixes #757.
|
|
|
|
|
|
Needed for X2Go as it does not have XRES 1.2 extension.
|
|
Before using any Xres extension one must call XResQueryExtension()
Also make sure Xres 1.2 is available as marco need XResQueryClientIds()
|
|
|
|
window-props: use XResQueryClientIds to get pid
_NET_WM_PID is unreliable! It can be faked or pid might be from
different namespace. Ignore _NET_WM_PID and use XResQueryClientIds
to get pid.
https://gitlab.gnome.org/GNOME/metacity/-/commit/bcbe966511362a8eb8c8c64035ab160086c931f8
|
|
When opening and then closing certain applications
the focus was correctly regained by the previous window
but it wasn't brought into the foreground.
To fix this we call meta_workspace_focus_default_window() for both NotifyDetailNone and NotifyPointerRoot.
These two are always mentioned together in the X docs:
https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabbed.html
Some programs will have NotifyDetailNone when closed, while others end up with NotifyPointerRoot.
|
|
fixes https://github.com/mate-desktop/marco/issues/735
|
|
|
|
directly on WM startup.
The marco WM is used in Arctica Greeter [1]. There recently
has a security issue been detected where people could open
applications via marco keybindings inside the greeter (display
manager) session.
.
A work-around could be evoking marco-message after marco startup
and disable all keybindings then. However, a more preferred fix
is provided by this patch: start-up marco with keybindings disabled
from the beginning.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- drop white spaces
|
|
|
|
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
|
|
In addition to existing properties use also new _GNOME_WM_STRUT_AREA
property that allows creating struts between monitors.
https://mail.gnome.org/archives/wm-spec-list/2018-December/msg00000.html
https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/22
origin commit:
https://gitlab.gnome.org/GNOME/metacity/commit/922de13
|
|
In addition to existing _NET_WORKAREA property set also new
_GTK_WORKAREAS_Dn property where n is desktop number (between 0
and _NET_NUMBER_OF_DESKTOPS - 1).
https://mail.gnome.org/archives/wm-spec-list/2018-December/msg00000.html
https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/22
origin commit:
https://gitlab.gnome.org/GNOME/metacity/-/commit/3d8b03d
|
|
This pull request prevents shadows being rendered for left and right side titled windows. This behaviour is consistent with maximised windows, which also do not render shadows.
The rationale for this change is so that when two windows are titled along side each other, it prevents central shadows bleeding into the touching points of the windows.
metacity-theme-x.xml has provision to style left/right titled windows. This patch makes it possible to to create window themes that present clean side-by-side tiled windows.
|
|
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.
|
|
When corner-tiling a maximized window, we should keep track of the saved
rectangle so that tiling does not reset our window size. Otherwise,
untiling the previously maximized window will end up with an unmaximized
full-size window, rather than the original window size.
|
|
When tiling a maximized window, we should keep track of the saved
rectangle so that tiling does not reset our window size. Otherwise,
untiling the previously maximized window will end up with an unmaximized
full-size window, rather than the original window size.
|
|
When handling a ClientMessage event that removes _NET_WM_STATE_MAXIMIZED_HORZ
or _NET_WM_STATE_MAXIMIZED_VERT from _NET_WM_STATE, marco always restore the
window rectangle to the saved rectangle. So if an application window is already
unmaximized and the application sends such a ClientMessage event, marco will
reset the window rectangle regardless. EWMH doesn't specify what must be done
when handling such events. It seems best to avoid restoring window rectangles
like other window managers in this case.
Fix a related bug: https://bugs.winehq.org/show_bug.cgi?id=50381
This revert a change introduced by 6219f8e8bcaeefb9185a3c3f5f20de4e2fa8f18f.
Signed-off-by: Zhiyi Zhang <[email protected]>
|
|
|
|
|
|
and conversion specifier 'ld', reported by Apache NetBeans IDE
|
|
|
|
|
|
widget is close to the edge of the work area.
See inline comments - as of 3.24 tooltip positioning is handled
differently, and under certain conditions in hidpi, tooltips for the
bottom panel applets can end up off the bottom of the work area.
To reproduce, in hidpi, set the bottom panel to approximately 30px
tall and try to activate a tooltip for an applet on that panel.
|
|
|
|
|
|
|
|
|