`resize` does not work properly during view_map execute criteria that creates floating windows

[dev-forty-two]

Please fill out the following:

• Scroll Version:
  1.12-dev-e00ca868

• Description:
  The resize command does not seem to work for floating scratchpad windows. E.g., I open thunderbird as a floating scratchpad window at start and set for_window [title="^.*Mozilla Thunderbird$" app_id="thunderbird"] resize set 98 ppt 93 ppt to resize it. On i3 and sway this correctly resizes the main thunderbird window to the desired dimensions. On scroll, this does not seem to work. Thunderbird is running under wayland.

  I also run some tui programs in foot (e.g. btop) as floating windows (not in scratchpad) and resize them like this; resizing does work as expected in these instances. On the other hand, for another scratchpad foot window titled "calculator", where a REPL is open, resizing with for_window [title="^calculator$"] resize set 80 ppt 80 ppt does not work. Again, this works as expected in i3 and sway. (A peek at scrollmsg -t get_tree tells me that my regexes should work.)

[dawsers]

Are you sure it's the resize command that doesn't work?

I have this in my config and it when I press mod+F12, I get a vifm scratchpad window of size width 50% and height 90%

    for_window [app_id="scratchpad_vifm"] move scratchpad
    for_window [app_id="scratchpad_vifm"] scratchpad show
    for_window [app_id="scratchpad_vifm"] resize set 50 ppt 90 ppt
    bindsym $mod+F12 exec $terminal --class scratchpad_vifm -e vifm

I think you may be missing the scratchpad show, and the resize command is not applying because the window is not in focus.

[dev-forty-two]

I do have scratchpad show; for example, this is what I have for opening the "calculator":

bindsym $mod+c [title="^calculator$"] scratchpad show; move position center
for_window [title="^calculator$"] floating enable
for_window [title="^calculator$"] resize set 40 ppt 40 ppt
for_window [title="^calculator$"] move position center
for_window [title="^calculator$"] move scratchpad

Note: The calculator app (also thunderbird) is autostarted in the config with an exec statement. Could it be some kind of race condition?

EDIT: So, the app starts and gets focus, becomes floating, is resized, centered, moved to scratchpad, and brought back on invoking $mod+c --- that's what the above should do, right?

EDIT: Also, scroll is crashing sometimes when I show the scratchpad thunderbird window and click on an email. This has happened five-six times in the past couple of days, but I cannot consistently reproduce it.

[dawsers]

This is related to a bug in sway, so I am sure the same problem happens there.

swaywm#2176

There is a PR about this:

swaywm/sway@master...kennylevinsen:sway:view_premap2

From what I found debugging, the criteria execute well, and do what they should: resize the container and send a request to the client to adopt that size. But there are applications (I tested using Firefox) that when they receive the initial 0x0 configure (use any size you want), they decide to resize to the size they were in their previous session. In my case, firefox's container gets resized, scroll sends the correct configure message, but then firefox sends a commit message using a different size it decided (the one from its previous session in floating mode), and the first request falls into oblivion.

So, as a workaround, for this to work with those applications, I had to do the resize when calling them back from the scratchpad, for example:

    for_window [app_id="firefox"] floating enable
    #for_window [app_id="firefox"] resize set width 80 ppt height 50 ppt
    #for_window [app_id="firefox"] move position center
    for_window [app_id="firefox"] move scratchpad
    #for_window [app_id="firefox"] scratchpad show
    exec firefox
    bindsym $mod+F9 scratchpad show; resize set width 80 ppt height 50 ppt

I am thinking Thunderbird will be similar to Firefox in this behavior..

I think it would be best to wait for sway to commit their PR instead of having two different solutions.

[dev-forty-two]

Okay, this must be it.

I tested on sway. Somehow thunderbird behaves correctly, but my calculator app (running in foot) suffers from this bug. Anyway, the workaround works as expected.