[embed] implement editor extension mechanism

NEW
Unassigned

Status

()

P3
critical
18 years ago
4 months ago

People

(Reporter: rubydoo123, Unassigned)

Tracking

(Blocks: 1 bug, {embed, topembed-})

Trunk
Future
embed, topembed-
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [T2])

(Reporter)

Description

18 years ago
task: implement editor extension mechanism
(Reporter)

Updated

18 years ago
Blocks: 34477
Keywords: embed
Priority: -- → P1
Target Milestone: --- → mozilla0.9

Comment 1

18 years ago
Accepting bug.
Status: NEW → ASSIGNED

Comment 2

18 years ago
spam

Comment 3

18 years ago
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?

Comment 4

18 years ago
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.

Comment 5

18 years ago
> > 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.

Comment 6

18 years ago
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.

Comment 7

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

Comment 8

18 years ago
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.

Comment 9

18 years ago
-> 1.0.
Target Milestone: mozilla0.9 → mozilla1.0

Comment 10

17 years ago
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1

Updated

17 years ago
Keywords: topembed

Updated

17 years ago
Keywords: mozilla1.0+
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.
Keywords: topembed → topembed-

Updated

17 years ago
Keywords: mozilla1.0+ → mozilla1.0-

Comment 12

17 years ago
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.

Target Milestone: mozilla1.0.1 → Future

Updated

16 years ago
Blocks: 157128

Comment 13

16 years ago
Corfirming topembed- [T2] per EDT triage.
Whiteboard: [T2]
QA Contact: sujay → editor
Assignee: kinmoz → nobody
Status: ASSIGNED → NEW
old bug.  down to P3
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.