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.
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)
(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?
(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.
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?
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 :)
(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"? :)
(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.