A list of windows in the dock menu?
scott.kovatch at oracle.com
Thu Mar 1 10:12:32 PST 2012
On Mar 1, 2012, at 9:05 AM, Mike Swingler wrote:
> On Mar 1, 2012, at 8:22 AM, Scott Kovatch wrote:
>> On Mar 1, 2012, at 6:44 AM, Anthony Petrov wrote:
>>> Hi Mike,
>>> The dock menu for a Java app displays a list of Java top-level windows when run with Apple JDK. However, with 7u4 the list won't show.
>>> According to the documentation, app's "open documents" are listed in the menu. Does this mean we have to associate an NSDocument with each instance of AWTWindow class? Or is there any other way to make the list visible in the menu?
>> All you need to do is have a menu named 'Window' in the nib file, and Cocoa will take care of updating it with all of the open windows, and adding it to the dock icon. The window has to have a title, I believe. That's how it used to work, anyway.
>> Aren't we using the shared DefaultApp.nib?
> That isn't the problem (well, it's a problem, but not related to the Dock window menu). The default NIB has never had a Window menu because developers often add one themselves, and then there is two. We've lived without that from Java 1.3 to 1.6, and have only gotten a few bugs along the lines of "I can't create the dashes and diamonds in the real Window menu"...so people clearly want to be HIG compliant, but it hasn't seemed to occur to them that we should be doing it for them. I'd love to see a "use the platform Window menu" in the menu bar.
Double-check DefaultApp.nib. There should be a free-floating NSMenu instance in there with a title of Window (or maybe a name of 'Window', I don't recall.) It's not added to the default menu bar. It's been there since 1.4.2 or so, unless someone took it out after I added it. :-)
This isn't about adding a Window menu to the menu bar -- there's no way the AWT can handle that in an HIG-compliant way.
> As to the issue at hand:
> I think the problem is that JDK7's top level windows are actually NSPanels, not NSWindows. This is so custom style bits can be applied to them (like titlebar-less, utility or HUD). Further work would need to be done to create an NSWindow subclass and an NSPanel subclass that could be dynamically changed at runtime to support "elevating" a window to a new style (and subsequently loosing it's name in the default Window menu - as it should) - but from Java's perspective, that should amount to a re-parenting operation.
> You can switch the superclass to NSWindow, but I think that will have unexpected consequences for untitled windows. If it doesn't, that only means you lose the extended styles like utility and HUD, which may be a reasonable tradeoff for getting the window title names in the Dock (but not in the main menu bar).
That makes sense. I didn't know we were using NSPanel for all windows, though.
I remember this now from when I implemented palette/utility window support in the SWT. I don't think that the SWT supported changing a window's style after it was created, so I could look at the style bits at creation time and make an NSPanel or NSWindow as appropriate. I guess there's a use case for being able to change the window style whenever you want, but I can't imagine when it would be useful to do so.
-- Scott K.
More information about the macosx-port-dev