67001 - need unix implementation of nsILocalFile::Launch and nsILocalFile::Reveal [Launch File & Reveal Location buttons]

Status: RESOLVED DUPLICATE of bug 391980

(Core :: XPCOM, defect, P3)

Description

[Scott MacGregor]

Spinning this bug off of 63346.

In order for unix to leverage the functionality of the reveal and launch buttons
used in the progress download dialog, we need implementations of reveal and launch.

Reveal needs to launch an appropriate file manager for the windows manager you
are using on unix and have it open up the folder the file points to.

Comment 1

[Scott MacGregor]

adding the help wanted keyword in the hopes that someone wants to contribute
this implementation.

Comment 2

[Jeffrey Baker]

I propose that this is a very un-unixish thing to do.  If the user can't
rememeber where they put a file on unix, they are rather well screwed.

Instead, why don't we expose an X resource that tells Mozilla the best default
location to put downloads.  That way, the X environments can hint Mozilla to
download to ~/Desktop, or ~/Desktop/Downloads, or whatever.

Comment 3

[tenthumbs]

I agree with Jeffrey Baker. Unix is not Windows and works differently. Personally,
I start a browser in a particular directory that is appropriate at the moment. I
certainly don't want to have some other program open just so I can repeat what I
have already done. Furthermore, I don't have any file managers on my system so
this would be a total waste of time.

Forcing Windows behavior on Unix is a crock.

Comment 4

[Matthew T (active 1999-2002)]

It's not `Windows behavior', it's behavior to make Mozilla more usable no 
matter what OS you are on -- Mac OS, Windows, Linux, BeOS, OS/2, whatever. And 
it's not `repeat[ing] what I have already done' -- in the unlikely event that 
you already have the folder open in your file manager or shell of choice, you 
don't need to press the button, do you? It's not as if anyone is forcing you to 
press it, every time you do a download.

Comment 5

[tenthumbs]

> it's behavior to make Mozilla more usable no matter what OS you are
> on ...

So the user's choice of OS is irrelevant? Mozilla decides what is good
and proper? I choose to use Linux because it suits my needs better. If I
wanted a more GUI oriented OS, I would run Windows. I want Mozilla to
act reasonably given my OS not override my preferences because it
doesn't want to.

> in the unlikely event that you already have the folder open in your
> file manager or shell of choice

Why do you assume this is unlikely? I always start from an xterm. I
commonly cd to a directory that contains the data I am interested in, at
the current moment. I then start a browser if I need one. I have already
made the decision on where I want downloaded files to go when I changed
directories. In Unix, the concept "current directory" is very important.
It may not be in Windows but I don't care when I run Linux.

Are you a regular Unix user? If not, then you should use try it as it is
intended to be used before making comments.

Comment 6

[sairuh (rarely reading bugmail)]

cc'ing several unix folx...to see if they might have suggestions.

Comment 7

[Jeffrey Baker]

I agree with tenthumbs.  If you want to fix the usability problems of Mozilla,
make the default download directory in the file picker be the processes current
working directory.  What Mozilla does right now is it tries to download things
to the last place I downloaded something, which is a nuisance.  Mozilla should
default to the current working directory via getcwd(), and if I pick a different
path using the file picker, Mozilla should make that path the current directory
using chdir().

As long as your heart is in Unix usability, the file picker could also be fixed
so that it can normalize paths.  Nothing more stupid than seeing
"/home/jwb/package/../../../usr/local/download" as the current directory in the
Mozilla file picker.

Comment 8

[tenthumbs]

Let me try to explain my position more clearly.

I work on a nunber of different projects. To contain the chaos somewhat,
I have different work areas, i.e. separate directory structures, for
each project. When I work on a particular project I move into its work
area. Inside this area I now have access to the local project tools as
well as the system tools. I consider a browser a system tool because I
use it on multiple projects.

Since the browser is a system tool I expect it to act as other such
tools do; in particular I expect it to respect my current location. What
I most certainly do not want is for the tool to decide that it wants to
use some other location, particularly since I may not remember where
that was.

Right now, Mozilla acts like a project in its own right. It tries to
lead me around. I want a tool that follows me obediently.

Now I am one person. Is there any quantifiable data on what Unix users
want or expect? What I see here is that Mac and Windows users prefer one
thing so Unix users must want the same thing. What I don't see is
proof. I would argue that failing to meet the user community's
expectations is a sure way to kill Mozilla.

