[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Review Request: Fix the inability to put an ioslave on hold when
From: "Dawit Alemayehu" <adawit () kde ! org>
Date: 2011-01-03 3:49:54
Message-ID: 20110103034954.17218.19319 () vidsolbach ! de
[Download RAW message or body]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6183/
-----------------------------------------------------------
(Updated 2011-01-03 03:49:54.352914)
Review request for kdelibs and Andrea Diamantini.
Changes
-------
Updated the previous version of the patch as follows:
- Handle the case where downloadResponse is called because of a content-dis=
position header for a text/html content. Note the fix for this case is real=
ly a hack based on what Konqueror does in its KonqMainWindow class. I just =
do not see any better way to handle this better at this point unless, I imp=
lement my own dialog to prompt the user for the desired action take on unsu=
pported content.
- Remove the ioslave on hold if the application selected to open the conten=
t in downloadResponse is a non-KDE application.
- Avoid unnecessary copying when setting the kio meta-data in KIO::AccessMa=
nager.
Summary
-------
The attached patch fixes a long standing issue in the KIO-QNAM class where =
actions that require putting an ioslave on hold currently do not work. In k=
dewebkit, which uses this integration class, such actions always occur when=
you click on a link that cannot be directly handled by the browsing engine=
. For example, clicking on a link that points to a PDF link. Even worse is =
when the link you click on results in an http POST which returns content. I=
n such cases, apps that rely on kdewebkit and hence the KIO-QNAM bridge cla=
ss have no way of putting an ioslave on hold as stated in KIO::get's docume=
ntation in order to properly deal with content types they do not support.
The attached patch along with another pending against kio_http, http://revi=
ewboard.kde.org/r/6182/, remedies this issue by adding a means to put repli=
es on hold and fixing the downloadResponse slot in KWebPage to do the right=
thing.
Diffs (updated)
-----
trunk/KDE/kdelibs/kdewebkit/ISSUES 1211077 =
trunk/KDE/kdelibs/kdewebkit/kwebpage.h 1211077 =
trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp 1211077 =
trunk/KDE/kdelibs/kio/kio/accessmanager.h 1211077 =
trunk/KDE/kdelibs/kio/kio/accessmanager.cpp 1211077 =
trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.h 1211077 =
trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.cpp 1211077 =
Diff: http://svn.reviewboard.kde.org/r/6183/diff
Testing
-------
Thanks,
Dawit
[Attachment #3 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://svn.reviewboard.kde.org/r/6183/">http://svn.reviewboard.kde.org/r/6183/</a>
</td>
</tr>
</table>
<br />
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://svn.reviewboard.kde.orgrb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for kdelibs and Andrea Diamantini.</div>
<div>By Dawit Alemayehu.</div>
<p style="color: grey;"><i>Updated 2011-01-03 03:49:54.352914</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Changes</h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Updated the previous version of the patch as follows:
- Handle the case where downloadResponse is called because of a content-disposition \
header for a text/html content. Note the fix for this case is really a hack based on \
what Konqueror does in its KonqMainWindow class. I just do not see any better way to \
handle this better at this point unless, I implement my own dialog to prompt the user \
for the desired action take on unsupported content.
- Remove the ioslave on hold if the application selected to open the content in \
downloadResponse is a non-KDE application.
- Avoid unnecessary copying when setting the kio meta-data in \
KIO::AccessManager.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">The attached patch fixes a long standing issue in the KIO-QNAM class \
where actions that require putting an ioslave on hold currently do not work. In \
kdewebkit, which uses this integration class, such actions always occur when you \
click on a link that cannot be directly handled by the browsing engine. For example, \
clicking on a link that points to a PDF link. Even worse is when the link you click \
on results in an http POST which returns content. In such cases, apps that rely on \
kdewebkit and hence the KIO-QNAM bridge class have no way of putting an ioslave on \
hold as stated in KIO::get's documentation in order to properly deal with content \
types they do not support.
The attached patch along with another pending against kio_http, \
http://reviewboard.kde.org/r/6182/, remedies this issue by adding a means to put \
replies on hold and fixing the downloadResponse slot in KWebPage to do the right \
thing.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> \
(updated)</h1> <ul style="margin-left: 3em; padding-left: 0;">
<li>trunk/KDE/kdelibs/kdewebkit/ISSUES <span style="color: \
grey">(1211077)</span></li>
<li>trunk/KDE/kdelibs/kdewebkit/kwebpage.h <span style="color: \
grey">(1211077)</span></li>
<li>trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp <span style="color: \
grey">(1211077)</span></li>
<li>trunk/KDE/kdelibs/kio/kio/accessmanager.h <span style="color: \
grey">(1211077)</span></li>
<li>trunk/KDE/kdelibs/kio/kio/accessmanager.cpp <span style="color: \
grey">(1211077)</span></li>
<li>trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.h <span style="color: \
grey">(1211077)</span></li>
<li>trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.cpp <span style="color: \
grey">(1211077)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/6183/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic