regression->high.

Marking 2.0.0 as part of the whole mime-mess; attaching to that
tracking bug.

I get the 'no installed viewer capabable...' message if I click on
a core file. I don't see why it runs at all for you!

I don't think you need the bug-buddy.mime and bug-buddy.keys files
at all. This information is included in gnome-mime-info.
(Also, you try to use the mc icon, which probably won't be there.)



nautilus_launch_application() just uses application->command as-is,
and passes the filename as the parameter. So it doesn't seem to
support the '%f' thing. Did it support it in GNOME 1.4?
(gnome-vfs.applications doesn't use %f anywhere either.)

We could add bug buddy to gnome-vfs.applications with the command
'bug-buddy --core' and it should work. Though I tried adding a
bug-buddy.applications file and that didn't work.

it works for me because i configured my mime types to use bug-buddy as
the default.

Guys: is 82604 the general case of this, as Brian surmises? Alex, what
is the status here?

Yes, 82604 is a part of this. Probably the worst part of the problem.


I think bug-buddy needs to forget its .keys and .mime files and just
install an .applications file (or add to gnome-vfs.applications).
Using a bug-buddy.applications file did work for me after all.


We could possibly fix nautilus so it substitutes the filenames/uris for
any '%f' in the command string. It is a very useful feature.

Created attachment 8903 [details] [review]
adds an application entry for handling core files

does nautilus 2 need the userlevel things in the .applications file?

other than that, it's ok to commit

So I take it the current fix is only for bug-buddy, and we don't have
a grand solution? Should I be punting from 2.0.0 then? And jody, what
is the situation with 'regular' nautilus mime-type stuff? I still
can't seem to get icons and open-with working... is that gnome-vfs or
is it now all on nautilus's side?

Note; this never worked in nautilus, it's an ancient, ancient
regression from Gnome 1.2 -> Gnome 1.4 + nautilus, and is no where
near a high priority bug. Can we downgrade this bug - fixing it
involves a chunk of work to nautilus, gnome-vfs, and to be useful
everyone that uses gnome-vfs-mime-handlers etc.

gnome-vfs has always ignored the 'open' action, and given the presence
of these % format strings that seems reasonable.

It might get 'fixed' in Gnome 2.2, hardly the world's most useful
feature though :-)

NO, NO, NO - this is not an inconsequential bug, it is the one really 
irritating feature of gnome2. Do we really want the flames we got 
over gnome1.

It is a major useability feature, ie being able to open a file from 
the file manager.

For example I have a gimp format file in my home directory and the 
only way to open it is via either the command line or within gimp.

I cannot see how completely broken mime/file operations can be seen 
as inconsequential

Apologies for the flame, but this I would see as a blocker

Note that outside of bug-buddy, no mime handler uses the 'open'
action.  And bug-buddy is fixed by applying the patch above.

I think thise should be supported in Gnome 2.2 for consistency with
launchers, but this is in no way a 2.0.0 blocker.

Jacob: Since the mime-database is shared with gnome1, we should really
leave the nautilus user-level settings. Applying as-is.

Mike : Why can't you assign a handler for your gimp file ?

I try to assign a handler in mime-types - it accepts it.
Then when I go back into mime-handler nothing has changed.

I know I could probably edit the mime-types file but that is not 
really the point - the average end-user who gnome2 is intended to 
target wont even either think of it or know which file (and could 
hose their installation)

Just does not work.

The reason I see it as a blocker (BTW it is probably unfortunate that 
this bug is acting as the placeholder for mime bugs)

is that in windows, kde or in gmc you can/could select a program to 
open a file, which at present is just not possible in gnome2.

It does get frustrating having to regularly move away from nautilus 
into a shell to open/edit a file - in HP's words it should "just work"

Not being obstructive just feel that at the moment file types are so 
broken that I would feel that it could wreck the environment for the 
average user

Would it be easier to add a open with option as per windows/gmc
(not ideal but would at least make it useable)
 
BTW - out the six bugs left I see this as the only blocker (see my 
post to desktop-devel (http://mail.gnome.org/archives/desktop-devel-
list/2002-June/msg00063.html)

The associated bug as regards menus etc not refreshing is a mild 
irritation in comparison.

On a related issue - has anything been decided on what to do about 
file associations such as mailto: and http: 

Mike : please want me though _how_ you assign the new handler, and _what_ exactly
       you assign.

I've just fixed a few bugs in that steaming pile of excrement so hopefully
things should be improving.

1. Click on file without handler 
2. get dialog saying no programs associated - do I want to go to 
control center etc I click yes
3. Change handler eg: to the gimp for xcf file save/exit
(sometimes I try shifting between view and application)
4. Try to open file again no changes have been made

(this is from memory - not at my box)

What happens here is similar to mike, but not quite. [With this
morning's everything]:
1) right click, select 'open with'
2) get error as mike does
3) put in data, including icon, program to open with. Close it.
4) restart nautilus.<- this shouldn't need to occur, of course :)

