[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