Qt4-preview-feedback Archive, April 2008
IFrames, qt-plugins and printing in QT Webkit demo browser
Message 1 in thread
Hi there,
I was testing the demo browser that came in latest QT 4.4 for Windows
snapshot (20080404). I created a very simple qtplugin.html page containing
the code proposed by Benjamin Meyer in this post:
http://labs.trolltech.com/blogs/category/labs/internet/webkit/
- qtplugin.html code (I've also added an ordinary image on it so that I
could compare the behaviour of an image against the behaviour of the qt
plugin):
<html>
<body>
Image:<br/>
<img src="
http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
width="80" height="80"/>
<br/>
QT progress bar:
<br/>
<object type="application/x-qt-plugin" classid="QProgressBar"
name="progressbar" height=30></object>
<script>
function display(){
if (++document.progressbar.value != 100)
setTimeout("display()", 50)
}
display();
</script>
</body>
</html>
This code works fine, the demo browser loads it and displays the image and,
under it, a nice QProgressBar embedded as a QT plugin inside the web page.
The problem is: if I embed this webpage into another one using an IFrame,
the embedded QProgessBar will not appear in the correct position inside the
main page, although the rest of the IFrame does it.
For example:
- iframe.html code:
<html>
<head>
<div>
Plugin test within an iframe:
</div>
<div style="float:right;">
<IFRAME SRC="/qtplugin.html" FRAMEBORDER="0" width="100%" height="100%"
></IFRAME>
</div>
</body>
</html>
Now, the IFrame inside this page will try to load qtplugin.html to the right
side of the page. The image appears fine in the demo browser, in the right
part of the screen. But the progress bar appears in the left part of the
screen, that is, outside of its parent IFrame.
Anyone could confirm if this also occurs to you?
Another thing: when I try to print preview the qtplugin.html page, the
progressbar doesn't show, only the text and the image. Maybe because the
plugins printing functions are still not implemented?
Cheers,
Beto
Message 2 in thread
Another problem with the embedded qt-plugin is: if you resize the browser,
the plugin widget is rendered well in its new location. But if you use the
scroll bars to move the page (vertically or horizontally), the plugin widget
rendering is not properly done.
On Fri, Apr 4, 2008 at 4:58 PM, Beto Boullosa <beto@xxxxxxxxxxxx> wrote:
> Hi there,
>
> I was testing the demo browser that came in latest QT 4.4 for Windows
> snapshot (20080404). I created a very simple qtplugin.html page containing
> the code proposed by Benjamin Meyer in this post:
> http://labs.trolltech.com/blogs/category/labs/internet/webkit/
>
> - qtplugin.html code (I've also added an ordinary image on it so that I
> could compare the behaviour of an image against the behaviour of the qt
> plugin):
>
> <html>
> <body>
> Image:<br/>
> <img src="
> http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
> width="80" height="80"/>
> <br/>
> QT progress bar:
> <br/>
> <object type="application/x-qt-plugin" classid="QProgressBar"
> name="progressbar" height=30></object>
> <script>
> function display(){
> if (++document.progressbar.value != 100)
> setTimeout("display()", 50)
> }
> display();
> </script>
> </body>
> </html>
>
> This code works fine, the demo browser loads it and displays the image
> and, under it, a nice QProgressBar embedded as a QT plugin inside the web
> page.
>
> The problem is: if I embed this webpage into another one using an IFrame,
> the embedded QProgessBar will not appear in the correct position inside the
> main page, although the rest of the IFrame does it.
>
> For example:
> - iframe.html code:
>
> <html>
> <head>
> <div>
> Plugin test within an iframe:
> </div>
> <div style="float:right;">
> <IFRAME SRC="/qtplugin.html" FRAMEBORDER="0" width="100%" height="100%"
> ></IFRAME>
> </div>
> </body>
> </html>
>
> Now, the IFrame inside this page will try to load qtplugin.html to the
> right side of the page. The image appears fine in the demo browser, in the
> right part of the screen. But the progress bar appears in the left part of
> the screen, that is, outside of its parent IFrame.
>
> Anyone could confirm if this also occurs to you?
>
> Another thing: when I try to print preview the qtplugin.html page, the
> progressbar doesn't show, only the text and the image. Maybe because the
> plugins printing functions are still not implemented?
>
> Cheers,
>
> Beto
>
Message 3 in thread
On Friday 04 April 2008 16:58:47 Beto Boullosa wrote:
> Now, the IFrame inside this page will try to load qtplugin.html to the
> right side of the page. The image appears fine in the demo browser, in the
> right part of the screen. But the progress bar appears in the left part of
> the screen, that is, outside of its parent IFrame.
>
> Anyone could confirm if this also occurs to you?
>
I can confirm this. The issue is that in FrameLoaderClientQt::createPlugin we
set the QWebView (or any other view) as parent of the QWidget and in
WebCore::Widget::setFrameGeometry we simply call QWidget::setGeometry.
The issue is: One has to convert the rect from the frame geometry to the one
of the containing window. Let me see what is breaking when I do this...
z.
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 4 in thread
Hi, Holger,
I've noticed that, in the latest snapshot, the IFrame issue is already
fixed: the qt-plugin progress bar appears to the right of the page, where it
belongs to, inside its IFrame. Nice!
However, there's still an issue with the scrolling: if the Web page is big
enough, such that the scroll bars appear, the qt-plugin object scrolling
dont work well (I'm not talking about pages with IFrames anymore).
For example, if you use the demo browser to open the following simple HTML
page, and resize the browser in such way that the scroll bars appear, you
will notice such behaviour, specially when the plugin object is supposed to
disappear from the current page view due to scrolling:
<html>
<body>
QT progress bar:
<br/>
<object type="application/x-qt-plugin" classid="QProgressBar"
name="progressbar" height=30></object>
<script>
function display(){
if (++document.progressbar.value != 100)
setTimeout("display()", 50)
}
display();
</script>
<br/>
Image:<br/>
<img src="
http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
width="80" height="80"/>
<br/>
Image:<br/>
<img src="
http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
width="80" height="80"/>
<br/>
Image:<br/>
<img src="
http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
width="80" height="80"/>
<br/>
Image:<br/>
<img src="
http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
width="80" height="80"/>
<br/>
Image:<br/>
<img src="
http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
width="80" height="80"/>
<br/>
Image:<br/>
<img src="
http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
width="80" height="80"/>
<br/>
Image:<br/>
<img src="
http://labs.trolltech.com/skins/trolltech_labs/categories/internet.png";
width="80" height="80"/>
</body>
</html>
The other question is: does anyone know why the qt-plugin object does not
appear when we use the print preview and print options? Is it not properly
rendered by those functions?
Cheers,
Beto
On Mon, Apr 7, 2008 at 5:33 PM, Holger Freyther <freyther@xxxxxxx> wrote:
> On Friday 04 April 2008 16:58:47 Beto Boullosa wrote:
>
> > Now, the IFrame inside this page will try to load qtplugin.html to the
> > right side of the page. The image appears fine in the demo browser, in
> the
> > right part of the screen. But the progress bar appears in the left part
> of
> > the screen, that is, outside of its parent IFrame.
> >
> > Anyone could confirm if this also occurs to you?
> >
>
> I can confirm this. The issue is that in FrameLoaderClientQt::createPlugin
> we
> set the QWebView (or any other view) as parent of the QWidget and in
> WebCore::Widget::setFrameGeometry we simply call QWidget::setGeometry.
>
> The issue is: One has to convert the rect from the frame geometry to the
> one
> of the containing window. Let me see what is breaking when I do this...
>
>
> z.
>
>
Message 5 in thread
On Friday 11 April 2008 12:45:10 Beto Boullosa wrote:
> Hi, Holger,
>
> I've noticed that, in the latest snapshot, the IFrame issue is already
> fixed: the qt-plugin progress bar appears to the right of the page, where
> it belongs to, inside its IFrame. Nice!
hehe, we needed two attempts. On the first I got the coordinate transformation
wrong but didn't notice because the scrollbar was put to the right. :)
>
> However, there's still an issue with the scrolling: if the Web page is big
> enough, such that the scroll bars appear, the qt-plugin object scrolling
> dont work well (I'm not talking about pages with IFrames anymore).
>
> For example, if you use the demo browser to open the following simple HTML
> page, and resize the browser in such way that the scroll bars appear, you
> will notice such behaviour, specially when the plugin object is supposed to
> disappear from the current page view due to scrolling.
I'm going to take a look.
>
> The other question is: does anyone know why the qt-plugin object does not
> appear when we use the print preview and print options? Is it not properly
> rendered by those functions?
I think this won't work in Qt 4.0.0. Your widget is not drawn with the
QPrinter used for printing, so it will not show up. For later versions we
will find a solution, e.g. using QWidget::render in WebCore::Widget::paint.
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 6 in thread
>
> > The other question is: does anyone know why the qt-plugin object does
> not
> > appear when we use the print preview and print options? Is it not
> properly
> > rendered by those functions?
>
> I think this won't work in Qt 4.0.0. Your widget is not drawn with the
> QPrinter used for printing, so it will not show up. For later versions we
> will find a solution, e.g. using QWidget::render in
> WebCore::Widget::paint.
>
What if, instead of printing, we try to generate an image file for the page?
I've tested a code like that and the output image doesn't show the
qt-plugins neither.
QSize size = getSize(); // getSize gets current page size
QWebFrame * frame = page()->mainFrame(); // gets a pointer to
current page's main frame
QPixmap screenshot(size);
QPainter painter(&screenshot);
frame->render(&painter, QRect(QPoint(0,0), size));
QString fileOut = new QString("test.png");
screenshot.save(fileOut);
Why does the output image render the whole page, except the qt-plugins? Is
that the same problem as in printing? Could we have a fix for the QT 4.4
final version?
)(s, Beto
Message 7 in thread
On Tuesday 22 April 2008 15:34:23 Beto Boullosa wrote:
> Why does the output image render the whole page, except the qt-plugins? Is
> that the same problem as in printing? Could we have a fix for the QT 4.4
> final version?
Same problem as printing just with a different color. With WebKit we have
something called RenderTree. When doing any kind of painting (printing,
drawing to image, drawing to screen) we go to the root to the RenderTree and
start to paint. The issue is we do not draw Widgets when we are asked to draw
them (WebCore::Widget::paint has no implementation). The QWidget is drawn
from a different paintEvent.
This has at least the following implications:
- Drawing only works for on-screen stuff
- The z-order is wrong
- alpha, transformation (CSS3 for future Qt releases) is not applied.
When we all know this, why don't we just fix it?
- Plugins and the ugly way they are implemented (XEmbed and similar
technologies for the other windowing systems)
What could be done:
- Treat widgets with a native window and window-less widgets differently
- For the window less ones (alien) we can use QWidget::render and things
would just work (like widgets on the graphicsview)
- Looking at the QGraphicsProxyWidget you could change WebCore::Widget to do
the right thing and have printing/rendering to an image working for you.
We will probably look into this for Qt 4.4.x, it is definately on our (Qt
webkit developers) mind.
z.
PS: We could refuse to ever implement the NPAPI (Netscape plugins) and use
Phonon for video, Gnash/SWFDec for flash, moonlight for silverlight, so
basicly only components with source available to make them proper QWidgets.
This idea is rather unrealistic.
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
