WindowMax Bar doesn't take into account windows being moved between monitors

[mkalinski]

• Open Bar version: 30
• Gnome Shell version: 45.5

To reproduce:

• Have multiple monitors.
• Maximize a window on a monitor without the shell bar.
• Use the "move window one monitor to left/right" keyboard shortcut (shift+super+left/right) to move the maximized window to the monitor with the shell bar.
• The maximized window is now on the same monitor as the bar, but WindowMax Bar doesn't trigger, until ex. going into the overlay and back.

The mirror scenario of the above also happens:

• Maximize a window on a monitor with the shell bar; WindowMax Bar triggers.
• Use the keyboard shortcut to move the window to another monitor.
• WindowMax Bar styling remains, despite the monitor with the bar being now empty and showing the desktop.

[neuromorph]

Hello, Good catch! Thank you for reporting! I missed to capture that event. I have fixed it now in GitHub. To get the update you can run this command in terminal:

cd ~/.local/share/gnome-shell/extensions/openbar@neuromorph/; curl -LJO https://raw.githubusercontent.com/neuromorph/openbar/main/extension.js; cd

Feel free to get the entire extension code from GitHub and replace your local installation (to get some more fixes esp. about fullscreen). The next official update/release will include these fixes. I am working on more theming options, so it may take a while.

Let me know how it goes.

[mkalinski]

The command you gave for update won't work in this case, since the extension then crashes due to gschema changes. :wink:

Using the code from entire repo as extension, it seems to fix the problem with WindowMax Bar, but "Apply in Overview" somehow stops being respected: styling is always applied in overview, no matter the option value.

[neuromorph]

The command you gave for update won't work in this case, since the extension then crashes due to gschema changes. 😉

Oh yeh, my bad. I added new key to schema for another issue. Full extension update is right option :+1:

but "Apply in Overview" somehow stops being respected: styling is always applied in overview, no matter the option value.

That part is also changed. Now, it is supposed to remove styles from the Bar, if that option is deselected, but the Menu styles are ON regardless (which is revealed only if you open a menu while in overview) . This is done to support the new features I am working on where the menu styles can be optionally carried forward to rest of the shell. Is this what you are referring to or the bar itself has style? Feedback also welcome.

[mkalinski]

Is this what you are referring to or the bar itself has style? Feedback also welcome.

Unfortunately, I'm referring to islands styling on bar elements remaining in overview, which from your response I understand shouldn't be happening.

[neuromorph]

That's correct, it shouldn't be happening. I missed to port a small change to 45+. Now, this command should fix it :crossed_fingers: :) cd ~/.local/share/gnome-shell/extensions/openbar@neuromorph/; curl -LJO https://raw.githubusercontent.com/neuromorph/openbar/main/stylesheets.js; cd

[neuromorph]

May still be a problem if you switch workspaces in Overview :face_with_head_bandage: . It is also fixed but I'll update later after some cleanup. Let me know if you face any breaking scenarios so I will also fix that. My testing is a bit limited right now.

[mkalinski]

Actually, there's no problem when switching workspaces in overview, buut… :stuck_out_tongue:

Unfortunately there's still a bit of confusion that seems to only happen with Fullscreen Avoider. I haven't checked if it would happen if the top bar was manually moved. The (slightly convoluted) scenario is as follows:

1. Maximize a window on one screen.
2. Fullscreen that window. Fullscreen Avoider kicks in and top bar is moved to another screen. No problems so far.
3. Move the window to another screen. Fullscreen Avoider moves the top bar back to the first screen, but now it's the Window-Max variant, despite the desktop being clear.

[neuromorph]

So, I am almost sure that I have tested this scenario when I added the last fixes and it should work fine. However, I haven't uploaded the code to GitHub due to other partial stuff that still needs to finish and it is in Gnome 42 :stuck_out_tongue: . I will test it out again soon (only have my laptop right now, need to find a monitor). Once tested OK, I will pick and port relevant part to Gnome 45+ and upload here. Meanwhile, feel free to add any scenario here that you are facing issues with so I can test that too.

In the new version, there should not be any issues with WindowMax combined with overview, window movement or Fullscreen Avoider and also it will be smoother than before.

[neuromorph]

I have uploaded the fix to GitHub 'main' branch. You will need to get extension.js and stylesheets.js. I have tested on Gnome 42, unable to check multi-monitor in Boxes for 45+. But it should go well hopefully.

Let me know how it goes. Thank you!

[mkalinski]

