[webkit-qt] QML2 WebView and viewport meta tag (on Desktop)
Lars Knudsen
larsgk at gmail.com
Sat Feb 16 14:32:57 PST 2013
Hi again,
just FYI - I ended up with the following temporary hack solution (that
works somewhat - I still need to check if there is a great performance
penalty on RaspberryPi):
I made a derived class of QQuickWebView (EduWebView) and added the
following:
void EduWebView::widthChanged ( int width )
{
// This is a hack. It needs to be here until the WebView is fixed to support
// viewport meta tag AND mouse events at the same time.
// QWebPage::ViewportAttributes va =
page()->viewportAttributesForSize(page()->viewportSize());
qreal viewportWidthDummy = 1920.0; // Hard coded - how to find the
above/equivalent in QQuickWebView?
qreal zf = ((qreal)width)/viewportWidthDummy;
setZoomFactor(zf);
}
Then - from the QML, I did this:
Component.onCompleted: webView.widthChanged(width)
onWidthChanged: {
webView.widthChanged(width)
}
It seems to work - as long as I design the apps to assume the same hard
coded resolution (I might put that out in an app descriptor/app - less hard
coded).
NOTE: I did find some strange rendering artifact when using border-image
(some sides and corners got rendered with an offset) combined with
setZoomFactor, but as no other elements I have used have any similar
rendering artifacts, I assume there must be a bug in the code that renders
the border-image.
Of course, this is not the perfect solution, but seems to work better than
any alternative available to me at the moment (unless I get cross-compiling
working for the RaspberryPi and do my own hacks in QtWebKit ;))
The best would be if it would be possible to get better control over the
behavior of the viewport-respecting flickable web view in an update to Qt5.
br
Lars
On Fri, Feb 15, 2013 at 8:55 PM, Lars Knudsen <larsgk at gmail.com> wrote:
> Thanks Andras and Jocelyn,
>
> I will do some work on this in the weekend and get back to you with the
> results.
>
> - Lars
>
> PS: The project I am working on:
> http://opensourcedays.org/2013/content/education-kit-built-webapps-raspberry-pi-and-arduino
>
>
>
>
> On Fri, Feb 15, 2013 at 6:33 PM, Andras Becsi <abecsi at webkit.org> wrote:
>
>> Hi again,
>>
>> On 15 February 2013 16:41, Lars Knudsen <larsgk at gmail.com> wrote:
>>
>>> just to recap my troubles and findings for QML2/WebView:
>>>
>>> 1. if you want to have (somewhat) working viewport meta tag support, you
>>> should use the WebView as it is - without fiddling with any experimental
>>> features.
>>> However:
>>> a) Only very few mouse events will be sent to the page (e.g. try with
>>> http://dunnbypaul.net/js_mouse/) - looks like mouse move and click (the
>>> rest is caught by the flickable surface (zoom/pan) and are never sent to
>>> the page
>>> b) Somehow, zoom/pan is still possible when specifying the
>>> maximum/initial/minimum scale = 1 and user-scalable=no .. even when
>>> creating a surface that would steal all touch and mouse events (working on
>>> iPad)
>>>
>>
>> Zooming should not be possible if you set user-scalable=no, not event
>> with double-tap (double-click). If it is possible, then it is a bug.
>>
>> 2. if you want to have the forced pan/zoom disabled and the mouse events
>>> back, you need to specify
>>> QQuickWebViewExperimental::setFlickableViewportEnabled(false); - BUT - an
>>> unfortunate side effect of this is that the viewport meta tag seems to be
>>> ignored. Leaving the WebView back to the same behavior as most desktop
>>> browsers have.
>>>
>>
>>> In my particular case, I need to have a WebView filling out the complete
>>> window, where mouse (or touch) events are all sent to the page. I also
>>> need the viewport meta tag to be respected as I am making a WebApps centric
>>> 'browser' window to be used on RaspberryPi and PC's running full screen
>>> (mostly) in developing regions (where you never know what resolution you
>>> will be hooked up to). Additionally, It would be VERY helpful if the
>>> parameters to the viewport metatag would make the browser window behave as
>>> on the iDevices - simply locking the screen (well - the width at least) to
>>> the size specified.. and then HANDS OFF ;)
>>>
>>
>> As said in my previous e-mail, the current WebView is a subclass of
>> Flickable.
>> Thus you might want to consider setting boundsBehavior:
>> Flickable.StopAtBounds for your web app, to disable the bounce back
>> animation.
>>
>> And also, for a web app where you control the content, you could maybe
>> make your "browser" application more specific and experiment with a WebView
>> with experimental settings like (accordin to your example from before):
>>
>> experimental.useDefaultContentItemSize: false
>> contentWidth: rootPanel.width
>> contentHeight: rootPanel.height
>>
>> Note, that this is highly experimental, and the property might go away in
>> future versions without notice, but for specialized use-cases like this it
>> could help to adopt the WebView.
>>
>> Personally, I think that if a page has a viewport meta tag specified, it
>>> does not make sense in ANY case I can think of NOT to respect it. I really
>>> don't understand why only Internet Explorer (to my knowledge) behaves like
>>> this (and no - I don't enjoy using windows ;)).
>>>
>>> I can make some test pages and file the bugs - but I think a BIG step
>>> forward would be to start using the viewport meta tag in ANY context.
>>>
>>
>> Opening bugs with test pages would be highly valuable, and very much
>> appreciated :)
>>
>> /Andras
>>
>> br
>>> Lars
>>>
>>>
>>>
>>> On Fri, Feb 15, 2013 at 3:00 PM, Lars Knudsen <larsgk at gmail.com> wrote:
>>>
>>>> Hi Jocelyn,
>>>>
>>>> Also, setting the following will make the WebView completely ignore any
>>>> viewport settings:
>>>>
>>>> QQuickWebViewExperimental::setFlickableViewportEnabled(false);
>>>>
>>>>
>>>> But if I don't disable the flickable viewport, then mouse and touch
>>>> clicks (with the mouse) behave strangly - AND double-click will zoom.
>>>>
>>>> hmmm... I guess I am back to some hack needed by deriving from
>>>> QQuickWebView and setting the zoom factor directly based on the
>>>> relationship between the width in the meta tag and the window width.
>>>>
>>>> This seemed to work when using QWebView - but I still havent found the
>>>> equivalent for QQuickWebView:
>>>>
>>>> void MainWebView::resizeEvent ( QResizeEvent * event )
>>>>
>>>> {
>>>>
>>>> QWebView::resizeEvent(event);
>>>>
>>>> QWebPage::ViewportAttributes va = page()->viewportAttributesForSize(page()->viewportSize());
>>>>
>>>> qreal zf = ((qreal)width())/va.size().width();
>>>>
>>>> setZoomFactor(zf);
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> br
>>>>
>>>>
>>>> Lars
>>>>
>>>>
>>>>
>>>> On Fri, Feb 15, 2013 at 12:27 PM, Lars Knudsen <larsgk at gmail.com>wrote:
>>>>
>>>>> Hi Jocelyn,
>>>>>
>>>>> I am getting half way there by removing the max and initial scale -
>>>>> but now window resizes don't have control over the zoom/scale when the
>>>>> content grows outside the window or double-click to zoom happens .
>>>>> Previously, I have combined the max/min/initial scale values on iPad to
>>>>> lock down all kinds of accidental zooming/panning when making webapp
>>>>> demos/games. But maybe that's abusing the system ;)
>>>>>
>>>>> - Lars
>>>>>
>>>>>
>>>>> On Fri, Feb 15, 2013 at 12:18 PM, Jocelyn Turcotte <
>>>>> jocelyn.turcotte at digia.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> humm I just realized that what you want is a zoom out, so
>>>>>> maximum-scale shouldn't prevent that, minimum-scale would.
>>>>>>
>>>>>> The initial-scale=1 along with user-scalable=no on the other hand
>>>>>> might be forcing it.
>>>>>> So maybe you could play along those lines.
>>>>>> It's also quite possible that you're hitting a bug in our code, I'd
>>>>>> be interested to know if you find any bad behavior.
>>>>>>
>>>>>> The spec is there if you are able to read this kind of language:
>>>>>> http://dev.w3.org/csswg/css-device-adapt/
>>>>>> We should follow it as best as we can.
>>>>>>
>>>>>> br,
>>>>>> Jocelyn
>>>>>>
>>>>>> On Fri, Feb 15, 2013 at 12:12:55PM +0100, Lars Knudsen wrote:
>>>>>> > I just tried it on my android tablet, where it works. It could be
>>>>>> that the
>>>>>> > params are interpreted differently on chrome/mobile and
>>>>>> qml2/webview.
>>>>>> >
>>>>>> > I'll try without min/max scale now.
>>>>>> >
>>>>>> > br
>>>>>> > Lars
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Feb 15, 2013 at 12:10 PM, Jocelyn Turcotte <
>>>>>> > jocelyn.turcotte at digia.com> wrote:
>>>>>> >
>>>>>> > > Hello Lars,
>>>>>> > >
>>>>>> > > This is pretty rusty stuff in my head, but doesn't
>>>>>> maximum-scale=1 mean
>>>>>> > > that you force a 1:1 pixel ratio of the page pixels with screen
>>>>>> pixels?
>>>>>> > >
>>>>>> > > To me it feels that using anything else than "width=device-width"
>>>>>> with
>>>>>> > > "maximum-scale=1" means that you do not want a view that fits the
>>>>>> screen to
>>>>>> > > width.
>>>>>> > >
>>>>>> > > br,
>>>>>> > > Jocelyn
>>>>>> > >
>>>>>> > >
>>>>>> > > On Fri, Feb 15, 2013 at 11:57:37AM +0100, Lars Knudsen wrote:
>>>>>> > > > Hi,
>>>>>> > > >
>>>>>> > > > I am having some trouble getting WebView to respect the
>>>>>> viewport meta
>>>>>> > > tag.
>>>>>> > > >
>>>>>> > > > I am including a test project (qt5) that should show the
>>>>>> problem.
>>>>>> > > >
>>>>>> > > > In the index.html file, I have:
>>>>>> > > >
>>>>>> > > > <!DOCTYPE html>
>>>>>> > > >
>>>>>> > > > <html>
>>>>>> > > >
>>>>>> > > > <head>
>>>>>> > > >
>>>>>> > > > <title>Demo App</title>
>>>>>> > > >
>>>>>> > > > <meta name="viewport" content="width=1024, initial-scale=1,
>>>>>> > > > maximum-scale=1, user-scalable=no">
>>>>>> > > >
>>>>>> > > > <style type="text/css">
>>>>>> > > >
>>>>>> > > > #block {
>>>>>> > > >
>>>>>> > > > position: absolute;
>>>>>> > > >
>>>>>> > > > left: 256px;
>>>>>> > > >
>>>>>> > > > top: 256px;
>>>>>> > > >
>>>>>> > > > width: 512px;
>>>>>> > > >
>>>>>> > > > height: 512px;
>>>>>> > > >
>>>>>> > > > background-color: red;
>>>>>> > > >
>>>>>> > > > }
>>>>>> > > >
>>>>>> > > > </style>
>>>>>> > > >
>>>>>> > > > </head>
>>>>>> > > >
>>>>>> > > > <body>
>>>>>> > > >
>>>>>> > > > <h1>TEST</h1>
>>>>>> > > >
>>>>>> > > > <div id="block"></div>
>>>>>> > > >
>>>>>> > > > </body>
>>>>>> > > >
>>>>>> > > > </html>
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > In the main.cpp, I have:
>>>>>> > > >
>>>>>> > > > QtQuick2ApplicationViewer viewer;
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > viewer.setResizeMode(QQuickView::SizeRootObjectToView);
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > >
>>>>>> viewer.setMainQmlFile(QStringLiteral("qml/SimpleWebAppRunner/main.qml"));
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > // Select the app to load
>>>>>> > > >
>>>>>> > > > QQmlProperty property((QObject*)(viewer.rootObject()),
>>>>>> "appToLoad");
>>>>>> > > >
>>>>>> > > > property.write("SimpleWebApp");
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > viewer.showExpanded();
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > In the QML, I have:
>>>>>> > > >
>>>>>> > > > import QtQuick 2.0
>>>>>> > > >
>>>>>> > > > import QtWebKit 3.0
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > Rectangle {
>>>>>> > > >
>>>>>> > > > id: rootPanel
>>>>>> > > >
>>>>>> > > > width: 800
>>>>>> > > >
>>>>>> > > > height: 600
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > property string appBaseUrl: "../../apps/"
>>>>>> > > >
>>>>>> > > > property string appToLoad: ""
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > WebView {
>>>>>> > > >
>>>>>> > > > id: webView
>>>>>> > > >
>>>>>> > > > anchors.fill: parent
>>>>>> > > >
>>>>>> > > > url: ""
>>>>>> > > >
>>>>>> > > > onUrlChanged: console.log("Loading " + url)
>>>>>> > > >
>>>>>> > > > }
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > onAppToLoadChanged: {
>>>>>> > > >
>>>>>> > > > webView.url = appBaseUrl + appToLoad + "/index.html"
>>>>>> > > >
>>>>>> > > > }
>>>>>> > > >
>>>>>> > > > }
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > The whole web view seems to resize fine when resizing the QML
>>>>>> window -
>>>>>> > > but
>>>>>> > > > content does not scale like it should (like on a mobile device)
>>>>>> -
>>>>>> > > > basically, scaling/zooming it <window width>/<viewport
>>>>>> witdth=1024px>.
>>>>>> > > >
>>>>>> > > > Can anyone tell me what I am doing wrong? (maybe I am just
>>>>>> blind from
>>>>>> > > > looking at the code too long - and the answer is obvious..
>>>>>> please tell
>>>>>> > > :)).
>>>>>> > > >
>>>>>> > > > br
>>>>>> > > > Lars
>>>>>> > >
>>>>>> > >
>>>>>> > > > _______________________________________________
>>>>>> > > > webkit-qt mailing list
>>>>>> > > > webkit-qt at lists.webkit.org
>>>>>> > > > https://lists.webkit.org/mailman/listinfo/webkit-qt
>>>>>> > >
>>>>>> > >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> webkit-qt mailing list
>>> webkit-qt at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-qt
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20130216/d91f6e18/attachment-0001.html>
More information about the webkit-qt
mailing list