280608 - I agree: Mozex.mozdev.org should be part of the fabric of mozilla

Status: RESOLVED DUPLICATE of bug 13474

(SeaMonkey :: General, enhancement)

Description

[Gary Lawrence Murphy]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804

Mozex is a fantastic step forward in allowing Mozilla to truly integrate with
the computing environment people already know.  I would like to open this thread
to cast my +1 vote in favour of folding the Mozex functionality into the core --
whether this goes into Mozilla or the Core, I don't know, so I've post it here
and I hope others can shift it to a better spot.

I have outlined my reasons for supporting mozex on my blog page at
http://blog.teledyn.com/node/2232 but basically it is the argument of the Unix
software philosophy of Small Tools, of each application do what it does best,
leaving other tasks to other who excell at those domains.  Mozilla can never be
a complete word-processing or email system, no matter how many add-ons, but it
should be possible to work with the processing systems people already have.

so +1 from me for mozex in the core.


Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a request to roll the Mozex code directly into Mozilla?  Or to provide
the hooks the FAQ author talks about?

If the former, is the code author OK with it?  If the latter, what are the exact
hooks needed?

(In brief, this bug, as filed, is useless -- I can't tell exactly what you want
people to do.)

Comment 2

[Gary Lawrence Murphy]

For my own wish-list, it's the hooks that I'd like to see integrated at a deeper
level.  I'm using mozex now and I don't mind having to install it (I'm
comfortable with that) but the trouble I have is that it's not totally seamless
with mozilla, it still feels like an add-on (which it is).

We know people want the freedom to choose their email client app from the
success of Firebird and Thunderbird, and the growth of alternative transport
handlers like magnet: and icq: show that there is a need to support easy
configuration of external protocol handlers in the core mozilla; even core
mozilla recognized the need to allow the irc: protocol extensions, but I think
the FireFox/email situation also suggests that Mozilla need not try to be all
things to all people, but instead should aspire to being the
window-manager/gate-keeper of the Internet Desktop :)  Whether it is IRC or
Email or even Downloads, I think the same rules apply as for our choice of AVI
or MP3 viewers -- defaults are fine and welcome, but I think Mozilla should
aspire to being an application framework, a means to glue familiar applications
together.

For my own use, yes, I love now being able to finally click on mailto: instead
of having to left-click, save-email, then paste into an emacs buffer -- I'm
amazed every time I click and there it is, a send-mail buffer ready to go -- but
the REAL perk for me is the outsourcing of TEXTAREA edits.  Mozex has
revolutionized my use of textareas.

This may be asking too much, but what I would like to see is the TEXTAREA editor
application subsumed into the Mozilla frame the same way we insert applications
like realplayer or even the Javascript HTMLEdit -- I'd like to retain the
quick-edit simple editor as the default, but have some easy one-stroke key or
mouse select that switches the buffer to my favourite editor, and if that can't
be inline in the mozilla frame, then external like mozex will do, but it should
be fast and easy to get in, and fast and easy to get out.

With the current mozex. I must reach for the mouse and right-click (no hotkey),
then select mozex, then select text-area; I'd hope this could be simplified to
pressing shift-something while the text-area has focus.  Similarly, when the
external editor returns, I must left-click on the text to see my changes; it
would be nicer if the changes refreshed when the editor returned.

So ... what do you think?  Is any of this possible? :)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Sounds like you want bug 13474.  If not, please clarify, with more brevity and
less essays about why it's desirable exactly _what_ it is that's desirable... ;)

Comment 4

[Gary Lawrence Murphy]

Bug 13474 is exactly what _I_ want, and for the same stated reasons and the same
requested behaviour, but _this_ ticket is also asking for additional external
filter/processes; TEXTEDIT behaviour is the same, but this ticket's
mozex-specification also requests external application call-outs to be
optionally applied to

* mailto: links -- clicking a mailto: calls the configured application with the
To and Subject from the mailto: URL

* downloads -- substituting any external application for shift-click or explicit
downloads.

* protocol: links -- any arbitrary string used as the protocol in a URL is
mapped to any arbitrary protocol handler application, passing the complete URL
as the only parameter.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> * mailto: links -- clicking a mailto: calls the configured application with the
> To and Subject from the mailto: URL

This is effectively the same as protocol: links, and can already be done.

>* protocol: links -- any arbitrary string used as the protocol in a URL is
> mapped to any arbitrary protocol handler application, passing the complete URL
> as the only parameter.

This can already be done, either via setting said protocol handler application
in the OS or, on Unix and OS/2 setting it in preferences (no UI, but the back
end is quite nicely there).

> * downloads -- substituting any external application for shift-click or
> explicit downloads.

The problem with explicit downloads is that we'd need to terminate the HTTP
connection and ask the external application to do the download.  That's not
really feasible with downloads that result from form submissions (think POST
data), for example.

The shift-click thing needs no core hooks; it's purely a UI issue.  Depending on
how the UI is set up (and I don't know how that is, exactly), it could be pretty
trivial for a small JS-only extension to change what shift-click does.

So again, what exact hooks do you want in the Gecko core?

Comment 6

[Gary Lawrence Murphy]

>This can already be done, either via setting said protocol handler application
>in the OS or, on Unix and OS/2 setting it in preferences (no UI, but the back
>end is quite nicely there).

I didn't know this.  If the GUI/config issues to set it all up are already in
the works and the external downloading done like mozex isn't possible, then this
leaves this bug as just a duplicate of Bug 13474, and, apart from that textarea
feature, leaves me a totally happy puppy.

Thanks.

*** This bug has been marked as a duplicate of 13474 ***