Comment 9

[Matthew T (active 1999-2002)]

I agree that synchronizing Mozilla's download directory with the current 
directory using getcwd() and chdir() would be an excellent idea -- but that 
should be the subject of a separate RFE, as it has nothing to do with this bug. 
If you regularly use a command line (as I did for four years on Solaris, and even 
longer on AmigaDOS), that's great -- you'll hardly ever need to use what this bug 
asks for. But that's not a valid reason for arguing that this bug shouldn't be 
implemented for the benefit of the large number of people who would rather use a 
graphical file manager than use an xterm; to actively try to keep such people 
away from Linux (or other Unices) would be churlish in the extreme.

Comment 10

[tenthumbs]

What this bug is about is implementing a decision already made. The buttons
are there in the download dialog but are grayed out. I am objecting here not
only to the implementation but also the design decision. I am objecting here
because this is the first public forum I've seen on this issue. I would be
extremely happy if someone would tell me I just missed the discussion and I
am an idiot.

Now there are outstanding bugs on the current file picker behavior so filing
an RFE seem superfluous. It also seems to me that these bugs are generally
ignored.

I am definitely for lots of configurability. No complex package can make the
user's experience enjoyable and effective without lots of options,
particularly across many OS's. Every successful package I've seen has the
ability to cater to user's wishes, even a minority of the users. So I have
no problems with prefs. The more the better. Other people appear to think
that there is a "one size fits all" solution, that there is, at least
theoretically, a common feature set that all users will like. This seems to
be the current solution. I certainly think Mozilla should not exclude
certain classes of users. I think it should include all classes. This
current scheme excludes the command line people like me.

Finally, having this configuration as a default and the classic Unix scheme
(compatibility with 4.x and every other GUI app I have) as a option will be
an implementation nightmare. There is no One True File Manager. There isn't
even One True Window Manager. This means that the current idea should NOT be
the default. How will Mozilla handle the case where it's default file
manager isn't available or if there is no file manager? Will the download
dialog just have grayed-out buttons? Will the only thing available be
"Cancel?" Will Mozilla handle the error correctly? Current experience says
Mozilla is very poor on error handling.

Since there are many file managers, with differing command line syntax, it
will be necessary to expose the pref that selects the file manager in the
GUI as well as Mozilla's syntax requirements. Those users who don't like
command lines will not be happy. Who's going to write the description of how
to use "%s" or "%f" or whatever. Who's going to maintain all this?

Of course, mozilla.org can just say it only supports certain Linux/Unix
configurations. It can say it just wants to support a particular subset of
Linux/Unix users. Maybe it should.

Comment 11

[Akkana Peck]

An easy quick fix: having a little dialog that popped up just showing the
pathname to which you are downloading/just downloaded a file would be useful
even to diehard Unix command-line folks, and wouldn't require any knowledge of
the myriad of file managers in existence.

As for file managers, although I never use a filemanager myself, I agree with
Matthew that a lot of people like them and many of the new Linux users over the
next few years will probably prefer the filemanager model.  We could handle
filemanagers the same way we do other helper apps: a pref (or piece of rdf data
or however you want to store it; it could even BE one of the helper apps, with
an appropriately chosen moz-specific mime type) which includes the syntax for
invoking the command, and a way for the user to change that to use a different
file manager.

It occurrs to me that the folks at Eazel might be interested in offering
feedback on this, or perhaps even helping with implementation.  They're the
experts on Unix filemanager usability ...  Cc'ing some Eazel people hoping that
one of them knows who the right contact might be.

Comment 12

[Dave]

I think Akkana's idea is a very good one. Letting the user configure what the
"Launch" and "Reveal" buttons do (by means of a helper app or some separate
config tool) would be great. This way Unix users could specify their favorite
file manager or whatever other action they would like to take place.

Another idea that occurred to me is for a dialog to appear which prompts the
user for the app to use with the file. The user could now type 'gmc' and the
browser would then attempt to execute 'gmc <path/file>', notifying the user upon
failure (e.g. if the user types gnc instead of gmc, the error would be something
like "gnc: command not found.")
If nothing is specified, Mozilla tries to execute the file, again, notifying if
this fails. This would be similar to using the Gnome exec feature (which is part
of the gnome panel) or the E exec epplet that I myself use... just a thought.

