Windows position and size, with taskbar in Win11

[pepe]

Hello. I found this program a great companion. Using Janet, I made my Win11 more ergonomic than my hand-crafted River on Wayland setup on Linux.

One thing with which I need help, though, is the size of the windows. They do not take the Windows Taskbar into account, and the bottom of the window is obscured. It is not always, and I still need to understand the pattern.

I would like to ask you for guidance in debugging so that I can understand and fix the behavior.

[agent-kilo]

They do not take the Windows Taskbar into account, and the bottom of the window is obscured.

Did this always happen to specific windows? All I can think of right now is that maybe those windows have minimum size limits, and they "overflowed" from the frames at the bottom. Can you take a screenshot when this happens, and see if those windows are of their minimum sizes? If that's the case, the :frame-to-window-size command may be able to fix it.

Windows (the OS) calls the desktop space excluding the taskbar "work areas", Jwno should have accounted for the taskbar here and in this function.

That said, I run Windows 10 on my machine, and Jwno is only tested in Win 11 VMs. Since Microsoft recently removed download links to their free VM images, I didn't really test Jwno on Win 11 lately. Maybe it's a Win 11 thing. I'll try to get a Win 11 setup ASAP.

[pepe]

Thank you very much! I am happy to test Win11 every day. After writing about this issue, I set the taskbar to hide, and the problem did not manifest. But after setting it to always show, the problem is back. Please see the screenshot of the Zulip client.

[pepe]

One more thing. Please, no hurry; with the taskbar hiding, I am fine.

[agent-kilo]

... I set the taskbar to hide, and the problem did not manifest. But after setting it to always show, the problem is back.

I see. When the space reserved by the taskbar is changed, Windows (the OS) would send some message to Jwno IIRC, but Jwno doesn't handle it currently 😅.

In this case, can you try Update Monitor Layout from Jwno's notification icon menu, and see if the work area can be resized properly, thus fixing the problem?

I wonder if this is the same problem you described in the original issue though.

They do not take the Windows Taskbar into account, and the bottom of the window is obscured.

Does this still happen when you're not changing the taskbar settings at all?

[pepe]

Update Monitor Layout command fixes it.

It happened before I started to do anything with the taskbar settings.

I will investigate more later. Thank you.

[agent-kilo]

Great, thank you for the feedback!

You can start Jwno like this, to have its logs written to a file:

jwno.exe --log-level debug --log-file <file name> --no-console

So that we may be able to do a postmortem if it happened again.

And I should indeed test it more on Win 11. I just found a bug when playing with Win 11's Paint app, but that's another story 😅

[pepe]

After more investigation, I found that it happens when I switch between one and two monitors on the notebook. The update monitor layout command fixes it. So, I guess we can call it a feature:-D.

Anyway, after that couple of weeks, I am so used to `Jwno' that I cannot imagine using Windows without it.

[agent-kilo]

I found that it happens when I switch between one and two monitors on the notebook.

Do you mean that it happens when connecting/disconnecting to an external monitor?

Do the monitors have different scale settings? You can check the scale in Settings app -> System -> Display -> Scale & layout section:

There may be edge cases when connecting/disconnecting monitors, that I'm not aware of.

I played with my Virtualbox VM a bit, emulating monitor connection/disconnection by enabling/disabling the second virtual screen, but could not reproduce the issue locally. Steps to reproduce it would be of great help 🙏.

Edit:

The update monitor layout command fixes it. So, I guess we can call it a feature:-D.

Oops, I replied to the original post received by email, so didn't see this part, sorry. I'm glad it worked for you 😊. If Update Monitor Layout worked, simply calling the :retile command may work too, it's Win + R in the example config.

[agent-kilo]

I'm closing this issue then. Feel free to re-open it if you have more info, or would like to tackle it again.

[oulongwen]

Hello. I am observing the same issue with the jwno on Windows 10. I can reproduce this issue by 1. lock the screen, 2. wait for the monitors to go to standby mode, and 3. log into the system again and jwno behaves as if the task bar does not exist. The :retile command does not fix it, but Update Monitor Layout does. Is it possible to bind Update Monitor Layout to a shortcut?

[agent-kilo]

Thanks for the repro steps! I'll try to reproduce it locally when I have time.

Meanwhile you should be able to bind this hacky custom command to a key and "refresh" the work areas 😅, it's equivalent to the Update Monitor Layout command in the context menu:

(:add-command (in jwno/context :command-manager) :refresh-work-areas
   (fn []
     (ev/give (get-in jwno/context [:ui-manager :chan]) :ui/display-changed)))

# Bind it to a key
(:define-key some-keymap "Win + Shift + R" :refresh-work-areas)

I'm replying from my phone so can't actually test it out, you may need to tweak it a bit to make it work 😅

[agent-kilo]

After some fiddling, I couldn't reproduce this on my machine.

What I did:

1. Launch Jwno as usual, and let it manage my windows;
2. Set the screen turn-off time to 1 minute:

3. Lock the screen by pressing Win + L;
4. Wait for the monitor to go to standby mode (It says "No Signal");
5. Wait at least 10 seconds;
6. Press Enter and enter PIN code to log in again.

I inspected Jwno's logs emitted during the time when the screen was locked, neither Windows nor Jwno did anything suspicious, and all my existing windows remained where they were, when I logged in again.

I only have one physical monitor, and my machine is a workstation. Laptops may have more aggressive power management, I'm not sure if that would have any effect on this bug.

It'd be great if you can run this line of code in the REPL:

(:dump-subtree (get-in jwno/context [:window-manager :root]))

Both before and after this bug gets triggered, and paste the output here. 🙏 I need specifically the lines containing monitor info, that look like this:

    Monitor (primary=true,dir=none,work-area={l:0,t:0,r:1920,b:1040},dpi=(96 96),device="\\\\.\\DISPLAY1")

You can right-click on Jwno's tray icon, and select Launch REPL.

[oulongwen]

Here is what I got before the bug triggered (I have two monitors):

Monitor 1:
Monitor (primary=false,dir=none,work-area={l:1920,t:0,r:3840,b:1040},dpi=(96 96),device="\\\\.\\DISPLAY1")
Monitor 2:
Monitor (primary=true,dir=horizontal,work-area={l:0,t:0,r:1920,b:1040},dpi=(96 96),device="\\\\.\\DISPLAY2")

and after the bug triggered:
Monitor 1:
Monitor (primary=false,dir=none,work-area={l:1920,t:0,r:3840,b:1080},dpi=(96 96),device="\\\\.\\DISPLAY1")
Monitor 2:
Monitor (primary=true,dir=horizontal,work-area={l:0,t:0,r:1920,b:1080},dpi=(96 96),device="\\\\.\\DISPLAY2")

I also notice that I need to wait for some time (e.g., 5 minutes) before logging back in to trigger the bug. If I log back in after 10 seconds, the bug does not trigger. Also note that I use a desktop. Hope these information helps and let me know if you need more information.

BTW I bound the custom command for refreshing work areas to a keyboard shortcut and it worked like a charm. It servers as a good workaround before this issue gets resolved. Thanks!