289243 - Camino should handle .ftploc files.

Status: RESOLVED FIXED

(Camino Graveyard :: Drag & Drop, enhancement)

Description

[Wevah (Nate Weaver)]

Since camino can open ftp:// URLs, it should also be able to handle .ftploc
files (created when an ftp:// URL is dragged to the Finder). These are exactly
the same format as .webloc files aside from the extension and type code, so I'll
make this go.

We might also consider attempting to open .inetloc (generic internet location)
files, but that's probably not as necessary since we don't handle anything that
would fall under that extension (except maybe Gopher, I suppose), so I'll just
make a patch for .ftploc.

Comment 1

[Wevah (Nate Weaver)]

Attachment: Patch to handle ftploc + a little cleanup.

Okay, this will allow Camino to handle .ftploc files everywhere it can already
handle .webloc files. I changed the following things:

- Changed +[MainController urlStringFromWebloc:] to +[MainController
urlStringFromInetloc:] because of it's broader usage.
- Added @"ftploc" to the open dialog's accepted types.
- Added "ftploc" to the accepted extensions, and "ilft" and "LINK" (the type
code for IE's .url files) to the accepted type codes in the two application
"Info.plist"s.

I'm not going to ask for r/sr yet because I'm considering tackling some of
Smokey's comments in bug 188043 as well. Comments desired though, of course.

Comment 2

[Samuel Sidler (old account; do not CC)]

Comment on attachment 179820 [details] [diff] [review]
Patch to handle ftploc + a little cleanup.

Simon, care to look at this for 1.0?

Comment 3

[Samuel Sidler (old account; do not CC)]

For now targeting for 1.1.

Comment 4

[Wevah (Nate Weaver)]

I have to make a new patch if the FSSpec patch gets in, anyway.

Comment 5

[Samuel Sidler (old account; do not CC)]

(In reply to comment #4)
> I have to make a new patch if the FSSpec patch gets in, anyway.
> 

And it's in. Can you whip up another patch?

Comment 6

[Wevah (Nate Weaver)]

Attachment: Handle .ftploc files; no HFS file type checking.

Comment 7

[Wevah (Nate Weaver)]

Attachment: .ftploc handling, with HFS file type checking/compatibility.

This patch is the same as the former, but also checks files' HFS type codes for 'ilht', 'ilft', and 'LINK' to hopefully fix bug 188043.

Comment 8

[Wevah (Nate Weaver)]

Attachment: No HFS-code patch with fixed variable name.

Comment 9

[Wevah (Nate Weaver)]

Attachment: HFS-code checking version with fixed variable name.

Oops; I forgot to fix a variable name.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 218901 [details] [diff] [review]
HFS-code checking version with fixed variable name.

This works great for all manners of drag-drop for the problematic weblocs in bug 188043, but it strips the protocol and server from *all* weblocs/ftplocs when using the Open File dialogue.

Comment 11

[Wevah (Nate Weaver)]

Yeah, I think I've found the issue there; will post a new patch on the morrow. (Opening .weblocs via the open panel is broken in 1.0 too, at least for me.)

Comment 12

[Wevah (Nate Weaver)]

Attachment: Version 3; with type codes and .js/.css added to the open filter/Info.plists.

This fixes the broken path stuff, and adds .css/.js to the open filter and Info.plists as well (per Smokey's request).

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 219071 [details] [diff] [review]
Version 3; with type codes and .js/.css added to the open filter/Info.plists.

I tested this version with my problematic weblocs from  bug 188043, as well as with other weblocs and ftplocs, and they now all work properly via drag-drop and Open File dialogue.  FWIW, r=me

Comment 14

[Chris Lawson (gone)]

Comment on attachment 219071 [details] [diff] [review]
Version 3; with type codes and .js/.css added to the open filter/Info.plists.

r=me, for whatever that's worth.

Comment 15

[Mark Mentovai]

Comment on attachment 219071 [details] [diff] [review]
Version 3; with type codes and .js/.css added to the open filter/Info.plists.

Do we really want .js and .css?

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 219071 [details] [diff] [review]
Version 3; with type codes and .js/.css added to the open filter/Info.plists.

(In reply to comment #15)
> (From update of attachment 219071 [details] [diff] [review] [edit])
> Do we really want .js and .css?
> 

The Fox has them already, we can read them, and having them makes life easier on folks who do web dev in Camino.

I've not heard an equally- or more-compelling argument for not including them, "so why not" given the advantages, simplicity, and apparent lack of cost :)

Comment 17

[Mark Mentovai]

Comment on attachment 219071 [details] [diff] [review]
Version 3; with type codes and .js/.css added to the open filter/Info.plists.

Time to exercise the line-item veto.  sr+ on this patch less the js and css change, and we can open a new bug to argue about that behavior.

Comment 18

[Håkan Waara]

Checked in on trunk and branch, with the css/js thing removed.

Wevah, wanna just double-check bonsai that I got it all right? Thanks.