Closed Bug 67001 Opened 24 years ago Closed 14 years ago

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

Categories

(Core :: XPCOM, defect, P3)

x86
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 391980
Future

People

(Reporter: mscott, Unassigned)

References

Details

(Keywords: helpwanted, platform-parity, Whiteboard: se-radar)

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.
adding the help wanted keyword in the hopes that someone wants to contribute this implementation.
Keywords: helpwanted
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.
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.
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.
> 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.
cc'ing several unix folx...to see if they might have suggestions.
Keywords: pp
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.
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.
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.
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.
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.
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.
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 ...
Summary: need unix implementation of nsILocalFile::Launch and nsILocalFile::Reveal → need unix implementation of nsILocalFile::Launch and nsILocalFile::Reveal [Launch File & Reveal Location buttons]
Depends on: 90008
Whiteboard: se-radar
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)
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.
Yes, launching external programs is good but this time lets document the syntax required for the command line.
s/required/available/
A simple and useful thing that could be done in unix is adding this button: [Copy file location to clipboard]
why doesn't nsILocalFile::Launch just use the helper?
(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.
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.
Product: Core → Mozilla Application Suite
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.
Blocks: 381697
Component: XP Apps: GUI Features → UI Design
Assignee: mscott → jag
QA Contact: bugzilla
Assignee: jag → nobody
Component: UI Design → XPCOM
Product: SeaMonkey → Core
QA Contact: xpcom
Priority: -- → P3
Target Milestone: --- → Future
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)
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)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.