NW.js version issues #1015
Comments
|
So, some additional information after testing different configurations. Better: Building As for the tray icon issue, I don't think it's a regression and the issue probably was always there, but a quick search on nw.js issue tracker didn't show anything ringing a bell. Is it for sure nw.js managing this? If yes I'm guessing something should be reported there, but with little to no hope this would be fixed I guess. EDIT: More details added on #1012 (comment) ; in the end it appears that the nw.js version is not the culprit. The nw2 feature flag is. |
This is a list about recent NW.js versions and their issues on specific systems. Since a200698 (upcoming
v2.5.2release), Streamlink Twitch GUI now uses different NW.js versions per platform.At the time of writing this, the latest NW.js version is
0.87.0with Chromium 124.See down below for how to help and a few comments about NW.js.
NW.js issues
*>=0.85*closeevent does not get triggered*blurevent is not triggered when losing focus for the first timev2.5.0changelog*>=0.83,<0.85("NW2" mode)>=0.78.1,<0.80llvm-libs 17.0.6-4on Arch Linuxv2.5.0changelog>=0.82,<0.85("NW2" mode)>=0.80,<0.84("NW2" mode)restoreevent doesn't trigger when unmaximizing, causing window state (and thus the maximize button) to break. Affects restored window position/state on startup.>=0.80>=0.85v2.5.1changelog*openevent when launching the app more than once doesn't trigger when opening the.app, only when running the NW.js executable directly>=0.85("NW2" mode),>=0.84("NW1" mode)openevent when launching the app more than once does trigger only for the first timeNote about Wayland on Linux
Chromium still defaults to their X11 Ozone platform implementation, even on Wayland sessions (Arch Linux Wiki), resulting in the application being run as an XWayland client. This can be prevented by forcing the Wayland Ozone platform implementation by launching the application using the
--ozone-platfrom=waylandlaunch argument. So far, I've avoided adding a wrapper launch script for automatically setting this launch argument depending on the user's desktop session, but considering that some major issues now arise in recent versions when forcing the Wayland mode on specific compositors, this means that adding a wrapper launch script is currently not possible.Testing different NW.js versions
Which NW.js version gets used in a build depends on the config here:
https://github.com/streamlink/streamlink-twitch-gui/blob/master/build/tasks/configs/nwjs.js#L27-L81
This tells
nw-builderwhich NW.js version to use when running tests or building the application.If you want to help me out checking new or specific NW.js releases for any issues, then please build the application from the
masterbranch and change the version number in the linked config file prior to building.https://github.com/streamlink/streamlink-twitch-gui/blob/master/CONTRIBUTING.md#developing-and-building
A list of all NW.js versions can be found here:
Most NW.js features/behaviors can only be tested manually because they interact with the OS / desktop environment. Automated tests can only check internal NW.js APIs, which doesn't guarantee that something is actually working. This is the reason why it's difficult for me to always be sure that bumping NW.js to a newer version won't break anything.
Streamlink Twitch GUI and NW.js
I started working on "Streamlink Twitch GUI" ("Livestreamer Twitch GUI" back then) at the end of 2013 (4216a49). NW.js had existed since 2011 ("node-webkit" back then), allowing users to write OS-independent Node.JS GUI web applications for the first time. The project was founded by Roger Wang and sponsored by Intel. During these early times though, one of node-webkit's co-devs left the project and founded ElectronJS. With the backing of GitHub for their Atom code editor (sunset in 2022), ElectronJS gained way more attraction and became the "industry standard" very quickly early on.
The lack of popularity for NW.js caused lots of issues over the years. This started with lack of packaging options on Linux, because NW.js was not built and packaged by any distro, requiring me to always bundle pre-built NW.js binaries, like on macOS and Windows, and this prevented the application from being included in most distro package repositories.
On top of this, NW.js has been pretty much a one-man-show run by Roger Wang, with lack of a healthy community with tooling projects, as well as documentation. Nowadays, the project is seeing very little development and tons of issues have piled up. The
nw-builderproject also was abandoned by its author(s) multiple times, so I "maintained" a private fork that's only used here and barely works.ElectronJS
As said in other issues, I've always played with the thought of switching to ElectronJS, since 2016 already, but this is far from easy, for several reasons. This would require lots of work in terms of build config changes and app code changes, especially since NW.js and ElectronJS work a bit differently (shared context mode, etc).
Considering that I've lost most of my motivation working on Streamlink Twitch GUI because of all the tech-dept, like it being based on EmberJS for example (one of the three big promising JS frameworks in 2013 - which is also dead for several years now), as well as all these Twitch API and Streamlink restrictions over the past years (see the changelog), starting work on switching to ElectronJS is very far down on my to-do-list.
I've only been keeping Streamlink Twitch GUI alive for the past years without adding any major new features, but with the recent NW.js issues I'm now at a point where keeping the project alive and the application usable on all platforms, moving from NW.js to ElectronJS has become more and more of a necessity. I haven't made any plans at all yet, but if these issues can't be resolved, I probably won't have a different choice.
The text was updated successfully, but these errors were encountered: