Bugzilla – Full Text Bug Listing
| Summary: | NPE in CocoaUIHandler | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Thomas Schindl <tom.schindl> | ||||||
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | bokowski, bsd | ||||||
| Version: | 0.9 | ||||||||
| Target Milestone: | 4.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Thomas Schindl
Created attachment 175302 [details]
patch
This patch at least removes the NPE - A better fix for the future would probably be to disable the CMD+Q on windows who are not defining it or searching in the other windows
You've attached a patch for a different issue. Created attachment 175308 [details]
patch
the correct one
Could we avoid fixing this for 4.0 by telling users to not include the fragment if they don't have a main menu? Sure. It is not an issue in the SDK because there all windows have a menu or are childs the main window so it's not causing troubles there. We should think about a better fix to disable the Quit-Action probably if a main-window has not menu. Sorry Tom, I missed this bug. Good catch. (In reply to comment #5) > We should think about a better fix to disable the Quit-Action probably if a > main-window has not menu. I don't think we want to disable Quit if there's no corresponding menu item found though (meaning that Cmd-Q is ignored). Though (separately) it would be good to make the pill conditional on the existence of the toggle-toolbar command. I suppose we could make the hooking of each app-menu entry conditional on the existence of the corresponding command. It's pretty unlikely that an app will create a command after the window has been created, right? I'm actually wondering if we shouldn't rototill this code slightly anyways: the current flow follows the 3.x CocoahUIEnhancer which checks for actions; but as we're now command-focussed, we can change things up. Currently on About/Preferences/Quit, we search through the menu items to find a menu item that either (1) has an elementId with the corresponding Eclipse IWorkbenchCommandConstants for about/preferences/quit or (2) is a HandledMenuItem with a command for the corresponding Eclipse IWorkbenchCommandConstants for about/preferences/quit. We should instead just use the handler service to look for a handler for the appropriate command (and search from the active child). If none is found, and there is a menu, then search the menus for a menu item with a matching elementId. Does that make sense? (In reply to comment #6) >> I'm actually wondering if we shouldn't rototill this code slightly anyways: the > current flow follows the 3.x CocoahUIEnhancer which checks for actions; but as > we're now command-focussed, we can change things up. Currently on > About/Preferences/Quit, we search through the menu items to find a menu item > that either (1) has an elementId with the corresponding Eclipse > IWorkbenchCommandConstants for about/preferences/quit or (2) is a > HandledMenuItem with a command for the corresponding Eclipse > IWorkbenchCommandConstants for about/preferences/quit. We should instead just > use the handler service to look for a handler for the appropriate command (and > search from the active child). If none is found, and there is a menu, then > search the menus for a menu item with a matching elementId. It would be better to simply delegate (through the command) to the handler. This will work for about and quit. I'm less sure about preferences. In 3.x the dialog popped up by the preferences command is sometimes a view preference dialog (if the Problems view is active, for example). I'm not sure what to do about that. PW |