Bug 178827 - No good way to assoicate a handler with a MIME type
Summary: No good way to assoicate a handler with a MIME type
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nautilus
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Alexander Larsson
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-01-24 17:34 UTC by Toralf
Modified: 2015-01-08 00:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-09-04 15:56:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Toralf 2006-01-24 17:34:39 UTC
Description of problem:
I'm trying to install an application with the necessary config to ensure that
this application will be opened whenever files of a certain type is
double-clicked under the GNOME desktop.

Unfortunately, how this is done is *completely undocumented* as far as I can
tell. Also, the config that has worked in the past no longer does, i.e.
mentioning the MIME type in /usr/share/application-registry/<name>.applications.
And what I thought may be the new way of doing it, i.e. including

MimeType=<my type>

in /usr/share/applications/<name>.desktop does not seem to help, either.
 

I trying really hard not to star yelling, now. This constant changing of how
things work *without providing compatibility for old-style config* must change
right now. Also, as far as I can tell, no config mechanism has been standardised
by freedesktop.org. Why change from something that works reasonably well to
something else that's nonstandard, when a new standard is right around the corner?

Version-Release number of selected component (if applicable):
2.8.1-4

How reproducible:
Every time

Steps to Reproduce:
You know what I mean

Comment 1 Alexander Larsson 2006-01-25 09:26:08 UTC
You have to set mimetype in the desktop file, and then run
update-desktop-database afterward (i.e. in the rpm post script).


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