Bugzilla – Full Text Bug Listing
| Summary: | [Mac] Application menu hook example needed | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jeff Williams <jeffw> | ||||||
| Component: | UI | Assignee: | Kim Horne <eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | bhunt, eclipse, grant_gayed, ob1.eclipse, pwebster, skovatch, snorthov, win32pro | ||||||
| Version: | 3.5 | ||||||||
| Target Milestone: | 3.5 M4 | ||||||||
| Hardware: | Macintosh | ||||||||
| OS: | Mac OS X | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 239485 | ||||||||
| Attachments: |
|
||||||||
|
Description
Jeff Williams
CarbonUIEnhancer is provided by the UI team. I'll see if I can't whip something together for M1. Without this it's going to be a pain to use Eclipse in Cocoa. > CarbonUIEnhancer is provided by the UI team.
This class should be deleted in the long run and API provided by SWT or in the short run, OS methods added to support this functionality that can be called as non-API.
(In reply to comment #3) > > CarbonUIEnhancer is provided by the UI team. > > This class should be deleted in the long run and API provided by SWT Yay! +1! Great idea Steve :) > or in the short run, OS methods added to support this functionality that can be called as > non-API. > Which is pretty much where we're at now. You might be able to make it easier for us but unless there's real honest to goodness API we're always going to need something like this class (and associated fragment). Even if you give us internal hooks to use, we're still going need to drive those hooks. Some API/helpers you'd need to supply: supply the Preference menu item callback supply the About menu item callback (and the ability to rename the item) supply the Quit menu item callback (and the ability to rename the item) the ability to rename the hide menu item set the application menu name configure the hide/show toolbar window decoration (and it's associated callback) *** Bug 248879 has been marked as a duplicate of this bug. *** *** Bug 252439 has been marked as a duplicate of this bug. *** I'm guessing this won't make it into M1 :-) PW Created attachment 116681 [details]
New implementation for Cocoa app menu/toolbar
How about m4 then? :-) Here's an implementation of the Cocoa equivalent of the Carbon UI fragment. It implements the toolbar toggle button and hooks to the about and preferences UI items.
I was able to load this in a local workspace, but I'm not sure what (if anything) needs to be done to build it into Eclipse.
Oops. You won't be able to build this because I had to add additional selectors to the PI and didn't include them in this patch. It's getting late; I'll try to add another patch Sunday night or Monday. *** Bug 253059 has been marked as a duplicate of this bug. *** *** Bug 253112 has been marked as a duplicate of this bug. *** I just committed the changes to expose the additional NSWindow and NSToolbar calls needed to get this to compile. The above attachment should now compile without complaint. *** Bug 253061 has been marked as a duplicate of this bug. *** (In reply to comment #12) > I just committed the changes to expose the additional NSWindow and NSToolbar > calls needed to get this to compile. The above attachment should now compile > without complaint. > Excellent! This works like a charm! I will get this into our CVS repo. (In reply to comment #12) > I just committed the changes to expose the additional NSWindow and NSToolbar > calls needed to get this to compile. The above attachment should now compile > without complaint. > Did you leave the copyright headers as IBM intentionally? Did you want to change those to Adobe before I commit them? (In reply to comment #15) > Did you leave the copyright headers as IBM intentionally? Did you want to > change those to Adobe before I commit them? That hadn't occurred to me when I wrote the code - thanks for catching that. It's based on the Carbon version, but I came up with the implementation, so Adobe Systems, Inc. should appear in the headers. Created attachment 117128 [details]
Updated project
Corrected dates, added Adobe copyright and IBM riders, removed scripts directory.
I will open a CQ for this code. The code is now in our repo. Scott, you should have write access to the project. I've opened bug 254597 to ensure that it makes its way into our build. I will leave this bug open until the accompanying changes are made to our menu code. Fix in HEAD. WorkbenchActionBuilder now tweaks the quit/pref/about actions in the same way it does on carbon. In the latest nightly build the Window > Preferences menu item is gone, but the Eclipse > Preferences menu item does not work. To confirm, it's expected that bug 254597 will fix this, right? The behavior of the fix is not quite right. In Carbon and Win32 Display.readAndDispatch() will return after the user selects AppMenu->Quit or presses the close box on the ApplicationWindow. In the Cocoa code NSApplicationTerminate() calls OS.objc_msgSend() to reach Display.applicationDelegateProc(). For the case of sel == OS.sel_applicationWillTerminate_ there is no explicit return value after disposing the window, so the routine returns 0 - the equivalent of NSTerminateCancel. In any event OS.objc_msgSend() terminates abruptly (exits?) and there is never a return from Display.readAndDispatch(). The API contract for Display.readAndDispatch() does not mention that it might never return, so I think this is either a bug or the API needs clarification. My application relies on return from Display.readAndDispatch(), with return value false and the display dispose'd(), for detecting post-SWT application cleanup (database server shutdown, etc.) (In reply to comment #23) > The behavior of the fix is not quite right. In Carbon and Win32 > Display.readAndDispatch() will return after the user selects AppMenu->Quit or > presses the close box on the ApplicationWindow. > > In the Cocoa code NSApplicationTerminate() calls OS.objc_msgSend() to reach > Display.applicationDelegateProc(). For the case of sel == > OS.sel_applicationWillTerminate_ there is no explicit return value after > disposing the window, so the routine returns 0 - the equivalent of > NSTerminateCancel. In any event OS.objc_msgSend() terminates abruptly (exits?) > and there is never a return from Display.readAndDispatch(). One of the gotchas of the default Cocoa quit handler is that it calls exit() if the delegate doesn't otherwise block it. AWT applications have a similar problem in that the JVM doesn't get a chance to clean up even if the user implements an AWT-based quit event handler. I think you've found a new bug rather than an issue with this one, as this just involved getting a Cocoa-aware hook into the application menu. If it's a new bug, we should have a new bug report. This one is tracking 'Application menu hook example needed' and that is done (with bugs). (In reply to comment #25) > If it's a new bug, we should have a new bug report. This one is tracking > 'Application menu hook example needed' and that is done (with bugs). I opened a bug 269735: "Display.readAndDispatch() might not return" to campture the problem Jeff found in the comment 23. Changing this bug back to "Fixed" as specified in the comment 21. |