Open lhmouse opened 4 years ago
I just found that this did NOT occur(could not reproduce it) with mate-settings-daemon and caja from current (1.25) git master on 11-11-2020, running on Debian Unstable. Duplicated your exact test, and trhe edit box in caja retained focus
lh_mouse@lhmouse-ideapad ~/Desktop/mate-settings-daemon $ ./autogen.sh
mate-desktop 1.25
on Linux Mint 20 (the latest version was 1.24
) so I applied this to configure.ac
:
diff --git a/configure.ac b/configure.ac
index cf4f72a..ffb03e5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,7 +56,7 @@ DBUS_GLIB_REQUIRED_VERSION=0.74
GLIB_REQUIRED_VERSION=2.50.0
GIO_REQUIRED_VERSION=2.50.0
GTK_REQUIRED_VERSION=3.22.0
-MATE_DESKTOP_REQUIRED_VERSION=1.25.0
+MATE_DESKTOP_REQUIRED_VERSION=1.24.0
LIBMATEKBD_REQUIRED_VERSION=1.17.0
LIBNOTIFY_REQUIRED_VERSION=0.7.0
LIBATSPI_REQUIRED_VERSION=2.0
make -j8
.I started the program in question like this:
lh_mouse@lhmouse-ideapad ~/Desktop/mate-settings-daemon $ ./plugins/mouse/msd-locate-pointer
Pressing Ctrl
activated the ripple effect around the mouse cursor so I suspected it worked.
At least two distinct behaviors were observed:
An additional side effect was observed: Normally, when an editbox gains focus, the fcitx-qimpanel tray icon should be a keyboard. But in the second case above, it became a penguin, suggesting nowhere was to enter characters. The original issue occurred no matter whether fcitx-qimpanel was running or not.
There might be divergences between Debian and Linux Mint. I am not clear about the details.
I was testing in a caja navigation window. Different gtk or glib versions might also affect this (I have glib 2.67.0 (development version) and gtk 3.24.23 from ocal builds installed here
It looks like libglib2.0-bin
is a bit out of date:
lh_mouse@lhmouse-ideapad ~ $ dpkg -l | egrep '\<lib(glib2\.0|gtk-3)-bin\>'
ii libglib2.0-bin 2.64.3-1~ubuntu20.04.1 amd64 Programs for the GLib library
ii libgtk-3-bin 3.24.20-0ubuntu1 amd64 programs for the GTK graphical user interface library
Mint is slow to update a lot of things, your gtk version is reasonably recent though. For glib to affect this would be less likely (it's lower level code) but I would not rule it out. No doubt a LOT of other differences between ours setups of course. I just checked to see if using compiz-reloaded and not marco was the difference(focus is issue here) but got the same behavior: renaming works as expected
I just tried Marco, Metacity and Compiz, all of which had the same issue.
Would it help if I provide a list of all packages?
Wouldn't help me much, someone who can duplicate the problem will have to work on this. One lead though is this: you and I just showed the window manager is NOT the problem, as changing WM does not change results for either of us.
This seems to be caused by XGrabKey
=> https://github.com/i3/i3/issues/2843#issuecomment-316173601. I have no idea about how to resolve it, though.
Expected behaviour
Pressing Ctrl should not make editboxes lose focus.
Actual behaviour
This option, if enabled, may cause editboxes (such as when renaming a file in caja a.k.a. the File Browser) to lose focus when the Ctrl key is pressed (for example when people attempt to copy the name), making it impossible to copy the text without using a mouse.
Steps to reproduce the behaviour
msd-locate-pointer
in the background. Starting this process manually can reveal the same issue.MATE general version
MATE 1.24.0
Package version
Package: mate-settings-daemon
Version: 1.24.0-1
Linux Distribution
Linux Mint 20 x86_64 MATE
Link to downstream report of your Distribution
N/A