Unfortunately there's a new bug that must have been introduced in one of the two most recent commits: If you have "Neon Glow" turned on and "Apply in Overview" turned off, then the glow (and only it) is applied in overview.

But more imporantly, bug #20 is back, so I can't really test the WindowMax Bar, because styling stopped working with non-primary monitors.

I hope I'm testing the right version. Aside from extension.js and stylesheets.js, I also needed the contents of the schemas directory from main branch, or else the extension would crash.

[neuromorph]

:facepalm: Need to fix the fixes :stuck_out_tongue:

If you have "Neon Glow" turned on and "Apply in Overview" turned off, then the glow (and only it) is applied in overview.

True. The backend for overview is changed and I missed to update this part. Fixed now.

But more imporantly, bug https://github.com/neuromorph/openbar/issues/20 is back, so I can't really test the WindowMax Bar, because styling stopped working with non-primary monitors.

I am not able to reproduce this issue. I suggest you try again with latest code from Github. Also, try turning On 'Apply in Fullscreen' toggle under Bar Props. It seems the Gnome crash issue is fixed upstream :crossed_fingers: and Dash-To-Panel users are able to access the panel in fullscreen, so I have added this toggle to keep Open Bar styling On in fullscreen. [The issue should not occur regardless but try toggling]. BTW, the earlier issue you mentioned above with Fullscreen Avoider was a timing issue :p. Open Bar was styling before Avoider moved the panel to another screen.

Aside from extension.js and stylesheets.js, I also needed the contents of the schemas directory from main branch, or else the extension would crash.

Oh, I did not change the schema this time but it was changed a couple weeks ago for another issue and I was under impression that you had that change. Good, you fixed that!

OK, so current issues should also be fixed now. You need to take 'stylesheets.js' and 'prefs.js' - I edited only those for current fix. Feel free to take whole thing in case something is out of sync. Let me list below what that should include (replace below files/dir):

• media
• schemas
• autothemes.js
• extension.js
• prefs.js
• quantize.js
• stylesheets.js

Thanks for reporting these issues! I will have them all fixed for the next release also. Let me know how that goes.

[mkalinski]

Thanks. The Neon Glow issue is fixed.

[The issue should not occur regardless but try toggling]

Unfortunately, the issue persists for me, but toggling "Apply in Fullscreen" does fix it, and I haven't seen any crashes yet.

Let me list below what that should include (replace below files/dir)

I admit, at this point, I just checked out the repo and symlinked it to gnome extensions dir.

So, it seems that the issue with moving windows between monitors is fixed, but there's another case with Fullscreen Avoider now.

1. Fullscreen a window on a monitor.
2. Bar is moved to the second monitor, and it will never receive Window-Max styling, no matter if a window is maximized there.

[neuromorph]

Bar is moved to the second monitor, and it will never receive Window-Max styling, no matter if a window is maximized there.

Again, I am not able to reproduce it, but then again I am testing on LTS with G42. So, something could be amiss in the 45+ port. Unfortunately, I am not able to test multi-monitor with 45 in a VM (Boxes only shows a single monitor). Let me know if that can be worked out in some way. I will also try to compare the two versions to find the missing puzzle piece.

[neuromorph]

I compared the 45+ port relevant part with 42 and it is same, nothing missing. However, I added a fix for another issue which was affecting it based on the multi-monitor layout/connections. That can also resolve the WindowMax styling issue on another monitor, hopefully. You can get extension.js or pull the latest since you have symlinked to the repo which does make more sense :smiley:

Let me know.

[mkalinski]

This change fixed all the remaining bugs I mentioned here. :grin:

Seeing in the code that it was an upper bound check issue, I wonder if you couldn't reproduce these bugs because you had your secondary monitor on the opposite side of the primary one than me (mine was on the right).

[neuromorph]

Great news! :smile:

Gnome assigns indices to monitors when they connect/disconnect and seems to depend on the layout or even connecting port (another user faced that). The upper bound issue meant that more than one monitors could satisfy the 'contains-panel' condition and it would 'break' on finding the first. So, yes, layout/connection combo was hiding the issue for me. When I suspected the issue could relate to that, I tried many re-layouts and finally reproduced it. Then fixing it was easy.

Let me know if you face any other issues.

One more thing. I am reworking the auto-theming algo at the moment. Check discussion here. If you use auto-theme and have any inputs on what you would like to keep or change, whether you would prefer the changes discussed there or not etc, please comment on that issue, if possible. Thanks!

[neuromorph]

The fix is now part of the live version published in E.G.O. (Gnome Extensions web), so closing this issue.