Bug 279423 - Rekonq downloads list does not respect mime type embedding settings
Summary: Rekonq downloads list does not respect mime type embedding settings
Status: RESOLVED FIXED
Alias: None
Product: rekonq
Classification: Unmaintained
Component: general (show other bugs)
Version: latest git snapshot
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Andrea Diamantini
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-05 07:43 UTC by Todd
Modified: 2013-04-11 09:51 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Todd 2011-08-05 07:43:17 UTC
Version:           latest git snapshot (using KDE 4.7.0) 
OS:                Linux

Rekonq has support for kparts, allowing you to view files in an embedded viewer.  However, this isn't always what someone wants.  KDE has a per-mimetype setting to control whether files are opened in an embedded viewer or in their default application.  The downloads list in rekonq, however, does not respect this setting.  It always opens files in an embedded viewer.

Reproducible: Always

Steps to Reproduce:
1. Download a file of a particular mime type in rekonq
2. Close rekonq
3. Go to system settings-> file associations
4. Find the mime type you just downloaded and click on it
5. Click the "embedding" tab
6. Set it to "show file in a separate viewer"
7. Click "Apply"
8. Open rekonq
9. Go to the downloads list
10. Click "open"

Actual Results:  
File opens in the current tab

Expected Results:  
File opens in the default application for that mime type
Comment 1 Harald Sitter 2013-04-11 09:51:45 UTC
Git commit e80327f333e724ae394e582e358181a67fb2ff4d by Harald Sitter.
Committed on 11/04/2013 at 11:51.
Pushed by sitter into branch 'master'.

honor filetype setting WRT embedding

there are 3 distinct states a filetype can have WRT kpart embeding
- 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 as the decision directly relates to whether a kpart is 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.

REVIEW: 109942
Related: bug 240400

M  +71   -1    src/webtab/webpage.cpp

http://commits.kde.org/rekonq/e80327f333e724ae394e582e358181a67fb2ff4d