Bugzilla – Full Text Bug Listing
| Summary: | Please add org.eclipse.ui as x-friends of SWT plugins ... | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Prakash Rangaraj <prakash> | ||||
| Component: | SWT | Assignee: | Silenio Quarti <Silenio_Quarti> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Scott Kovatch <skovatch> | ||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | eclipse.felipe, remy.suen, Silenio_Quarti, skovatch | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | 3.7 M5 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Silenio, this up to you. Will CocoaUIEnhancer always be there ? aren't we working to replace it ? (In reply to comment #1) > Silenio, this up to you. > > Will CocoaUIEnhancer always be there ? aren't we working to replace it ? CocoaUIEnhancer is needed to support many Mac related stuff (like associating the About/Preferences menu, toggle toolbar button etc) I don't remember any plans to replace it. Scott has some outstanding work in this area. I am not sure it would completely replace the CocoaUIEnhancer. Depending on that and the code actually be finished for 3.7, this change is not necessary. Is there a bug with your work in progress to link to this one? (In reply to comment #3) > Scott has some outstanding work in this area. I am not sure it would completely > replace the CocoaUIEnhancer. Depending on that and the code actually be > finished for 3.7, this change is not necessary. Apart for the CocoaUIEnhancer, there are other classes such as the CocoaTitlePathUpdater(1) & MinimizeWindowHandler(2), directly uses the NS* classes. So even if the CocoaUIEnhancer is removed completely, these classes will show up the warnings. (1) http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ui.cocoa/src/org/eclipse/ui/internal/cocoa/CocoaTitlePathUpdater.java?view=markup (2)http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ui.cocoa/src/org/eclipse/ui/internal/cocoa/MinimizeWindowHandler.java?view=markup (In reply to comment #3) > Scott has some outstanding work in this area. I am not sure it would completely > replace the CocoaUIEnhancer. Depending on that and the code actually be > finished for 3.7, this change is not necessary. What work were you thinking of? Display.getAppMenuItem? I don't recall anything else in this area. Yes, Display.getAppMenuItem() (or equivalent). I see that even if we add that API, the CocoaUIEnhancer will still have to acess internal methods. Prakash, I applyed the patch in my workspace, but I still see all the warnings in the org.eclipse.ui.cocoa project. Am I missing something? > Prakash, I applyed the patch in my workspace, but I still see all the warnings > in the org.eclipse.ui.cocoa project. Am I missing something? This seems to be working for me. Did a rebuild help? Can anyone in the CC try this patch and tell us?(In reply to comment #6) (In reply to comment #7) > Can anyone in the CC try this patch and tell us?(In reply to comment #6) Yes, this patch is working for me on 3.7. All of the warnings in org.eclipse.ui.cocoa go away after an auto-rebuild. With the work on 329456 hopefully we won't need this, but I suspect some of it will hang around (toolbar notification, for example.) (In reply to comment #8) > With the work on 329456 hopefully we won't need this, but I suspect some of it > will hang around (toolbar notification, for example.) Yes, I'm still unable to bring back the toolbar without any of the cocoa hacks. I may revert back to the old code to make it work. To Silenio to make a final call. The patch works fine for me. Fixed > 20101220. Note that using the internals is still not recommended. |
Created attachment 180223 [details] Possible fix CocoaUIEnhancer is using some internal classes from SWT. This has lot of warnings on the file. It would be nice to have org.eclipse.ui as a x-friend of SWT plugins