Unity support

[hotice]

Could you please add Unity settings to tdrop? I'm trying tdrop with Terminix under Unity and the terminal window moves each time it's shown.

[noctuid]

Sure. I'm installing compiz, so that I can test things. Could you give me the output of the following command?

    xprop -notype -id "$(xprop -root -notype | \
        awk '$1=="_NET_SUPPORTING_WM_CHECK:"{print $5}')" \
        -f _NET_WM_NAME 8u | awk -F "\"" '/WM_NAME/ {print $2}' | head -n 1

With that, I could probably fix it right away.

[hotice]

Sure:

$ xprop -notype -id "$(xprop -root -notype | \
>         awk '$1=="_NET_SUPPORTING_WM_CHECK:"{print $5}')" \
>         -f _NET_WM_NAME 8u | awk -F "\"" '/WM_NAME/ {print $2}' | head -n 1
Compiz

[noctuid]

Let me know if that fixes it.

[hotice]

Yes, it works now, thank you very much. However, there's an issue (tested in Ubuntu 16.04): the first time I run Terminix (so no Terminix process exists) as a drop-down, without setting any "y" offset, the terminal is displayed a few pixels under the top Unity panel - screenshot: http://i.imgur.com/wIGHjXR.png

The second (and any other time except the first time) time I run it, it's displayed correctly - screenshot: http://i.imgur.com/dbYce5M.png

Also, the first time I run it, this is displayed in the terminal:

$ tdrop -a -w 1200 -x 350 terminix
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  8 (X_MapWindow)
  Resource id in failed request:  0x0
  Serial number of failed request:  17
  Current serial number in output stream:  17

Maybe a slight delay is required after running the app and before moving/resizing its window?

[noctuid]

Maybe a slight delay is required after running the app and before moving/resizing its window?

That error message isn't important; it shouldn't appear anymore. Tdrop waits for a window to be mapped before moving/resizing it already.

As for the issue you mention, I think this is caused by tdrop setting the default y offset to 1. It does this because an offset of 0 causes problems with some window managers. I don't know why it would change afterwards though. What happens when you use -y 0?

[hotice]

The behaviour is exactly the same as in my previous comment (with a gap the first time I run it) when using -y 0.

[noctuid]

Okay so I tested this in an Ubuntu vm. It turns out that the gap is the normal behavior (that's where a terminal will move if you call xdotool getactivewindow windowmove 0 0), so this is a problem with the interaction between Unity and xdotool. I don't think that there is anything I can really do about this. The reason the gap isn't there later is that this doesn't happen when mapping the window and moving it in the same xdotool command. I could separate them and maybe add some delay to get the gap to always show, but I don't think I can have it work the other way around.

[hotice]

I understand, thank you!

[noctuid]

This problem also seems to happen on some other DEs and with both wmctrl and xdo (and I couldn't get wmutils to work at all on a DE). There is an open issue for xdotool that mentions this. I'll keep an eye on it and leave this issue open for now.

[noctuid]

I'm following the xdotool issue but will close this for now since there is nothing I can do.