Open PerBothner opened 2 years ago
We are using gtk3 which could set this via env variable. I think devs is able to set it themselves. Otherwise, we probably want to add some option in config of tauri.
I think we need to use set_overlay_scrolling because env variable will no longer supported in gtk4.
GTK 4 will no longer support GTK_OVERLAY_SCROLLING https://wiki.archlinux.org/title/GTK#Disable_overlay_scrollbars
And, I would like to take on this issue, is that a problem?
I don't think we should do anything in wry or tao regard this problem.
tao
already exposes WindowExtUnix::gtk_window
which users can use to call set_overlay_scrolling
, wdy think @wusyong ?
Maybe we could try to make a platform specific attribute like Tao does. And see how it goes.
I'm personally not a fan of add too many functions unless it's totally necessary. But looks like we should also look for the extension trait approach.
Alright, I will move this issue to tao
, @keiya01 you can take it.
I found this issue that was resolved the problem where gtk::Settings are not propagated to webkit. Unfortunately, I glanced at the latest release notes for WebkitGTK, the fix is not released. Could you have the other idea?
I want to use set_overlay_scrolling
declared on ScrolledWindow. However we can not access ScrolledWindow in gtk webview or window.
Therefore I think we need to use gkt::Settings
but it cannot be propagated to webkit yet.
I tried to use the following code, but this is not working
#[cfg(target_os = "linux")]
{
if let Some(settings) = wry::webview::WebviewExtUnix::webview(&webview).as_ref().settings() {
gtk::traits::SettingsExt::set_gtk_overlay_scrolling(&settings, false);
}
}
I couldn't find a reliable API to fix and setting the gtk-overlay-scrolling
directly resulted in a panic.
The only way is to set GTK_OVERLAY_SCROLLING
env var before creating the webivew:
std::env::set_var("GTK_OVERLAY_SCROLLING", "0");
which I think is enough for now.
Gtk uses "overlay scrollbars" which are only shown on mouseover. This saves space but causes some problems: For example you can't click in the area that is covered by the scrollbar. It also causes portability problems in terms of area calculations and event handling.
Overlay scrollbars are neat in some applications, but I don't think they should be the default for Wry applications. Ideally, it would be an option that can be overridden, but defaults to disabled.
I found this link helpful.