Hi,
when taking a sufficiently large screenshot of at least this wine application with xfce4-screenshooter (window or selection) and copying that to the clipboard, pasting, e.g. into libreoffice writer, fails.
Interestingly when the selected window region is small, it works, which smells like a bug to me. When starting xfsettingsd with
XFSETTINGSD_NO_CLIPBOARD=true
and using xfce4-clipman with the "copy last image" option checked, it always works.
The same occurs within MATE, which probably has it's own clipboard manager..
I also tested gnome-screenshot - the pasting works, if gnome-screenshot is not closed before pasting (while xfce4-screenshooter closes itself after copying to clipboard, gnome-screenshot remains open).
This seems to be a pointer that the common underlying technology (which is it?) is broken - it looses larger images once the referenced screenshot application closes. However, to have another unreliable backend less, I suggest to copy the last image by default also in the clipboard used within xfsettingsd.
Tested on mostly vanilla Debian Buster.
Btw, if libreoffice-gtk3 is used, it crashes on close, this does not happen in the gtk2-version...
Thanks for the effort
Tycho
Thanks for a quick update :-)
4.18.6 has been released with the fix, I can't do more :)
Yesterday I received two XFCE related updates:
libxfce4util-4.18.2-1.fc38.x86_64 Tue 12 Mar 2024 01:51:39 PM
libxfce4ui-4.18.5-1.fc38.x86_64 Tue 12 Mar 2024 01:51:39 PM
after which I can no longer use shortcuts using The Windows/Super Key + any keypad digits, e.g.
<property name="<Super>KP_5" type="string" value="xlock"/>
<property name="<Super>KP_2" type="string" value="gamma.sh +"/>
<property name="<Super>KP_1" type="string" value="gamma.sh -"/>
<property name="<Super>KP_0" type="string" value="gamma.sh 0"/>
Now none of them work.
Downgrading libxfce4ui to version 4.18.3 has fixed the issue.
Yesterday I received two XFCE related updates:
libxfce4util-4.18.2-1.fc38.x86_64 Tue 12 Mar 2024 01:51:39 PM
libxfce4ui-4.18.5-1.fc38.x86_64 Tue 12 Mar 2024 01:51:39 PM
after which I can no longer use shortcuts using The Windows/Super Key + any keypad digits, e.g.
<property name="<Super>KP_5" type="string" value="xlock"/>
<property name="<Super>KP_2" type="string" value="gamma.sh +"/>
<property name="<Super>KP_1" type="string" value="gamma.sh -"/>
<property name="<Super>KP_0" type="string" value="gamma.sh 0"/>
Now none of them work.
Downgrading libxfce4ui to version 4.18.3 has fixed the issue.
GitBot (c928755c) at 12 Mar 23:45
I18n: Update translation kk (100%).
I released libxfce4ui 4.18.6 with the above patch, since this regression seemed to affect quite a few people.
Gaël Bonithon (86d264da) at 08 Mar 09:18
Back to development
Gaël Bonithon (2f49f3c6) at 08 Mar 09:18
Updates for release
Gaël Bonithon (5afc7af7) at 08 Mar 09:18
Updates for release
setxkbmap -query
rules: evdev
model: pc105
layout: de,de,de
variant: ,nodeadkeys,deadacute
options: ctrl:swap_lalt_lctl
/Default/XkbDisable false
/Default/XkbLayout de,de,de
/Default/XkbOptions/Compose
/Default/XkbOptions/Group
/Default/XkbVariant ,nodeadkeys,deadacute
Assigned to Nick Schermer
Hello,
I am writing here as a result of 2 other bugs: first this one https://bugzilla.xfce.org/show_bug.cgi?id=14390 from where I understood finally that assigning Alt + Print (SysRQ) is not permitted and secondly this one: https://bugzilla.xfce.org/show_bug.cgi?id=7897 from where I finally understood why I am not allowed to assign it.
My problem is the behavior or keyboard shortcut app: it is not giving any conflict info to the user and as a result it is assigning a wrong shortcut (only Alt) for the operation which could lead to more search and efforts and frustrations.
Luckily justinnoah@gmail.com, the reporter of bug 7897 realized it when he was setting it up, but there are possibilities (like in my case) when this is not noticed.
Can a "conflict warning" be issued for the case when the user is attempting to assign Alt+Print?
thank you, V
Version: 4.13.4
This is actually not true, since by setting the shortcut manually as in xfce4-settings#519 (closed), it is then activated on key release (unlike the other shortcuts which, with the exception of a single modifier since libxfce4ui 4.18.5, are activated on key press).
However, I don't think we currently have a way of doing better with the shortcut dialog, as we're listening to GTK events, not directly to X11 events as in the shortcut grabber. And GTK doesn't let Alt+SysReq through, either on key press or on key release.
I'm not sure it's worth listening directly to X11 events in the shortcut dialog just to improve that. Anyway, I'm reopening this issue, since there's room for improvement.
Gaël Bonithon (e23a9cf9) at 29 Feb 08:36
Back to development
Gaël Bonithon (35366137) at 29 Feb 08:36
Updates for release
Gaël Bonithon (f2a031af) at 29 Feb 08:36
Updates for release
Thanks!