terminator icon indicating copy to clipboard operation
terminator copied to clipboard

On toggling visibility, window reverts from multi-monitor span

Open protist opened this issue 4 years ago • 11 comments

Steps to reproduce

  1. Resize window to span across multiple monitors
  2. Hide terminator using the hide_window keybinding
  3. Show terminator again using the same keybinding

Expected results

Window should be the same size and in the same position as before. (This occurs as expected if the window was originally wholly contained in a single monitor in step 1.)

Observed results

Window is moved and/or resized to fit within a single monitor.

Additional information

  • I'm using a "normal" multihead setup in KDE, i.e. just using the default DE settings.
  • Up-to-date Arch Linux
  • Terminator 1.92-2 (from the official repositories)

protist avatar Jun 09 '20 04:06 protist

I don't really have the setup to reproduce this one. It sounds like it may be a window manager problem. Can you reproduce this under GNOME?

mattrose avatar Jun 11 '20 01:06 mattrose

Thanks @mattrose. I installed GNOME (I feel dirty), and I can reproduce this issue there too.

FWIW I also installed a bunch of other terminals with a "toggle-visibility" setting, and I can confirm that Tilda correctly spans multiple monitors after a toggle-visibility cycle.

I couldn't properly test the others I installed (which also reinforced how good Terminator is!):

  • Guake: the size is set manually in the preferences window. Resizing the window on-the-fly does not persist after a hide/reveal cycle. However, the preferences don't allow for a width greater than a single monitor.
  • Yakuake: I can't even start this program without it crashing
  • Qterminal: I can't assign a key to toggle visibility. The field won't register.

protist avatar Jun 11 '20 06:06 protist

Thank you so much. I didn't want you to feel dirty, but it will make trying to reproduce this so much easier.

mattrose avatar Jun 11 '20 15:06 mattrose

I'm now able to reproduce this and, wow, looking at the solution for this it's ... not trivial. I know why this is happening, but I'm not quite clear on how to fix it yet. I'll leave this bug open, but in the meantime I recommend the workaround of "Don't do that" :(

mattrose avatar Aug 21 '20 20:08 mattrose

Bummer. Thanks for looking at this anyway @mattrose. I haven't tried yet, but a hacky solution might be to use KDE's window rules in the meantime.

protist avatar Aug 22 '20 00:08 protist

Yeah, it's weird. I'm just using the GTK.Window calls. Oddly enough, .iconify() works as expected, but .hide() doesn't seem to remember the placement properly, and needs to have it's position reset.

mattrose avatar Aug 25 '20 23:08 mattrose

Ah right. So it seems like a GTK bug then?

protist avatar Aug 25 '20 23:08 protist

Bug, or ... Feature? I'll do some digging on the gtk bug tracker.

mattrose avatar Aug 25 '20 23:08 mattrose

Can't find any of that exact bug on the various gtk bug trackers, but I found a bunch of similar. We actually hack around this a little bit in terminator, but I'll take a look at the source and see if I can find anything, and probably end up opening a GTK bug.

mattrose avatar Aug 26 '20 00:08 mattrose

Save the window size/position before hiding and restore it after unhiding?

ghost avatar Sep 16 '22 19:09 ghost

@stinnnnn Could be a workaround.

It might be relevant, but I do occasionally have the window move around unexpected. That is, I usually have it aligned to the top of the screen, covering ~80% of the screen. It's almost always fine, but sometimes (1/100 occasions) when I hide then show the window, it aligns to the bottom of the screen instead.

protist avatar Sep 17 '22 01:09 protist