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

[Commit Hook]

-----------------------------------------------------------
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.)


Status
------

This change has been marked as submitted.


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/f7ff6e79/attachment.html>