task: implement editor extension mechanism

Accepting bug.

spam

So here's what I think we need for this: 1. Decide what comprises an editor "extension". Something like: * JS file with implementation of one or more nsITransactions. * Properties file (localizable) containing strings for undo and redo actions, and the name of the extension. * Optional XUL/JS files for any UI that the extension needs to put up. Presumably these would be packed in a jar file. The properties file needs to live under the usual locale-specific directry hierarchy. Extensions may be packed with properties files for one or more languages. Should we allow C++ implemenations of transactions? I think an extension package should be allowed to implement any number of transactions (and should provide UI strings for each of them). 2. Choose a specified location for finding user-installed extensions. Probably have a per-profile, and per-installation locations. 3. Create a mechanism for finding and loading available extensions on composer first startup (an extensions service, probably). Extensions may register their transactions(s) at load time, and be given transaction IDs then. Maybe use RDF to build the menu that lists available extension transactions. 4. Hook up calling extensions' transactions to the menu items. Maybe allow the extensions to assign key shortcuts? 5. Hook up undo/redo strings. Thoughts?

I like almost everything in Simon's proposal. > Should we allow C++ implemenations of transactions? I'd say probably not. If there are things that can only be done in C++, then we've made a mistake in our APIs. And I don't expect there will be much demand for C++ extensions; anyone capable of writing a C++ extension is probably capable of submitting a patch to bugzilla and getting the code checked in. > Maybe allow the extensions to assign key shortcuts? That would be lovely, but I expect it'll require a redesign of the xbl keybinding mechanism, since right now it relies on a couple of hardcoded filenames and doesn't allow any further additions. See bug 18508.

> > Should we allow C++ implemenations of transactions? > > I'd say probably not. If there are things that can only be done in C++, then > we've made a mistake in our APIs. And I don't expect there will be much demand > for C++ extensions; anyone capable of writing a C++ extension is probably > capable of submitting a patch to bugzilla and getting the code checked in. There are reasons that people might want to implement a transaction in C++ in additoin to simple interface availability. The txn might be very computationally intensive, or even call into OS-specific services (and why not!). So allowing C++ extensions would, it seems to me, open up the possibility for lots of cool extensions which we never even thought of.

I guess you answered your own question, then. :-) I have no objection to C++ extensions, but if they turn out to be more difficult I don't think we should expend a lot of effort to make them work. Or at least, I think we should get JS extensions working first and then worry about native code.

do we need the extension txns to share some commonality other than that already implied by nsITransaction? If so we need an nsIEditorTransaction api.

I believe the answer to Joe's question is yes. We're going to need some sort of interface that will allow composer to query a transaction for some info like the strings it should display in the menus. I want to remove UI methods from the transaction manager interfaces because 1. transactions should be independent from UI and 2. every app wants to get/keep track of UI strings etc differently.

-> 1.0.

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these back in if I can.

topembed- Kin states: You can already extend the editor via JS/C++ transactions. This bug is about writing a mechanism that can recognize a neatly packaged (yet to be determined format) group of files and dynamically add them to Composer's menus etc.

Bulk move of my milestoned bugs to Future in an effort to get my milestone lists to reflect reality. I will be pulling this bug back into a milestone when I can.

Corfirming topembed- [T2] per EDT triage.

old bug. down to P3