Bug 76777
| Summary: | [Qt] QQuickWebView needs to choose style/scrollbars/etc. automatically depending on the underlying platform | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Hausmann <hausmann> |
| Component: | New Bugs | Assignee: | Simon Hausmann <hausmann> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | kbalazs, kenneth |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 76773 | ||
Simon Hausmann
For example on Windows we want to render scrollbars and use QStyle for themeing.
When running on a mobile Linux platform we may want to delegate the scroll indicator rendering
to the application and use the mobile theme.
This is potentially a meta-bug, but in practice we should get rid of WebView.experimental.useTraditionalDesktopBehaviour.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Kenneth Rohde Christiansen
I am not sure this is feasible for Qt5, because we will need a lot of other things as well, such as copy/paste. Maybe we should instead spend a bit of time making sure that the WebKit1 API actually works, as it doesn't seem so currently (Web Inspector renders half black for me)
Simon Hausmann
(In reply to comment #1)
> I am not sure this is feasible for Qt5, because we will need a lot of other things as well, such as copy/paste. Maybe we should instead spend a bit of time making sure that the WebKit1 API actually works, as it doesn't seem so currently (Web Inspector renders half black for me)
Hm, are you suggesting that we leave out the WK2 QML API from Qt 5.0.0?
Kenneth Rohde Christiansen
(In reply to comment #2)
> (In reply to comment #1)
> > I am not sure this is feasible for Qt5, because we will need a lot of other things as well, such as copy/paste. Maybe we should instead spend a bit of time making sure that the WebKit1 API actually works, as it doesn't seem so currently (Web Inspector renders half black for me)
>
> Hm, are you suggesting that we leave out the WK2 QML API from Qt 5.0.0?
No, of course not :-) I just suggest that we don't necessarily make sure it covers all desktop cases as the QWidget version (webkit1) is still available.
We could make it the target for a subrelease instead.
Balazs Kelemen
Let me check if I understand the task. It's about implementing smg like the qstyle theme without depending on widgets, right? Or it's ok to just reuse the existing RenderThemeQStyle?
Simon Hausmann
Based on the discussion on webkit-qt I'm closing this as WONTFIX. Let's keep the WebView as a simple component that implements one well defined behaviour and can also be used as a building block in more platform specific component sets.
This is largely what today's WebView element does :)
Balazs Kelemen
(In reply to comment #5)
> Based on the discussion on webkit-qt I'm closing this as WONTFIX. Let's keep the WebView as a simple component that implements one well defined behaviour and can also be used as a building block in more platform specific component sets.
>
> This is largely what today's WebView element does :)
Don't you think we should add private API for those "more platform specific component sets"? :)
Simon Hausmann
(In reply to comment #6)
> (In reply to comment #5)
> > Based on the discussion on webkit-qt I'm closing this as WONTFIX. Let's keep the WebView as a simple component that implements one well defined behaviour and can also be used as a building block in more platform specific component sets.
> >
> > This is largely what today's WebView element does :)
>
> Don't you think we should add private API for those "more platform specific component sets"? :)
Sure, private API used to implement more platforms specific components is fine, but that is different from this bug, which was abut _automatic_ behaviour of the existing WebView component.