76777 2012-01-20 23:36:49 -0800 [Qt] QQuickWebView needs to choose style/scrollbars/etc. automatically depending on the underlying platform 2012-04-01 23:12:16 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 76773 1 hausmann hausmann kbalazs kenneth oldest_to_newest 540078 0 hausmann 2012-01-20 23:36:49 -0800 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. 540308 1 kenneth 2012-01-22 11:57:40 -0800 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) 540409 2 hausmann 2012-01-23 00:34:09 -0800 (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? 540435 3 kenneth 2012-01-23 01:36:42 -0800 (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. 589011 4 kbalazs 2012-03-27 10:18:59 -0700 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? 591182 5 hausmann 2012-03-29 07:42:48 -0700 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 :) 592634 6 kbalazs 2012-03-30 16:23:48 -0700 (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"? :) 593189 7 hausmann 2012-04-01 23:12:16 -0700 (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.