[Webkit-unassigned] [Bug 208129] [GTK] Stop using gtk foreign drawing API to style form controls

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=208129

--- Comment #17 from Adrian Perez <aperez at igalia.com> ---
(In reply to Michael Catanzaro from comment #16)
> (In reply to Carlos Garcia Campos from comment #14)
> > For GTK3 the only solution I see is to bring back the old code and add a new
> > setting (useSystemAppearance), disabled by default, that apps can use to
> > keep the consistency.
> 
> Compromise proposal: do this, but enabled by default, and only for
> scrollbars. All the web form controls can use Adwaita theme. Scrollbar is
> going to be more important than form controls since having a non-native
> scrollbar will look really out of place. The rest is just web content, and
> it's not expected that web content look native. Then when GTK 4 comes
> around... well, I don't know what to do for GTK 4, but I think retaining
> native scrollbar would be enough to avoid most complaints. Maybe we could
> try moving the scrollbar to the UI process, except when it's actually themed
> by websites (in which case it has to be in the web process no matter what).
> 
> Maybe we could add a config file or some other way of configuring a color
> scheme on top of Adwaita that Yaru and Granite (and other themes) could use,
> without creating a completely separate RenderTheme class that would be tough
> to maintain.

Wild idea: can we expose somehow in the WebKitWebView API the information
that an embedder might need to render a scrollbar? I think the following
additions each scrollbar should suffice:

 - Current position, range [0.0, 1.0].
 - Size of the viewport vs. page height (to know how long the thumb
   needs to be).
 - Whether the web view needs to show a scrollbar (e.g. FALSE if content
   does not need it, or if CSS has been used to override the default
   scrollbar look).
 - A new method to scroll to a given position.

Am I being too naïve with this idea?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200319/682828c4/attachment-0001.htm>