Closed Porkepix closed 6 months ago
Did you read https://github.com/streamlink/streamlink-twitch-gui/issues/1008#issuecomment-2107657475 ? NW.js on Linux has been downgraded to 0.80 on master. STG v2.5.1 with NW.js 0.82 is irrelevant. You didn't even bother to try building from master.
Also give me a break, man... There are tons of other issues with NW.js/Chromium releases, as you can see in the recent releases, the linked issue and the recent changes on master. Tiling window managers are such an edge case, it's barely even relevant.
Did you read #1008 (comment) ? NW.js on Linux has been downgraded to 0.80 on master. STG v2.5.1 with NW.js 0.82 is irrelevant. You didn't even bother to try building from master.
When I read it, it maybe didn't even have a third of the content the message currently have. Especially, the request to test latest wasn't there at that time. There was the part about downgrading nw.js and splitting platform though, which is why I checked if there was a new release yesterday and this morning before opening this. I'll try to get a build from AUR's package, although on the computer running Gnome building such things might be quite long for me.
Also give me a break, man... There are tons of other issues with NW.js/Chromium releases, as you can see in the recent releases, the linked issue and the recent changes on master. Tiling window managers are such an edge case, it's barely even relevant.
Don't get me wrong, you don't owe anyone anything; don't feel compelled to fix those or act immediately, a downgrade is always possible by us users for such situations (which is what I did on the computer running Hyprland: I downgraded to 2.4.x, because usability is a pain with this issue). But I don't think keeping issues unreported is a good solution either, especially when as a user I don't know well enough interactions between the project and nw.js to know when the project can do something on its own, and when I should just report it straight to nw.js without knowing even a bit about how does it work.
So, I did the test and issue is still around when built from master on nw.js 0.80.
EDIT: As for the tray icon issue, it's probably something that should be reported upstream on nw.js tracker, but is it even worth it if nobody works on this anymore?
So, after playing with git bisect
, it found out the culprit commit was https://github.com/streamlink/streamlink-twitch-gui/commit/fa0d9a6424e34217644fb5f32750ff99f94e559e.
But I've already shown in https://github.com/streamlink/streamlink-twitch-gui/issues/1015#issuecomment-2115748765 that I could not reproduce the issue with older code but newer nw.js. In the end I could see that this commit was also changing the --disable-features=nw2
flag by removing it.
I concentrated investigations on this and could confirm several things:
v2.4.1
, I reproduce the issue;In the end, I can't tell what nw2 is changing nor why was it disabled and now reenabled, but it's the cause of the issue here, not the nw.js version.
NW2 is a re-implementation of NW.js's JS bindings. NW1 has been removed (or stopped working) in 0.85, hence the removal in this commit. This is also the reason why the exit confirmation dialog started working again, because the app's close
event is broken in NW1. However, in NW2, the app-window's blur
event is broken. This has been a pick-your-poison situation for me since at least one and a half years. The issue has been reported by me a long time ago with a couple of bumps, but without any responses.
Considering that the Linux and Windows builds are now stuck on 0.80 and 0.82 respectively, I can have a look at disabling NW2 again.
Resolved by 381a9a5cb507ed689b2127ad6afb67127582eef8 / ab45651abefddd9d39d515f184648214ba810c1b See #1015
Checklist
Streamlink Twitch GUI version
2.5.1
Streamlink version
6.7.4
Operating system, environment and configuration details
ArchLinux, Hyprland
Description
Since 2.5.X, probably due to nw.js changes, streamlink-twitch-GUI only offers floating or full screen modes at least on Hyprland, maybe also other compositors such as Sway. That means it gets stuck on foreground in both cases, unless we set another tile as fullscreen to go on top of it. In the end it completely breaks the tiling. This is a regression from 2.4.x which had no problems (I did a downgrade to check issue is gone on 2.4.x). Gnome gets no issue around this (which makes sense, no tiling by default).
Note that the problem is when it's running with the default parameters, ie. on XWayland. When forcing the use of Wayland with --ozone-platform=wayland, that issue is gone, but some other issues arise such as the default tray icon getting its own tile window.
Note that Hyprland maintener suggested it could be an issue with window requested max size and suggested to try to override it from Hyprland's side, but it didn't fixed anything. (If the max size is smaller than what the tile size would be, then Hyprland don't tile it).
Debug log
No relevant logs, but here are some n case it might show something interesting for some issues with some visible warnings/errors: