On Tue, Mar 27, 2012 at 4:44 PM, Alexis Menard <[email protected]> wrote: > On Tue, Mar 27, 2012 at 3:05 PM, <[email protected]> wrote: >> Hi, >> > > Hi Simon, > >> 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 > > I really don't like that. I wonder how I will scroll on desktop with > my mouse? On Mac when you plug a regular mouse the scrollbars keep > being always visible -> good. When you use the magic trackpad and > unplug the mouse they hides automatically. > >> * UIProcess sided scrolling with the kinetic flickable behaviour. > > On desktop with a mouse (not a magic track pad) it doesn't make any > sense to me if it it like today in the mobile mode (i.e. I left click > and long press it and it kinetic scroll). It's awkward at best, it's > nice to play with but not useful. On Mac when you have a regular mouse > it doesn't do any flickable effect while left clicking unless you > start using the trackpad with two fingers. We should do the same as > everyone doesn't seem to be bothered with the way it works. > > Of course the wheel needs to work. > >> * 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) > > The latter needs to be improved on desktop. I already talked to Pierre > about that. > > All my use cases are based on let say a RSS reader on desktop. > >> >> (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?
And selection need to work on desktop :) >> >> >> Simon >> >> _______________________________________________ >> webkit-qt mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt > > > > -- > Alexis Menard (darktears) > Software Engineer > INdT Recife Brazil -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
