[Enhancement] Add option to hide on lost focus

[lpinner]

Would you consider adding a 'hide on lost focus' option, like the way the Guake/Tilda terminals unmap themselves when they lose focus?

Looks like it might be possible with something like xdotool behave $wid blur exec xdotool windowunmap $wid

[noctuid]

This seems pretty useful, so I'll consider adding it as an actual flag. Ideally you'd just be able to do this with --create-hook, but I couldn't get xdotool's behave to work right. Does that command work for you?

If I run this in a dropdown, it will work at first, but it will also activate when remapping the window (requiring me to kill xdotool):

xdotool behave $(xdotool getactivewindow) blur \
    exec xdotool windowunmap $(xdotool getactivewindow) &

This might be a bug in xdotool or just have to do with my WM. I'll try it in some other WMs.

[lpinner]

I found the same. I eventually got it sort of working using tdrop --map-hook='sleep 0.25 && xdotool behave $1 blur exec hide_on_lost_focus $1 &' -a terminix where hide_on_lost_focus is a small shell script containing:

#!/bin/bash
xdotool windowunmap $1
killall "xdotool"

But then I could only unmap the window when the focus was lost as pressing my tdrop keyboard shortcut lost focus, so xdotool unmapped the window and tdrop mapped it again :)

I didn't try much more than that and raised the enhancement request hoping someone more knowledgeable could implement it or suggest a better way to do this with a hook.

[noctuid]

Yeah that was the only workaround I could think of. If you wanted to use more than one xdotool behave (or more than one dropdown), it would be better to kill the specific xdotool instance.

But then I could only unmap the window when the focus was lost as pressing my tdrop keyboard shortcut lost focus, so xdotool unmapped the window and tdrop mapped it again

It works ~5/6 times for me if I increase the sleep time and kill xdotool before the tdrop command, but that's still not very good. I made an issue (see jordansissel/xdotool#124). Hopefully this is fixed in xdotool eventually or one time rules are added to prevent the need to kill xdotool afterwards. There may be some other utility that could replace xdotool (though I didn't see any equivalent feature in wmutils, xdo, or wmctrl at first glance).

What window manager are you using?

[lpinner]

Running gnome 3.18 so WM is mutter I assume.

[ibrokemypie]

it is so nice to find such an awesome project that iS STILL BEING MAINTAINED BY THE DEV OMG
+1 for hide when losing focus

[noctuid]

Unfortunately, there isn't much I can do until the issue I opened for xdotool is addressed in xdotool. A solution is probably possible for a few window managers using their own functionality (e.g. bspwm), but for this to work in the general case, xdotool needs to be changed or an alternative program used. None of the xdotool alternatives have an equivalent of xdotool's "behave" command as far as I am aware.

[jordansissel]

Hello! xdotool author here. Thanks for linking these bugs together :)

I'll see what we can do.

[noctuid]

@lpinner I'd like to keep this open until there is some solution.

[alexesmet]

I managed to get it working with xdotool. The problem was that the application would close even when reopened. I managed to get it working by adding a check - whether a correct window is in focus. I start tdrop the following way:

tdrop -C 'xdotool behave $(xdotool getactivewindow) blur exec /home/alexesmet/Documents/scripts/unmap_if_not_tdrop.sh $(xdotool getactivewindow)' -am -w 70% -x 15% -y 0 alacritty -o window.decorations=none  --class=tdrop -t tdrop

As you can see, it calls my unmap_if_not_tdrop.sh script when focus of the created terminal changes. Script checks, whether currenlty active window is a tdrop, and unmaps it if yes:

#!/usr/bin/sh

if [ "$(xdotool getactivewindow getwindowname)" != "tdrop" ]
then
    xdotool windowunmap $1
fi

It receives id of the dropdown window as a first parameter (I just understood it can be removed).

I had to extract this bit into a script because I was not ture how to plug if into the exec

[I-Want-ToBelieve]

I wrote a program that automatically hides the window managed by tdrop by listening to the focus switch event emitted by the x11 server

Installation

cargo install autohide-tdrop

Usage

~/.config/sxhkd/sxhkdrc

ctrl + t
	tdrop -n tdrop_kitty --post-create-hook "autohide-tdrop &" -ma -h 60% -w 70% -x 15% -y 0 env GLFW_IM_MODULE=ibus kitty --class=tdrop_kitty

plz see https://github.com/I-Want-ToBelieve/autohide-tdrop/tree/main

[Darukutsu]

I decided to dig in this because I had some performance issues with @I-Want-ToBelieve autohide-tdrop.

After so much tries with xdotool I managed to do pretty stylish and working flow.

sxhkd(you can safely remove bspwm part of config and -N if needed):

# tdrop (square mid)
F12
	tdrop -N -P 'xdotool getactivewindow behave %1 blur windowunmap exec killall xdotool' -U 'killall xdotool' -l 'bspc rule -a \* -o rectangle=900x550+0+0 center=on state=floating layer=above' kitty

So basically we kill xdotool when explicitly close tdrop. And exec will kill xdotool after window hides(loses focus) therefore we used -P and not -C cause calling each time.

[edit]
I was happy too fast. I just discovered that if window is fullscreen (in bspwm) that this won't work(looks like focus is on fullscreen window)

[jordansissel]

@Darukutsu for ‘killall xdotool’, would you rather xdotool have a way to terminate itself? I’m open to adding such a feature to xdotool.

or maybe add a flag to the xdotool behave command to exit after performing the task once.

[I-Want-ToBelieve]

@Darukutsu I also encountered an edge case today. Under normal circumstances, when the listening window exits, the autohide-tdrop process will also be terminated.

However, if x11 server crashes, autohide-tdrop will occupy a single CPU core.

I have reported this bug upstream, bread-graphics/breadx#93 (comment)

I have followed the breadx author's prompt to switch the dependency from breadx to x11rb and released version 1.0.3.

x11rb is able to report x11 server crash errors, which I caught, so now x11 server crashes will not cause infinite loops.