Closed
Bug 280608
Opened 20 years ago
Closed 20 years ago
I agree: Mozex.mozdev.org should be part of the fabric of mozilla
Categories
(SeaMonkey :: General, enhancement)
SeaMonkey
General
Tracking
(Not tracked)
People
(Reporter: garym, Unassigned)
References
()
Details
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•20 years ago
|
||
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.)
Reporter | ||
Comment 2•20 years ago
|
||
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•20 years ago
|
||
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... ;)
Reporter | ||
Comment 4•20 years ago
|
||
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•20 years ago
|
||
> * 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?
Reporter | ||
Comment 6•20 years ago
|
||
>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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•