Bug 206262 - Can't handle URIs
Summary: Can't handle URIs
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gtorrentviewer (Show other bugs)
(Show other bugs)
Version: 5
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-13 10:49 UTC by Denis Leroy
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-26 21:12:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fixes desktop file exec argument (420 bytes, patch)
2006-09-26 07:56 UTC, Denis Leroy
no flags Details | Diff

Description Denis Leroy 2006-09-13 10:49:26 UTC
gtorrentviewer cannot open a file described by a standard URI such as
"file:///foo.torrent" or "http://xxx".

Unfortunately, the desktop file contains a MimeType entry that registers
gtorrentviewer as a valid recipient for torrent files. So if you try to open a
torrent file from Nautilus with gtorrentviewer, gtorrentviewer can't open it
(Log tab says "no such file or directory"). Same if you execute a torrent link
from a web browser.

2 solutions:

1) write a quick patch to add the URI support. Should be simple, as I believe
Gnome provides all that you need. I can help with the patch too.

2) Remove the MimeType entry from the desktop file, so that gtorrentviewer does
not show up as application when you right-click on a torrent file in Nautilus.

Comment 1 Paul Howarth 2006-09-13 10:53:52 UTC
If you can provide a patch, it would be very useful. I'm not familiar with
programming in Gnome and upstream for this project appears to have gone away.

Comment 2 Denis Leroy 2006-09-26 07:56:12 UTC
Created attachment 137113 [details]
Fixes desktop file exec argument

Actually, the solution is simpler than that. The desktop file should not
specify %U (means: accepts one or more URIs), but rather it should use %f
(accepts a single file argument). I looked at the code and it only supports a
single file as main argument. Drag'n'drop torrent files works correctly, as it
follows a different code path. Patch attached :-)

Comment 3 Paul Howarth 2006-09-26 15:32:30 UTC
Patch is included in 0.2b-11, which should get released soon for FC-4, FC-5, and
devel.

Comment 4 Denis Leroy 2006-09-26 21:12:25 UTC
Fix verified. Thanks!


Note You need to log in before you can comment on or make changes to this bug.