search

streamlink / streamlink-twitch-gui

A multi platform Twitch.tv browser for Streamlink
https://streamlink.github.io/streamlink-twitch-gui/
MIT License
2.65k stars 200 forks source link

On small windows below minimum width, horizontal scroll is broken if there's vertical one #1001

Closed Porkepix closed 4 months ago

Porkepix commented 4 months ago

Checklist

Streamlink Twitch GUI version

2.4.1

Streamlink version

6.6.2

Operating system, environment and configuration details

ArchLinux, issue reproduced on a tiling Window manager (would not happen for example on Gnome I think).

Description

This can be a nw.js bug, can't be sure. When Streamlink Twitch GUI is launched in a tiling window manager that can therefore open it as a quite small window, it might imply the need for horizontal scrolling when the minimum width isn't respected (in views with thumbnails, it seems to be the width of three of them for example).

This horizontal scrolling is visible with a scrollbar and works (with the trackpad) if there's no vertical one. But as soon as the height isn't big enough anymore and needs vertical scrolling, horizontal one cease to work.

Debug log

No response

bastimeyer commented 4 months ago

Streamlink Twitch GUI properly advertizes its minimum window width (960px) and height (540px) to the compositor / window manager. When these window properties are ignored by the user's window manager (due to space constraints or user overrides), then there's nothing that can be done here, because it's not supported. The window's minimum size is set for a reason, to be able to have an app layout that's guaranteed to work while being useful on this small scale. The width and height values are also not chosen arbitrarily and and simply 1/4 of 1920x1080, so a quarter of a full-HD screen resolution. I'm aware that this can cause issues on tiling window managers which also show a gap, but I don't care about these kinds of edge cases.

The way the application behaves is still correct, btw. Scrolling within the app's main content area scrolls the content, while scrolling outside of it scrolls the whole application content (the DOM body). Scrolling with the cursor on the top bar doesn't work (and never has been), because it's a window drag-zone. This is the case on the whole top bar, which includes a small fraction underneath the logo, search bar and window buttons.

Example of the window size being overridden by KWin's window rules, with a size of 600x400 pixels:

https://github.com/streamlink/streamlink-twitch-gui/assets/467294/2a77bfc8-d2b2-4f1e-8b55-6a8daafb2676

The window's scrollbars do of course only appear when overriding the window's min width/height. This was requested years ago by a user who was using a tiling window manager with gaps who accepted this compromise solution.

Porkepix commented 4 months ago

@bastimeyer Can't see the video, somehow browser complains the file is corrupt…?

Indeed, doing horizontal scrolling from the sidebar works. That's so counter-intuitive I didn't thought about testing this.

However, wouldn't it be possible to have some logic such as "if that scrolling can't be done/exist in this level of the DOM, then try it to the one above if it's hovered"? (I'm not sure my formulation is clear, let me know if that isn't).

What's especially curious is that the horizontal scroll works from the thumbnails place (eg. Followed streams one) if there are low enough of them to fit vertically. As soon as there are too many of them (more than six for example) to fit, then vertical scrolling appears… and horizontal one over the thumbnails gets broken.

EDIT: Also, not sure about this, but maybe nw.js, the same way as electron, is forcing the use of XWayland/isn't yet compatible with Wayland, and therefore can have some difficulties managing multi-directional scrolls and so on? (I didn't checked it).

bastimeyer commented 4 months ago

Reload the page if you can't view the video. GitHub adds expiry data to embedded video URLs. Otherwise, watch it in a local video player. It's a regular and valid mp4 container.

I'm not going to change any scroll logic. The scrolling in the content area is handled by the smooth scrolling implementation (last modified 5 years ago), which has been forked a couple of years ago from another library and has been heavily modified by me since. The mousewheel events only propagate to the first parent node which has overflowing content, namely the main content node (never the body node), and keyboard events (arrow buttons) are always tied to the main content node.

If you look at the video, you can see that if the window gets shrinked beyond its intended min-width or min-height that there are scrollbars shown for the whole app window. As said, this is a good enough trade-off, so I'm not going to make any further modifications. I can't support every weird use case here. If this is a major issue for you, then you need to make the necessary modifications yourself, sorry.

No idea about any XWayland issues, because I'm still on X11. The version of NW.js/Chromium that's currently used here though doesn't have native wayland support yet, so XWayland is being used on Wayland sessions. In order to force experimental Wayland support, you need to launch the app using the --ozone-platform=wayland parameter. https://wiki.archlinux.org/title/Chromium#Native_Wayland_support

Porkepix commented 4 months ago

@bastimeyer While I'm at it about things I discovered on that tiling compositor, one "issue" I've seen comes from the fact that, if I understand it correctly, Streamlink Twitch GUI starts in a mode considered to be fullscreen by the compositor, am I right?

I've looked a bit at the options from nw.js some times ago but I'm really not sure about what I've found. Is it like I think starting as "fullscreen", and like I'm afraid a "maximized" mode doesn't exist, it's either "fullscreen" or "windowed"?

If I'm wrong, would such a maximized mode be possible (I'd open a dedicated issue).

For the context, the tested compositor is Hyprland, and one default behavior was that "Fullscreen" windows covers every other window, so at first I didn't understand what was happening and thought about a bug somewhere, but I probably don't think it's a bug anymore.

bastimeyer commented 4 months ago

No, it does not start in any "fullscreen" mode. The starting window conditions are here: https://github.com/streamlink/streamlink-twitch-gui/blob/v2.4.1/src/app/package.json#L12-L17 And the window state (size, maximized, visibility) gets changed after initialization here: https://github.com/streamlink/streamlink-twitch-gui/blob/v2.4.1/src/app/init/instance-initializers/nwjs/instance-initializer.js#L52-L77 https://github.com/streamlink/streamlink-twitch-gui/blob/v2.4.1/src/app/init/instance-initializers/nwjs/parameters.js

maximized mode

https://github.com/streamlink/streamlink-twitch-gui/wiki/Parameters#--maximize---max---maximized

Porkepix commented 4 months ago

Ugh, I don't understand then why the compositor consider the window as if it was a fullscreened one… I have nothing else using nw.js to compare how it behave, but anyway Streamlink Twitch GUI have nothing to do with this strange behavior then.