Broken window move leads to out of screen Network plugin for Wayland Wayfire

[qrp73]

Network plugin for Wayland Wayfire taskbar appears out of screen after WiFi network scan is completed.

NOTE: needs to be tested on typical environment with 10-30 visible WiFi hotspots

Steps To Reproduce: 1) Open Preference->Appearance Settings 2) Select Taskbar tab and select Bottom position for taskbar 3) Make sure taskbar has Network plugin, add it if it missing 4) Left click on Network plugin in taskbar and go to Advanced Options->Edit Connections 5) Open each Wireless connection and disable "Connect automaticaly" checkbox on General tab and save changes 6) Right click on Network plugin in taskbar and click Turn Off Wireless LAN 7) Wait until disconnect will be done 8) Right click on Network plugin in taskbar and click Turn On Wireless LAN 9) With no pause right click on Network plugin to open menu and wait...

Expected result: when scan is done, menu window position should be shifted up, to expand menu height

Actual result: menu window position remains the same and all menu items appears out of screen

The same issue happens each time when network list is changed.

[qrp73]

I'm not sure if taskbar uses X11, but it seems that it may be related to broken XMoveWindow function in XWayland.

See mistakenly closed (not fixed) issue #56

[spl237]

The XMoveWindow function is not "broken" in Wayland. As has been explained on the issue you quote, X functions have no effect in Wayland as they address an X server, and there isn't one in a Wayland environment. As has also been explained on that issue - which has been deliberately closed, not "mistakenly" - it is up to application authors to modify them using the layer-shell protocol, which is the only way to fix the position of windows under Wayland.

[spl237]

With regards this particular issue, it looks as if the authors of GTK did not consider the possible requirement to move a menu which grows while on display which is anchored at the bottom rather than (as is conventional) the top. This probably isn't fixable without redrawing the menu from scratch each time an item is added, which would be very annoying as it would cause the position of the mouse cursor on the menu to change.

The solution is to leave the taskbar at the top of the screen, where it should be, because menus are read from top to bottom and hence having them grow upwards rather than down is counter-intuitive anyway.

[qrp73]

using taskbar at top leads to more worse issues with window. When I set taskbar at bottom some window title may appears above upper display bound and when it happens it's impossible to click on window title and move window, because its title is outside of display. And this issue is not fixable with broken XMoveWindow function.

This is why I switched to bottom taskbar. When taskbar at the bottom there is no such issue when window title appears outside of screen.

Also I found that when taskbar at the bottom it is more convenient to use, because when taskbar at the top it confuses user with many layers of taskbar/window title/tab title. Just run firefox with taskar docked to the top of display, you will see: taskbar line, window title line, tabs line, bookmark line, and after these 4 (!) lines you can see the content. Taskbar located at the bottom reduce it to 3 lines which is much better for usability.

Also, the taskbar located at the top distracts attention when you use some app in maximized window.

[spl237]

It is not physically possible to move a window so far up the screen that it cannot be grabbed by the titlebar and moved back down again, because the mouse pointer cannot move outside the screen bounds. And it makes no difference either way whether the taskbar is at the top or bottom - the screen bounds do not change.

And yet again - there is no "broken XMoveWindow" function. This functionality does not exist in Wayland. It is not "broken". It is, by design, not included. Please stop trying to claim otherwise. This will not be changed, because it is not possible to change it.