This pretty much sums up my feelings. :-) Regarding scroll indicators; mac already have them, so does GNOME, and the Windows 8 Metro will as well, so I don't really think this will be any problem. We are just a bit in front of our time :-)
Kenneth On Tue, Mar 27, 2012 at 8:05 PM, <[email protected]> wrote: > Hi, > > I'd like to raise the topic of the behaviour of the QML2 WebView element > across different platforms and devices once more. > Before we get into details however, I'd like to clarify one rather important > assumption or boundary condition about this element: > > The purpose of the QML2 WebView element is to enable the embedding of web > content in applications. This purpose should be > served on all platforms QML2 runs on, including (but not limited to) > traditional desktop platforms and all sorts of mobile devices. > > Writing a fully fledged web browser is beyond the scope of the element and > its API. Doing so requires a much tighter integration > that what the publically supported API can currently offer. We should right > now not clutter the API with functionality needed only by a > browser and apply the same to behavioural/visual aspects of the WebView > element. > > Anyone interested in developing a browser on top of the same "technology" > (QML2, WebKit2) may find the QML API a great starting > point, but it will at this point always require the use of private API. > > So with application embedding use-cases in mind, I'd like to revisit the > discussion about how the WebView element should behave > across different platforms. > > I recall our intent of giving the WebView a rather automatic behaviour when > it comes to the appearance. > > (1) For example that on Windows it should look and behave like a > traditional desktop web browsers, with scrollbars out of the box, layout > according to the element's width and platform themed form elements / popups. > > (2) At the same time when we were talking about fun mobile platforms like > the N9, the intent was to let the WebView be like the browser's > viewport: A fixed layout for web content, no traditional scrollbars, > behaviour as if the element was a QML2 Flickable (also in terms of > connecting it to scroll indicators). > > If you look at this from the point of view of writing a browser, it kind of > makes sense. But I'm starting to seriously doubt that this is a good > behaviour from an application embedding point of view, because it is > unpredictable and inconsistent compared to other QML elements. Another > example of this extensibility in the API: In the experimental section we've > been playing with the ability to allow users of the API to provide QML > components > that will be instantiated for dialog functionality, like alerts or file > uploads. It's not clear what these should be like on "desktop" platforms, > neither how to > implement them nor what the default should be (should there be one on windows > but not on Linux?) > > So instead I'd like to propose that we give the QML2 WebView element one > consistent behaviour and appearance across all platforms: > > * No scrollbars > * UIProcess sided scrolling with the kinetic flickable behaviour. > * Public inheritance from flickable would give one clear interface for > scroll indicators > * Semi-fixed layout (using properties that _can_ be bound to the element's > with - Jocelyn, do you remember the details of our discussion?). > * Form elements according to current "mobile" theme (this has room for > improvement if we manage to encapsulate the themeing like in Chromium) > > (In a nutshell: The currently implemented default!) > > I believe this would give us also consistent behaviour for things like QML > components for dialogs, because if for example filePicker is not defined, it > simply won't appear, there's no need for a "default" in WebKit. > > One aspect to consider here also in the light of the desktop platforms is Qt > desktop components. If Qt components for the desktop gets new momentum > in development, it could easily provide a WebView element itself that > > 1) Uses the QML2 WebView element as basis perhaps > 2) Can certainly use private APIs to provide a traditional > with-scrollbars-and-platform-theme element > > In the scope of Qt desktop components such an element would make perfect > sense, I believe. If somebody wants to develop a web browser using > QtWebKit and Qt 5 for desktop platforms (Qrome? ;-), then nothing stands in > the way of contributing to the private API and developing perhaps a new > QML element that could one day become publically supported API. But in the > meantime the QML2 WebView component has one behaviour everywhere, > a highly customizable building block for creating QML based applications that > embed web content. > > What do you think? > > > Simon > > _______________________________________________ > webkit-qt mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit.org http://codeposts.blogspot.com ﹆﹆﹆ _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
