Closed Bug 51447 Opened 23 years ago Closed 23 years ago

Help menu needs to support submenus

Categories

(SeaMonkey :: Help Documentation, defect, P2)

Product:
SeaMonkey
Component:
Help Documentation
Platform:
PowerPC
Mac System 8.0
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED INVALID
Milestone:
Future

People

(Reporter: oeschger, Assigned: mikepinkerton)

Details

(Whiteboard: [nsbeta3-]) 

[MOVED FROM BUGSCAPE:]
The Help menu does not currently support submenus, but it needs to if we are to 
get the Help chrome and the submenu of help topics implemented in NS6.
What do you mean it doesn't support submenus?
It'd be better for mike pinkerton to explain, but apparently Mac menus don't 
support submenus unless they are explicitly made to do so. May be an 
optimization thing? Nobody knew we'd need submenus in the Help menu, and now we 
need them.
Several other menus have submenus, why does Mike have to do anything specific
for this particular menu?  Is the Help menu that special on Mac?
yes, the help menu is special. we have to build it differently than the others.

okay, nominating for nsbeta3
Keywords: nsbeta3
nsbeta3-/future. We have too many other things that are more important, this is
not worth the time/risk at this point. Can workaround by moving those few menu
items to their own section on the top-level menu.
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
Peter, special work would most definitely be needed to move these items to the 
top-level menu. For instance, we'd have to change the names of all the submenu 
items. We'd have to have a different menu for the Mac. And it's not a "few 
items" -- the main menu currently has seven items; moving the six submenu items 
to the main menu would nearly double the size of the menu.

If we're going to work at this, why not put the time toward the correct 
solution?

Renominating for nsbeta3. Please let me come and talk to you all about this 
before you minus it again.
Whiteboard: [nsbeta3-]
Note: this proposed work around might also cause work for the installer team to
have OS specific menus, and would definitely cause more work for the docs team
who are not programmers but still doing the XUL work to create new menus.

Choice one: fix this bug.
Choice two: do work around.

Both choices cause more work for different teams, both teams currently hosed.
Please get together and decide which path is easiest to implement.
nsbeta3+, P3 for M18
Whiteboard: [nsbeta3+]
Target Milestone: Future → M18
Hallelujia! I can breathe again. Thank you.
ok, i looked at the mac menu code for the help menu and i don't see anything 
wrong (i assumed earlier, like an ass, that we weren't handling hierarchicals, 
but it appears we are). *shrug* this will take some more investigation.

Also, i cannot get a commercial debug build on mac, so I cannot make any progress 
on this bug until I can.

ok, saari and I know what the problem is. basically, the menu manager wants to be 
smarter than us, and it handles the processing of the help menu w/out giving us 
any crack at what is going on. as a result, we will never be able to make the 
help menu dynamic. 

I'll rewrite the helpmenu stuff to make it static when the window appears, but 
just be aware for the future: no wacky rdf data source with data changing based 
on the phase of the moon, and the onCreate() handler will only be called _once_, 
when the window appears.

Wait...you mean you're taking out the RDF and putting a static version of the 
Help menu in place?? I made a template becaus we need to have the Help menu 
localizable. Maybe I misunderstand.
you misunderstand. the rdf will get run through, but only once. if it changes, 
we'll never notice.

should be about a full day of work
Whiteboard: [nsbeta3+] → [nsbeta3+] est 1 full day
Status: NEW → ASSIGNED
Upgrading to P2, but only to keep Verah breathing, and on the off-chance that 
PDT considers Help support to be high profile functionality.  I still think 
that it would be easier and safer to rearrange the menu items to be elsewhere, 
or to have one menu item that links to a page where the other category links 
are.
Priority: P3 → P2
Someone besides me will have to be the judge of what is safer. But I assure you, 
changing to a different help menu strategy at this point is not easier. 
Houston, we've got a problem...

I got the help menu showing its submenus, but the OS is not cooperating. It 
refuses to correctly process when the items in the submenus are selected, 
basically making them useless. saari and I will take a look at this more 
tomorrow, but we're not expecting any miracles. 

We may just not be allowed to have submenus in the help menu. 
Leger considered "Help support to be high profile functionality," even dogfood
(as some Help bugs attest). Why wouldn't it be?

Ian, can you please comment on the feasibility of opening up a Sidebar-less
window that has links to the other content. Thanks.


I'd agree that the help menu is high profile functionality and that this should
be left as P2.

update: saari is pinging people at apple, i'm going to post to npm.mac. we're out 
of ideas, it's not looking good.

We are discussing alternatives via email, and are zeroing in on something we 
"like" (sort of).
It's too late to implement new features.  Please open another bug to implement
an alternative fix.  pdtp5.
Priority: P2 → P5
Whiteboard: [nsbeta3+] est 1 full day → [nsbeta3+][pdtp5]
Target Milestone: M18 → Future
For the record, this is not a new feature. The Help menu specification for 
the commercial version has included a submenu pratically since the beginning of 
the project. The submenu didn't work on Mac OS for PR2, but the decision was to 
overlook that, er, small flaw. Now we know why it didn't work.
Returning to P2 until this gets resolved.  The reason we said this was a new
feature is that it hasn't been implemented yet regardless of how long we've been
mumbling about implementing it.
Priority: P5 → P2
clearing pdtp5 until this gets resolved (which I hope is what SElmer intended).
This report is about the bug in submenu support, not the help menu feature,
which presumably has its own bug report.
Whiteboard: [nsbeta3+][pdtp5] → [nsbeta3+]
Target Milestone: Future → M18
Vera, if your Help menu has submenus, then it's too complicated for its own good. 
Nested menus are hard to use at the best of times, let alone for users who are 
looking for help.

That's not to detract from the worthiness of fixing this bug for XPToolkit in 
general, but for a Web browser in particular an alternative design would probably 
be better in the long run.

PDT marking nsbeta3-, PFT futuring
Whiteboard: [nsbeta3+] → [nsbeta3-]
Target Milestone: M18 → Future
spam: mass-moving currently open help bugs to Terri, who now does qa on 'em. :)
QA Contact: paw → tpreston
As far as I know, the Help menu does _not_ need to support submenus anymore. We are using the help viewer to display the various sets of content, so the whole, one-submenuitem-per-set plan is out. Marking INVALID
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Verified invalid
Status: RESOLVED → VERIFIED
Hardware: PC → Macintosh
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.