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.
|
|
Verbose mode is not active by default when running Marco, but can be
toggled dynamically to help debug issues, possibly as they happen.
This should only be disabled for very performance-sensitive or
size-sensitive builds, but not for the regular case where it can be
very useful to debug a user issue.
|
|
Verbose logging shouldn't require a rebuild, as it can help debugging
user problems.
This reverts commit 397e31879bf79861a1a21ec4e2a75017e243d34b.
|
|
|
|
|
|
|
|
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
|
|
|
|
Also update HACKING
Signed-off-by: Tormod Volden <[email protected]>
|
|
|
|
|
|
|