[Sched] Editor UI updating should use JS commander nodes

VERIFIED FIXED in M14

Status

()

defect
P3
normal
VERIFIED FIXED
20 years ago
18 years ago

People

(Reporter: sfraser_bugs, Assigned: sfraser_bugs)

Tracking

Trunk
All
Mac System 8.5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

We need to change the way we update the editor UI (editing toolbar, menu items)
to use the new commander mechanism that hyatt, hangas and saari have been working
on.

I guess this is 3-4 person-days of work.
M13
Target Milestone: M13
Blocks: 5563
Blocks: 15138
*** Bug 16513 has been marked as a duplicate of this bug. ***
Summary: [Sched] Editor UI updating should use JS commander nodes → [dogfood] [Sched] Editor UI updating should use JS commander nodes
Whiteboard: [PDT-]
transferred [dogfood] and [pdt-] from dup bug 16513.

simon, I've recently written a controller in C++ for html text controls, see
mozilla/layout/html/content/src/nsEditorController.h,cpp. So I'd be happy to
help you with this if you have any questions.  Also, paul has written a
controller in javascript, see abCommon.js and widgetglue.js.
in fact, maybe we should just factor nsEditorController:  move the core routines
into a controller object in the editor directory that the editor widget uses,
and have a tiny class in layout that embeds one of these as the workhorse for
the html text field controllers (leaving the content/frame specific code in the
tiny layout controller class.)  I think the semantics for when commands are
enable and disabled are identical.  The only difference I really see is that the
editor widget might support more commands than the html text controls, so the
controller for the html text controls would have to override enough of the core
to handle this properly.
*** Bug 21413 has been marked as a duplicate of this bug. ***
I'm not going to be able to get to this before I come back on Jan 10, but here's
what I think needs to happen:
1. The XUL and JS need to be changed to use command nodes, making use of the
   common commands in globalOverlay.xul where possible. This involves renaming
   lots of our menu items, keys etc.
2. After selection changes, and various other editing operations, we need to
   'dirty' the relevant commands, probably by calling methods on the
    nsXULCommandUpdater in C++, for speed.
3. We need to make sure that the editor controller gets called when appropriate
   (may already happen?)
4. The editor controller needs to be taught about all the editing commends for
   which we have UI. We need to use a more efficient scheme than all the nsString
   member variables in there now.
5. We need to write code to get the enable/disable status of said commands; this
   may require input from joe/charlie/buster
Blocks: 22176
*** Bug 15138 has been marked as a duplicate of this bug. ***
Summary: [dogfood] [Sched] Editor UI updating should use JS commander nodes → [Sched] Editor UI updating should use JS commander nodes
Whiteboard: [PDT-]
updating summary fields
Depends on: 21376
Target Milestone: M13 → M14
Well, I'm trying, but this depends on other stuff that isn't done yet (see bug
dependencies). I'll get as much checked in as I can.
Blocks: 26134
Blocks: 8009
The frame work for this is now in place, and is being used by the edit menu 
items. There is still considerable work to rig up all the other menu items. Since 
this bug covers the infrastructure, I'm marking it fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Simon, please verify this one...tbanks!
Verified.
Status: RESOLVED → VERIFIED
No longer blocks: 22176
You need to log in before you can comment on or make changes to this bug.