Bug 76777 - [Qt] QQuickWebView needs to choose style/scrollbars/etc. automatically depending on the underlying platform
Summary: [Qt] QQuickWebView needs to choose style/scrollbars/etc. automatically depend...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Simon Hausmann
URL:
Keywords:
Depends on:
Blocks: 76773
  Show dependency treegraph
 
Reported: 2012-01-20 23:36 PST by Simon Hausmann
Modified: 2012-04-01 23:12 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Hausmann 2012-01-20 23:36:49 PST
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.
Comment 1 Kenneth Rohde Christiansen 2012-01-22 11:57:40 PST
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)
Comment 2 Simon Hausmann 2012-01-23 00:34:09 PST
(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?
Comment 3 Kenneth Rohde Christiansen 2012-01-23 01:36:42 PST
(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.
Comment 4 Balazs Kelemen 2012-03-27 10:18:59 PDT
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?
Comment 5 Simon Hausmann 2012-03-29 07:42:48 PDT
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 :)
Comment 6 Balazs Kelemen 2012-03-30 16:23:48 PDT
(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"? :)
Comment 7 Simon Hausmann 2012-04-01 23:12:16 PDT
(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.