504123 - support command line flags for external viewer (frontend TB work)

Status: NEW

(Thunderbird :: General, enhancement)

Description

[Harald Dunkel]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1) Gecko/20090630 Firefox/3.5
Build Identifier: version 2.0.0.22 (20090623)

It would be very nice if Thunderbird could support helper applications like "openoffice -view" or "gmplayer -ao alsa:device=hw=0.1,". This could help to avoid defining and deploying billions of trivial wrapper scripts.

Reproducible: Always

Comment 1

[rsx11m]

This would depend on Core bug 57420 (yes, it's really nine years old) but also on bug 503303 to allow the manual addition of such command line arguments to an application definition with the recent changes of that preference pane.

Not duping this as it may need more than just the Core support. I'd suggest to confirm the bug here dependent to the other two, but wait for a 2nd opinion.

Comment 2

[Harald Dunkel]

It should be sufficient to write "ooffice -view" in the "open with" dialog. No reason to create yet another dialog for the command line args. Keep it simple.

Maybe I am wrong, but wasn't something like this in the very first Netscape versions?

Comment 3

[rsx11m]

If I'm not mistaken, Netscape 4.x mainly used and manipulated the operating system tables directly rather than by a user file. Now we have for each profile a mimeTypes.rdf, which apparently lacks the capability of handling arguments.

> It should be sufficient to write "ooffice -view" in the "open with" dialog. No
> reason to create yet another dialog for the command line args. Keep it simple.

That 2.0 dialog is gone in 3.0 though, now it's only possible to browse for an application rather than directly entering a path. Since these dialogs are to a certain extent specific to FF/TB/SM, similar to the preference pane, I'd expect some frontend work being necessary even after bug 57420 lands. Thus confirming the bug here, even if it's just as a placeholder for looking into what's needed for Thunderbird specifically after the backend supports command arguments.

Comment 4

[Harald Dunkel]

Do you think it would be possible to go "back" to the 2.0 dialog? I would assume that detecting a file type and binding a file type to a viewer application plus arguments should be kept separate.

Sorry to say, but asking the user to browse for the application path is not very user friendly. Why does he or she have to know about /usr/local/bin or /opt/openoffice.org_3.1.1/bin? $PATH is set, so Thunderbird should be able to search for "ooffice" on its own. On the next host the path might be different, anyway.

Comment 5

[rsx11m]

I couldn't find the bug introducing the new dialog, but it likely came from respective developments in the Firefox File Handling. Much of the Core code is shared, thus the options are to either use the same base or to reimplement the functionality specifically for an application. The Helper Applications dialog is another example of a piece of code "inherited" from Firefox development, hence the follow-up bugs there (bug 501163 and bug 503303) to make that dialog work for mail/news applications. Thus, I doubt that the 2.0 dialog will (can) come back, but whatever TB adaptions are necessary should be taken care of.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #4)
> 
> Sorry to say, but asking the user to browse for the application path is not
> very user friendly. Why does he or she have to know about /usr/local/bin or
> /opt/openoffice.org_3.1.1/bin? $PATH is set, so Thunderbird should be able to
> search for "ooffice" on its own. On the next host the path might be different,
> anyway.

Bug 57420 is actually blocked by bug 400852, which suggests popping up the application picker rather than the file picker, so it would solve the bad UX problem, though I suspect it's still likely to use an absolute path.