[rekonq] Review Request 109942: only use a kpart for downloads when it makes sense to

[Andrea Diamantini]

> On April 10, 2013, 10:38 p.m., Andrea Diamantini wrote:
> > Ship It!
> 
> Andrea Diamantini wrote:
>     This is really nice, thanks :)
>     I'm just wondering about a possible "global" location for this shared code. This and some other shared one.
> 
> Harald Sitter wrote:
>     Best be brought up on the kde-frameworks-devel list. Usually I'd say a new library kwebbrowser, but at least the filetype snippet could be done in a generic fashion (I actually was surprised that there was no KMimeType::shouldEmbed()), so I believe for this particular case kmimetype may actually be best (or a related class to kmimetype in kdecore).

uhm... if I remember it well, kmimetype is one of the KDE5 deprecated k-classes... :(


- Andrea


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109942/#review30879
-----------------------------------------------------------


On April 11, 2013, 9:51 a.m., Harald Sitter wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109942/
> -----------------------------------------------------------
> 
> (Updated April 11, 2013, 9:51 a.m.)
> 
> 
> Review request for rekonq.
> 
> 
> Description
> -------
> 
>     honor filetyperc setting WRT embedding
>     
>     there are 3 distinct states a filetype can have WRT kpart embedding
>     - always embed
>     - never embed
>     - do whatever the parent node does (e.g. application/foo would take the
>       setting of application)
>     
>     since the logic to determine which of those it is going to be we are using
>     a bit of code imported from konqueror deciding in a boolean fashion
>     whether or not we are supposed to embed or not. this is particularly non-
>     intrusive to the existing code as the decision directly relates to whether
>     a kpart should be created, if not the file will simply be krun'.
>     
>     this change is using static functions for the imported code. rationale being
>     that they are in fact static and not having them reflected in the header makes
>     them all the easier to remove should a better solution arise in the future.
> 
>     with that in mind: while the code is copy'n'pastable it seems like a good idea to move this
>     into some shared library in the long term such that konqueror and rekonq (and any other kpart
>     enabled app) can use the same code.
> 
> 
> This addresses bugs 240400 and 279423.
>     /show_bug.cgi?id=240400
>     /show_bug.cgi?id=279423
> 
> 
> Diffs
> -----
> 
>   src/webtab/webpage.cpp 479997e4e6f421c76f31ddec7ede1cc9aaf33edb 
> 
> Diff: http://git.reviewboard.kde.org/r/109942/diff/
> 
> 
> Testing
> -------
> 
> - swaped through aforementioned embed states for .pdf
> - .deb are no longer opened using ark in a kpart
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rekonq/attachments/20130411/aa758cdf/attachment.html>