Comment 13

[timeless]

nc4composer would ask you to select your text and image editor apps the first 
time you tried to use them, this sounds like a good idea. However, ideally you 
get this for free when you treat these as unassociated mime types and the 
browser feels the need to ask the user what application to use.

it should probably be application not found. only shells have internal 
commands, and it is unclear what shell we'd be speaking of ...

Comment 14

[Stuart Ballard]

And for die-hard command line users, you can always set your "helper app" to be
"xterm -c 'cd %s'" - that is, assuming moz gets support for "%s" in helper app
strings.

(I might have got the flag for "execute this and then drop into interactive
mode" on xterm wrong, but you get the idea)

Comment 15

[Christopher Blizzard (:blizzard)]

I think a first good step here would be to code up something that would use a
preference to launch an external program.  It appears that no matter what people
want to use, it will probably be an external program.

Comment 16

[tenthumbs]

Yes, launching external programs is good but this time lets document the 
syntax required for the command line.

Comment 17

[timeless]

s/required/available/

Comment 18

[Nicolás Lichtmaier]

A simple and useful thing that could be done in unix is adding this button:

[Copy file location to clipboard]

Comment 19

[chris]

why doesn't nsILocalFile::Launch just use the helper? 

Comment 20

[Vaclav Dvorak]

(In reply to comment #19)
> why doesn't nsILocalFile::Launch just use the helper?

Yes, exactly, is there any reason it doesn't? Or is it intended to override the
helper settings and just launch the file using the OS? If that's the case, it's
kinda problematic on Unix.
http://www.freedesktop.org/Standards/mime-actions-spec seems to be the place
where the spec for handling this should eventually emerge. Currently, there is
no standard, so the best we could do at this time is something like:
1) Detect KDE and use its configuration if found
2) If that failed, do the same for GNOME
3) If that failed too, use mailcap (or our helper settings, which may mean
falling back to mailcap)

I think implementing KDE- or GNOME-specific things in Mozilla is not the right
thing to do, so until there's a standard for Unix desktops, I'd just use
Mozilla's helper app settings.

Comment 21

[timeless]

thing is, your helper app could be something like |cat|. and mozilla is an x11 app.

what kind of x11 window do you want to hold |cat|? and how precisely do you
expect mozilla to find this x11 windowing application?

some examples: xterm, rxvt, konsole, gnome-terminal, eterm.

Comment 22

[Nils Maier [:nmaier]]

http://mxr.mozilla.org/mozilla1.8/source/xpcom/io/nsILocalFile.idl#143
Honestly, the remarks about supported platforms for |launch| and |reveal| are not quite helpful.
All systems considered *nix are affected.
> 147      *  this really just simulates "double clicking" the file on your platform.
> 148      *  This routine only works on platforms which support this functionality.
My Ubuntu and Kubuntu supports this, but nsILocalFileUnix does not.

I just got a bug report about reveal/launch not working in an extension. Had to find the actual implementation to see what happens. |return NS_ERROR_FAILURE|.

On the other hand I see the built-in FX Download Manager working around this.
Download Statusbar, the extension, copies said work-around.
And now DownThemAll copies it as well.
Looks in my eyes as if there is a working solution, namely passing either the file (launch) or the parent folder (reveal) to the external protocol handler so that the OS should decide what happens with it.
http://mxr.mozilla.org/seamonkey/source/toolkit/mozapps/downloads/content/downloads.js#877 ff

Conclusion
--
Please at least make the comments in the .idl more clear.
I would however prefer if the said work-around became the actual implementation in |nsLocalFileUnix::launch| and/or |::reveal|.
Or all current and future XP extensions that use launch/reveal need to copy that work-around, and I assume most actually will. Seems wrong to me.

Comment 23

[Cedric Vivier [:cedricv]]

I think it would make sense to use xdg-open which is a FreeDesktop standard available on most desktop environments (Gnome, KDE, XFCE...) and is used by other programs for similar feature.

http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html

It will use the default application for the detected mimetype as configured by the desktop environment (a user can also override the desktop environment by using xdg-mime)

Comment 24

[Mike Hommey [:glandium]]

Actually, this was implemented a while ago with bug 391980 and subsequent changes to nsLocalFile::Launch and nsLocalFile::Reveal.

(I don't understand why it's not using the external application handlers, though)