162704 - MIssing desktop integration functions : x-remote and command line

Status: RESOLVED EXPIRED

(Core Graveyard :: X-remote, defect)

Description

[Michael Kolmodin]

Basic desktop integration for HTML files could (possibly) be defined by the
actions View, Edit and Print; these actions should preferably be available in
the context menu for every HTML file in the file mgr. These functions should be
available whether moz is up&running or not - that is, with Uniz/X, both as
command line arguments and -xremote options. Missing items are

command line: no print <url> option. (the 'save as' might be used, I'm not sure,
but a print option would really be nice).

-remote: options for editing a file, printing a file is missing. These existed
in 4.x.

Preferably, run-mozilla.sh should be able to view, edit or print a URI in the
way existing -xremote options are merged into this frightening script
recently;-) Anyway, there is a need to assure that required functions exist as
command line arguments, x-remote options and, I guess, correspåonding windows
functions.

Comment 1

[Michael Kolmodin]

Attachment: Short investigation describing what's available (to my understanding)

Small overview covering moz functionality from a X desktop point of view

Comment 2

[Adrian Ulrich]

> no print <url> option.
Dup of Bug 5702

> Edit
.. as you said -edit is a solution.. but i could not find a remote command for
NS 4.. 

http://wp.netscape.com/newsref/std/x-remote.html
How did this work?

Comment 3

[Michael Kolmodin]

See the attachment. Long time ago I actually made a ksh launcher for Netscape
which in CDE made i possible to view, edit & print a HTML file (+ opening of
mail, address book etc). But *don't* ask where I found this info covering a
superset of the commands in "your" link.

Comment 4

[Andrew Schultz]

some of additional arguments are covered in bug 101169.  stuff like irc, edit
and addressbook would not be hard to implement.  printing is a different story.

Comment 5

[Michael Kolmodin]

A good nights sleep clears the brain a little... As I have described it, we need
all functionality available both at command line (in case moz is not running)
and as xremote arguments in case it's running. An alternative, and propably
better way would be to always use the xremote functions to make moz do various
things. However, what's needed for this is a way to ensure that moz is running
and ready to accept xremote calls. 

So: if there was a short program which

 - returned immediately if moz was up&running
 - else started moz and returned when moz was ready to accept xremote calls

we wouldn't have to use the command line arguments from the desktop. Sounds
better to me, and is more similar to the Windows model as well. The tricky point
is to determine when moz is "ready"; anything else could be done in a script.
One could even "poll" moz until it's up, but this is not really satisfactory.A
command line switch for running an arbitrary system command when moz is up??? 

The need for xremote options is still there, though.

Comment 6

[Andrew Schultz]

The RPM-build startup script does something similar to what you described
originally and bug 122698 would integrate that functionality into run-mozilla.sh

there are various issues with what you have described in comment 5 that would
actually make it more complicated (profile being the biggest one)

Comment 7

[Christopher Blizzard (:blizzard)]

>  - returned immediately if moz was up&running

mozilla -remote 'ping()' will do this.

Comment 8

[simon annear]

Some documentation can be found here

http://www.mozilla.org/unix/remote.html

Comment 9

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 10

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.