Bugzilla – Full Text Bug Listing
| Summary: | [10.7] Let Eclipse use the new full-screen support in Lion | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Marcos César de Oliveira <mcesar> | ||||||||||
| Component: | SWT | Assignee: | Silenio Quarti <Silenio_Quarti> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | enhancement | ||||||||||||
| Priority: | P3 | CC: | alex.blewitt, andypiperuk, apschexn, billhigg, bsd, bulrich, caniszczyk, eclipse.felipe, gtg366p, hubert+eclipseorg, jordi.paricio, lichtemo, linyunz, lshanmug, mail, markphip, markus.kell.r, Mike_Wilson, moritz.eysholdt, mschrag, n.a.edgar, peter, pinnamur, pwebster, Silenio_Quarti, steeg, torkildr, yozh | ||||||||||
| Version: | 3.7 | ||||||||||||
| Target Milestone: | 3.8 M7 | ||||||||||||
| Hardware: | Macintosh | ||||||||||||
| OS: | Mac OS X | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 376155 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Marcos César de Oliveira
I concur. I really love the way the Lion full-screen mode gives you the option to let you give your full attention to a single application at a time, but easily switch between apps using multi-touch gestures. Having this enabled in Eclipse would really be excellent for doing focused development work. How does this feature works ? (sorry I don't have a Lion around) Is it activate by shortcut/menu action/global shortcut ? Does the app needs to do something special to enable this feature ? I would expect the feature to exist in the window manager and to work for all applications. The way you described it seems that it works for some apps but not for others (e.g. Eclipse). Yes, it's a per-application feature. I don't have a apple developer membership that allows me to access the documentation of this, but after a google search, I found an article talking about the news in Lion. This is the relevant part: "Full-Screen Application Enhancements Mac OS X v10.7 includes support for full-screen mode through methods in the NSApplication and NSWindow classes, and the NSWindowDelegate Protocol protocol. Full-screen support is off by default, but an application can turn it on with a simple method call. Turning on the support adds an Enter Full Screen menu item with associated action methods to the View menu if it exists. Otherwise, it adds it to the Window menu. There is also a new full-screen presentation option. NSWindow full-screen support includes a window style mask and notifications upon entering and exiting full-screen mode. It also provides programming interfaces for implementing custom animations that are shown when an application enters and exits full-screen mode. The NSWindowDelegate protocol allows the window delegate to control the full-screen content size and to provide a custom set of presentation options to be in effect while its window is the primary full-screen window. For more information, see Application Kit Framework Reference" I see, thank you. This is definitely something we want to have in SWT. Mcq, do you know if anyone has Lion installed ? Not locally, no. Apparently, the gold master has already been released, so it should be out in the next 2..3 weeks. Any updates here? Mac OS X is now available publicly. *** Bug 352858 has been marked as a duplicate of this bug. *** As noted in Bug 352858, the code to do this is already present in OSX SWT. Shell shell = window.getShell(); NSWindow nswindow = shell.view.window(); nswindow.setCollectionBehavior(1<<7); If you want to enable this for OSX now, you can follow the instructions at http://alblue.bandlem.com/2011/07/full-screen-support-for-eclipse-on-osx.html where I have put a plugin to enable this for OSX on Lion. Created attachment 200300 [details]
test patch
I still don't have Lion :(
could you please try this patch and let me know if it works for you ? Thank you.
(In reply to comment #9) > Created attachment 200300 [details] > test patch > > I still don't have Lion :( > could you please try this patch and let me know if it works for you ? Thank > you. The problem with this approach is that the method takes different parameters based on whether it's a 32-bit or 64-bit platform. On a 32-bit, the method parameter takes an int; on 64-bit, it takes a long. As a result, the code isn't portable between the two - even though the value is an int, the JavaC compiler will encode the parameter type into the class file. I've pushed a new fix which uses reflection to achieve the goal (at http://github.bandlem.com) - in essence, looking up a method called 'setCollectionBehavior' which takes a LONG and then falling back to one that takes an INT, prior to invoking. Finally, this approach leaves an empty bar across the top of the screen. This can be nullified by calling nswindow.setToolbar(null) - a default toolbar is created for a window, but if it is moved to full-screen then it occupies an ugly space. Re: the patch suggested - this would apply to all Shells, right? I'm not sure whether it makes sense to do this for (e.g.) Dialogs or tear-off views. Oh, and the test says + if (OS.VERSION < 0x1070) behavior |= 1 << 7 /*NSWindowCollectionBehaviorFullScreenPrimary*/; -- shouldn't this be a >= instead of a < here? I am using the plugin that Alex posted and it works well. However, I notice that if I fire up an Eclipse Runtime workbench to do some work on my own plugins I see these messages in the Console. So I am assuming these problems always exists and you just do not see them in the main Eclipse because I am not running it from a Console: vvv The below messages are caused by the existing windows having setCollectionBehavior called after startup from com.bandlem.eclipse.fullscreen.ui objc[95397]: Object 0x7fb35850f390 of class NSToolbar autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb353486200 of class NSFont autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354040370 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354031c30 of class __NSCFData autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354042520 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb3540a2490 of class NSCoreUIImageRep autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb3540167a0 of class NSImage autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354024840 of class _NSThemeFullScreenButtonCell autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb35404cf70 of class SWTAccessibleNSButtonCell autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354073990 of class _NSThemeFullScreenButton autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354024570 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb35401b6f0 of class __NSArrayM autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354015ac0 of class __NSArrayM autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb35401a9e0 of class NSTrackingArea autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354030690 of class NSConcreteMapTable autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354034730 of class NSTrackingArea autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354088ce0 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[95397]: Object 0x7fb354080ac0 of class NSTrackingArea autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug ^^^ The above messages are caused by the existing windows having setCollectionBehavior called after startup from com.bandlem.eclipse.fullscreen.ui (In reply to comment #11) > I am using the plugin that Alex posted and it works well. However, I notice > that if I fire up an Eclipse Runtime workbench to do some work on my own > plugins I see these messages in the Console. So I am assuming these problems > always exists and you just do not see them in the main Eclipse because I am not > running it from a Console: > > > vvv The below messages are caused by the existing windows having > setCollectionBehavior called after startup from > com.bandlem.eclipse.fullscreen.ui > objc[95397]: Object 0x7fb35850f390 of class NSToolbar autoreleased with no pool > in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb353486200 of class NSFont autoreleased with no pool in > place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354040370 of class NSPathStore2 autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354031c30 of class __NSCFData autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354042520 of class __NSCFString autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb3540a2490 of class NSCoreUIImageRep autoreleased with > no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb3540167a0 of class NSImage autoreleased with no pool > in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354024840 of class _NSThemeFullScreenButtonCell > autoreleased with no pool in place - just leaking - break on > objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb35404cf70 of class SWTAccessibleNSButtonCell > autoreleased with no pool in place - just leaking - break on > objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354073990 of class _NSThemeFullScreenButton > autoreleased with no pool in place - just leaking - break on > objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354024570 of class __NSCFString autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb35401b6f0 of class __NSArrayM autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354015ac0 of class __NSArrayM autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb353413220 of class __NSArrayI autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb35401a9e0 of class NSTrackingArea autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354030690 of class NSConcreteMapTable autoreleased > with no pool in place - just leaking - break on objc_autoreleaseNoPool() to > debug > objc[95397]: Object 0x7fb354034730 of class NSTrackingArea autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354088ce0 of class __NSCFString autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > objc[95397]: Object 0x7fb354080ac0 of class NSTrackingArea autoreleased with no > pool in place - just leaking - break on objc_autoreleaseNoPool() to debug > ^^^ The above messages are caused by the existing windows having > setCollectionBehavior called after startup from > com.bandlem.eclipse.fullscreen.ui I solved this by putting it on a thread in earlyStartup() : final IWorkbench workbench = PlatformUI.getWorkbench(); workbench.getDisplay().asyncExec(new Runnable() { public void run() { IWorkbenchWindow[] windows = workbench.getWorkbenchWindows(); for(IWorkbenchWindow window : windows) { showMacFullScreenWidget(window.getShell()); } } }); (In reply to comment #11) > I am using the plugin that Alex posted and it works well. However, I notice > that if I fire up an Eclipse Runtime workbench to do some work on my own > plugins I see these messages in the Console. So I am assuming these problems > always exists and you just do not see them in the main Eclipse because I am not > running it from a Console: Yes, you can see it in your error log or the workspace/.metadata/.log file. I put the warnings there explicitly so people would know where it comes from. I believe that it would not be a problem if called prior to the window being displayed. For example, you don't get those warnings if you do Window -> New Window, despite calling exactly the same code. (In reply to comment #12) > I solved this by putting it on a thread in earlyStartup() : Nice. Seems if you wrap it in the Display.asyncExec then it avoids those problems. I wonder what the reason behind that is? Oh well, I've pushed out 1.0.2 of the feature which uses this approach to remove the spurious errors - but as I said, I suspect doing it in the Shell constructor (or CocoaUIEnhancer) would also solve the problem since there wouldn't be anything shown at that time, and it will be on the SWT thread in any case. (In reply to comment #14) > (In reply to comment #12) > > I solved this by putting it on a thread in earlyStartup() : > > Nice. Seems if you wrap it in the Display.asyncExec then it avoids those > problems. I wonder what the reason behind that is? Oh well, I've pushed out > 1.0.2 of the feature which uses this approach to remove the spurious errors - > but as I said, I suspect doing it in the Shell constructor (or CocoaUIEnhancer) > would also solve the problem since there wouldn't be anything shown at that > time, and it will be on the SWT thread in any case. Indeed. Also, I suspect that CocoaUIEnhancer.createDummyToolbar(IWorkbenchWindow) is not needed on 10.7 as the lozenge is no longer there in 10.7. Created attachment 201029 [details]
work in progress
This patch adds the full screen button to all top level shells. I do not think dialogs should have the full screen button.
It also ties the Mac Lion full screen support to Shell.setFullcreen()/Shell.getFullScreen(). At first I though this was the correct thing to do, but I am not so sure anymore. Anyone?
note that you can find whether a window is in full screen mode with:
public static boolean isFullScreen(NSWindow window) {
long styleMask = Reflect.executeLong(window, "styleMask");
return (((styleMask >> 14) & 1) == 1);
}
However, I've seen some problems when you have more than one window open and you go into full-screen mode. I suspect you'd ideally make one window the primary (<<7) and make others secondary (<<8) but I've not verified that yet.
Also, the patch doesn't disable the toolbar which otherwise shows up as a grey lozenge at the top when in full-screen mode. I've been calling nswindow.setToolbar(null) to get rid of it, but I think it's being added in the CocoaUIEnhancer in the 'createDummyToolbar' method which probably shouldn't be called in the case of OS.version >= 0x1070
http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.ui.cocoa/src/org/eclipse/ui/internal/cocoa/CocoaUIEnhancer.java?view=markup
I have pushed out an update of my fullscreen enabler for Eclipse 3.7 (and apparently, it works on Eclipse 3.6 too). This adds the 'Esc' button to come out of full-screen mode, as well as a Window -> Toggle Full Screen menu item. The code has been refactored for those that want to re-use it; I have created an SO class which allows you to invoke behaviour regardless of 32-bit or 64-bit SWT under the covers. It also adds some NSWindow additions int he BnLWindow class (mostly, the toggleFullScreen and isFullScreen methods) Silenio, I guess you don't need any more help from me on this? The code is in the repository and I'd be happy to attach it if you needed it, but I think you're well on the way to solving it. The only thing is, since this adds API I'm guessing it's not likely to be available until the next Eclipse release? FWIW I think there are still some problems when there are multiple open windows and going into/out-of fullscreen mode. Given that the toggleFullScreen can be sent to any window, and only the window that was originally made fullScreen will toggle back correctly, there are some edge cases that I want to try and explore. I'm also not sure whether tear-off windows/shells should have a setting of 1<<8 (for the secondary window support), or even if that applies to additional windows. I'll experiment some more and let you know how I get on. I've been using Alex's plug-in a lot (thanks Alex!) and one minor feature that's not (yet) there is the ability to save the fullscreen state across workbench launches. Currently the behavior for Eclipse + Alex's plug-in is this: - If you exit the workbench in fullscreen mode, it restarts in "normal" mode - If you exit the workbench in normal mode, it restarts in normal mode The Lion applications from Apple that use fullscreen (e.g. Safari, iTunes) remember your fullscreen state across restarts, and I personally like this behavior a lot because I've noticed that if I switch an application to full screen, I always keep it there, with rare exception. I'm currently using Alex's patch and it really works well, but when I export my rcp app, it shows that dummy toolbar. I see that this bug should be resolved in 3.8 version, but I need something long before. Is there a way to remove the dummyToolbar in eclipse 3.7 in lion for my app? (In reply to comment #16) > This patch adds the full screen button to all top level shells. I do not think > dialogs should have the full screen button. > > It also ties the Mac Lion full screen support to > Shell.setFullcreen()/Shell.getFullScreen(). At first I though this was the > correct thing to do, but I am not so sure anymore. Anyone? Good question: are there circumstances where a top-level window *shouldn't* be able to be made full-screen? Hi Silenio, I tested the patch by launching eclipse with it and it works well. But, two things need to be fixed in the Eclipse UI code for the full-screen support: 1. remove the dummy toolbar in fullscreen mode 2. add menu item to Enter/Exit Fullscreen (In reply to comment #22) > Hi Silenio, > I tested the patch by launching eclipse with it and it works well. > But, two things need to be fixed in the Eclipse UI code for the full-screen > support: > 1. remove the dummy toolbar in fullscreen mode > 2. add menu item to Enter/Exit Fullscreen Please open two separate bugs in UI for these. We can provide a patch for the first one (remove dummy toolbar). I believe CocoaUIEnhancer should stop creating the dummy toolbar when OS.VERSION >= 0x1070, given that the toolbar button on the title bar is not available anymore. Once the dummy toolbar is gone, we should release this patch. It is up to the UI team to decide where the menu item to toggle full screen is going to live. They also need to remember the state when the workbench exits, so that it can be restored on restart. (In reply to comment #23) > (In reply to comment #22) > > Hi Silenio, > > I tested the patch by launching eclipse with it and it works well. > > But, two things need to be fixed in the Eclipse UI code for the full-screen > > support: > > 1. remove the dummy toolbar in fullscreen mode > > 2. add menu item to Enter/Exit Fullscreen > > Please open two separate bugs in UI for these. We can provide a patch for the > first one (remove dummy toolbar). I believe CocoaUIEnhancer should stop > creating the dummy toolbar when OS.VERSION >= 0x1070, given that the toolbar > button on the title bar is not available anymore. Once the dummy toolbar is > gone, we should release this patch. > > It is up to the UI team to decide where the menu item to toggle full screen is > going to live. They also need to remember the state when the workbench exits, > so that it can be restored on restart. Opened the following bugs to track them: 1. Bug 376155 2. Bug 376394 Hi Silenio, The setFullScreen() on the child windows no longer works with this fix. Is it as expected? It would break someone who is already using this API to set child window to fullscreen. Created attachment 214253 [details]
modified patch
Modified patch so that fullscreen button is hidden but setFullScreen() works on child window. Silenio, can you please review?
(In reply to comment #26) > Created attachment 214253 [details] > modified patch > > Modified patch so that fullscreen button is hidden but setFullScreen() works on > child window. Silenio, can you please review? Looks fine. Thanks Silenio! Fixed in master > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=9b1e6a553a714c81f1d1f1cccddf187918d20587 Found a problem with the above fix while testing on Nightly build N20120422-2000. When eclipse is in fullscreen mode, opening a child window causes the child window also to go into fullscreen mode. I have modified the fix in master to the patch in comment 16. I'll open a separate bug to track setFullScreen() not working on child window. I'm adding support from Platform/UI for 4.2M7 (bug 376394), and it's appears to be working. But I just wanted to confirm as the behaviour doesn't quite match what I see in other apps: * The full-screen button isn't shown on the main windows * Setting Shell#setFullScreen(true) doesn't lead to the whizzy animation of the window sliding onto a new screen, and the menu bar is still seen (In reply to comment #30) I don't see any of these problems with I20120427-1000 (3.8, 32-bit) on Mac OS X 10.7.3. (In reply to comment #31) > (In reply to comment #30) > I don't see any of these problems with I20120427-1000 (3.8, 32-bit) on Mac OS X > 10.7.3. Thanks Markus — it turns out the 4.2 I20120427-0800 build has an older SWT than the 3.8 I20120427-1000. Filed as bug 377997. Created attachment 220053 [details]
patch for R3_7_maintenance branch
The patch works for 10.7, but does not work with 10.8. The OS.VERSION value may change on 10.8, but did not check it yet. (In reply to comment #34) > The patch works for 10.7, but does not work with 10.8. The OS.VERSION value > may change on 10.8, but did not check it yet. Is this a problem with this patch specifically? Or a 3.8/4.2 build also fails on Mac 10.8? We do not have a Mac 10.8 to try it yet. Fullscreen works fine on OS X 10.8 with Eclipse SDK 3.8 and 4.2 without any patches. OS.VERSION is 0x1080 as expected. The only thing I found that is not perfect is the ControlExample: When you open a Shell and enable fullscreen via the window title button, then the checkbox is not checked. But that's a bug in the example. Sorry, I made a mistake on 10.8 yesterday. The patch did fix the problem on 10.8 as well. |