Expected behavior [actual behavior]:
a)icon shows [doesn't happen]
b)'open with' menu shows the app I've chosen [doesn't happen]
c)'open with an application' remembers I've set a handler [it does
not-I get the same error message as I got the first time.
Interestingly, and I think differently from Mike, when I select 'yes'
from the menu, I get an editor window where all settings are
rememebered from the last session.]
d) left-click on the icon launches the file with the program [this
_does_ happen. Really weird that this works and a-c don't.]

Interestingly, (a) occurs when the files are anywhere except my desktop.

Just rebuilt my system and tested and I now get the same results as 
Luis - so bizarre I never thought of trying to open as open with was 
blank.

I am wondering if this is related to the vfolders update bug.

This bug is basically "Gnome-vfs mimetype handling suck ass". It seems
to be about the same as we shipped in gnome 1.4.x. I fail to see how
this is a blocker and how we're supposed to fix it in 3 days.

Lets put it this way - if we ship with it broken and kde/windows 
users comment how much this sucks, what can we say?

If this has been a problem since 1.4 (which it has) what has 3 days 
got to do with it?

Also what do you think sites like zdnet,cnet etc ar going to come out 
with

luis : I can not replicate that behaviour.

When I restart nautilus the new icon and action are displayed.

What version (date) of nautilus and gnome-vfs are you running.
Jody:
I tried this morning with gnome-vfs-1.1.17 and nautilus-1.1.19 - noc 
hange in behaviour as above.

AS a side issue the mime editor windows seems borked. The entries 
blink all over the place.

Not at box but I had an error referring to gtktreeview does match 
gtktreeviewmodel on controlling tty

CVS head for gnome-vfs and the control-center.  You need both.
The patches are not in a release as yet.

The treeview error is also patched in CVS.

Moving this to urgent because the remaining changes should go in
/immediately/ post-2.0.0, and adding the relnote keyword.

Jody: is the remainder of this committed yet? Also, is bug 86693 a
duplicate of what remains of this?

*** Bug 86693 has been marked as a duplicate of this bug. ***

Not quite.  We're still rebating the best way to handle this in nautilus.

I would love to see something as easy to use as kde3.
someone involved should definetly check it out.

Just to clarify i was speeking of setting the mime types
in KDE3.

[Search for 'luis spamming' to catch every instance of this email.]
In order to better track Sun's bugs for Sun and Ximian's internal use, I've
added a temporary keyword to some bugs. I apologize for the spam, and for the
use of an additional keyword, but this is the best way for Sun to track 'it's'
bugs without interfering with the community's own triage and bug behavior. If
you have any questions or objections, please drop me a note at louie@ximian.com
or email bugmaster@gnome.org for more open discussion.

Silly question - not at my my box so cant check it, but has anyone 
checked to see if the same behaviour occurs as root

Checked this last night.
I think that some stuff in .gnome gets in the way. after I wiped out 
the mime entries in .gnome, everything worked mainly.

There are 3 patches required
1) patch to file type capplet to support better defaults for files of 
unknown mime type.  (in cvs)

2) patch to nautilus to send the required info to the capplet.  
Written and pending.

3) patch to nautilus to get it to update cached mime types when the 
mime db changes.  I'm just merging a pair of distinct approaches to 
this now.  Should be ready tommorow.

Jody: what's the status here? AFAICT, it all works with latest
gnome-vfs and nautilus. Can we close this bug and file new ones if
there are any remaining niggling details?

Patches 1 & 2 are in CVS (although 2 did not make it in time for 2.0.1)
Patch 3 merges the 2 approaches Dave and I discussed and has been sent to the
maintainers for final review.  I belive that solves the worst of the problems.

Tested with sun beta 2 build 4 package. Error dialog box pops up 
stating that No specific launcher is available for viewing core file.

prabhut, there are at least two things wrong here.  

  1) gnome-vfs sees Solaris sparc core files as MIME type:
application/x-executable-binary.

  2) bug-buddy doesn't exist in the Solaris GNOME 2 beta 2
distribution so there is no bug-buddy keys file.