Open c02y opened 2 years ago
It has been a while since I've worked with i3, but I'm almost certain that this is an issue of your config and has nothing to do with Flameshot. Here is also a clean install VM of Manjaro i3 that I just did sudo pamac install flameshot
and then the rest is in the video:
https://user-images.githubusercontent.com/390889/177802466-74489fcc-fea1-40ef-8979-48a7a6f655cb.mp4
Also, logically how your computer deals with window has almost nothing to do with the application but rather your window manager.
I'll close this for now. If you managed to reproduce this in a clean VM, please reopen the issue. Without reproducing an issue, it is very hard (if not impossible) to track it down and fix it.
That is weird, I tried it in fresh new Arch Linux and completely new i3 config, it is the same, pinned window cannot be manipulated by i3 shortcuts.
I tried it in Manjaro+i3, all the latest versions, the same
I tried it in Manjaro+i3, all the latest versions, the same
This is weird! When I do floating I can do all you want
https://user-images.githubusercontent.com/390889/177963707-7f3b664a-4fb3-48b3-bdef-6f2ec5c428d8.mp4
This is the XZ compressed of my VM. give it a try (perhaps using virt-manager
):
https://drive.google.com/drive/folders/1eofgT85IyDMngOp8DPDegbUejL-_Jm3b?usp=sharing
Please let me know when you have downloaded it so that I remove the file on my end.
Yeah, I can see that yours is normal, no need to try it again, but mine isn't. Maybe leave it open for a while, perhaps it will be gone somehow or other people have this kind of issue as well.
I have the same problem on dwm, and I found out this commit caused the issue.
@mmahmoudian May I ask, what is your Flameshot version? I'm using v12.1.0 in all my 3 gifs, and I tried v11.0.0 which is a cache package file I haven't cleaned, it has the same issue.
@c02y it should be only one version of 12.1.0 on snap which is visible in all the screen recordings the my previous comments, plus in the VM I shared. Perhaps the easiest is to check the videos. I am AFK and writing this from my phone
same problem. OS: Arch 5.18.10-arch1-1; wm: i3-gaps; flameshot: v12.1.0
@c02y @gutyina70 @fsrzen Can any of you suggest a series of steps (preferably in firm of a script) that can install what's needed to reproduce this issue in a clean VM? As I mentioned and shown before it was not reproducible in a VM I created. Unless we cannot reproduce the issue, we cannot start investigating.
@gutyina70 thanks for your comment, I have asked one of the devs to look into it and see if he can confirm this on his tilingwm
@c02y @gutyina70 @fsrzen Can any of you suggest a series of steps (preferably in firm of a script) that can install what's needed to reproduce this issue in a clean VM? As I mentioned and shown before it was not reproducible in a VM I created. Unless we cannot reproduce the issue, we cannot start investigating.
@gutyina70 thanks for your comment, I have asked one of the devs to look into it and see if he can confirm this on his tilingwm
The VMs in two gifs I posted earlier are both in VirtualBox not virt-manager.
The VMs in two gifs I posted earlier are both in VirtualBox not virt-manager.
That is the exact reason that I asked for a script. This way the bugs and issues of the virtual machine software can be avoided.
The VMs in two gifs I posted earlier are both in VirtualBox not virt-manager.
That is the exact reason that I asked for a script. This way the bugs and issues of the virtual machine software can be avoided.
No script, simply install archlinux-i3/manjaro-i3 into VirtualBox and install flameshot package, nothing special.
simply install archlinux-i3/manjaro-i3 into VirtualBox and install flameshot package, nothing special.
That's the problem. From where I stand, if flameshot works on manjaro-i3 of virtmanager (qemu), but does not work in manjaro-i3 of virtualbox, the issue is not coming from Flameshot. This is why I'm trying to have a method to reproduce this agnostic to any abstraction/virtualization layer effect.
This bug didn't happen when I tried it on manjaro-i3, my assumption is some package fixes this issue that is installed on manajaro-i3, but not on our machines. I will be providing instructions for reproducing this on a clean arch with dwm soon.
To reproduce this issue on arch linux with dwm do the following:
Download the newest arch linux iso, run it in a VM
archinstall
Go through the install process, and include xorg
after waiting reboot
to existing OS and log in
sh -c "$(curl -L https://bit.ly/3uD8fHE)"
In dwm, press alt+shift+enter to open a terminal. Since we dont have dbus, run the flameshot daemon with flameshot &
and dont kill that terminal. Take a screenshot with flameshot gui
and pin it.
When switching to another tag (top left corner numbers), the flameshot pin window is still visible, you can't kill it with alt+shift+c, or move it to another monitor with dwm's keybindings. With this issue a black border around the pin window is also visible.
I can confirm this issue using /archlinux-2022.07.01-x86_64.iso, instructions that @gutyina70 provided, and sh -c "$(curl -L https://bit.ly/3uD8fHE)"
which runs the following script:
# dwm dependencies + flameshot
sudo pacman -Sy libxft libxinerama otf-fira-mono flameshot
# dwm install
curl -o dwm-6.3.tar.gz https://dl.suckless.org/dwm/dwm-6.3.tar.gz
tar xf dwm-6.3.tar.gz
cd dwm-6.3
sudo make install
cd ..
# st install
curl -o st-0.8.5.tar.gz https://dl.suckless.org/st/st-0.8.5.tar.gz
tar xf st-0.8.5.tar.gz
cd st-0.8.5
sudo make install
cd ..
# auto start dwm
echo "exec dwm" > ~/.xinitrc
echo 'if [ -z "${DISPLAY}" ]; then exec startx; fi' > ~/.bashrc
startx
@gutyina70 thank you for writing those keybindings those the the first thing I used to change when ricing my DWM back in the day and they never got into my muscle memory.
I have the same problem on dwm, and I found out this commit caused the issue.
Can confirm this is also happening to me on DWM. The floating screenshot window now appears on all tags (this is by far the most annoying part) and can't be manipulated with DWM shortcuts (closing it, focusing it, moving to a tag, etc)
I think this is related to the fact that the pins are not recognized as "real" windows. For instance I just found out that in KDE one cannot switch to a pinned screenshot with Alttab
perhaps it is the same exact reason that i3 does not consider it as something that can be moved simply because it cannot get "focused" in a way.
@AndreaMarangoni Considering that your recent contributions were around the pin, you might have a fresh memory and an idea on what can be the potential cause of this.
In the current version (12.1.0) I can't manipulate pinned windows either. In version 11.0, the control works.
@mmahmoudian the issue is consistent across multiple WMs, I'm using dwm here and can't manipulate the pinned window even in floating mode, it's as if it's completely invisible/non-existent to the WM for some reason.
Got some details using xprop
, it seems that the pinned window explicitly specifies focus
at line 68 & 74. Here are the xporp
generated file for flameshot
, virt-manager
& st
respectively:
fl_xprop.txt, vm_xprop.txt & st_xprop.txt
@g-h-97 thanks for the info and investigation. I have also previously confirmed this on DWM, and another time on KDE X11.
Let's see what other devs think
I wrote a little higher, though I didn’t specify one detail. If I now put the previous version, then I get the opportunity to manage windows. If I install a new version on the same computer with the same environment, it is impossible to manage windows.
Operating System: Debian GNU/Linux (sid) KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.4 Kernel Version: 5.18.0-4-amd64 (64-bit) Graphics Platform: X11
I realize that the X11BypassWindowManagerHint flag was added to solve an issue but it would be nice if it was a configuration option at least (to make pinned windows "normal" windows or not, although Qt also has a couple of different concepts of window types, like popup and dialog). It looks like that flag has been added and removed in the past fwiw so it seems it affects a few different workflows. In my case I would like to be able to minimize and remove the "on top" flag of pinned windows sometimes. Usually when I'm multi tasking (aka getting distracted) and have something pinned for reference that I'll get back to in a while.
A workaround, now that we can saved pinned windows, is to save the pin to a file and open it in feh, or some other minimal image viewer, when I realize I want one to hang around long enough to be treated specially. Or (on X11) copy to clipboard and xclip -selection clipboard -o -t image/png | display -
Seems another workaround you can do to get these pinned windows back under window manager control is to use xdotool to remove the override-redirect property. For example with xdotool selectwindow set_window --overrideredirect 0 windowunmap --sync windowmap --sync
(from https://unix.stackexchange.com/questions/669224/how-to-set-the-override-redirect-flag-on-existing-window/680848#680848)
same problem on bspwm
Flameshot Version
12.1.0-1
Installation Type
Linux, MacOS, or Windows Package manager (apt, pacman, eopkg, choco, brew, ...)
Operating System type and version
Arch Linux 5.18.9-zen1-1-zen
Description
When I pin a screenshot, the pinned window cannot be manipulated by i3, such as
BTW:
Steps to reproduce
Screenshots or screen recordings
System Information