Closed Bug 51447 Opened 24 years ago Closed 24 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: 24 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.