Open Kapeli opened 10 years ago
Probably we can use NSWindowMaskFullScreenContentView or whatever it's called. Also, CoreUI rendering still draws 10.9'ish in 10.10 and [NSWindow coreUIRenderer](while it still exists) returns nil. Might just be a bug at this point though; some system apps in 10.10 have different title bars than others.
Yes it is harmful: the added subview is in fact not added! Note that this bug only occurs when built on 10.10. Not when built on 10.9 (and ran on 10.10).
First screenshot is code built on 10.10
vs
Second screenshot is code built on 10.9, ran on 10.10
Are you sure you are running the latest version of Yosemite? I remember seeing an identical rendering artifact in the first couple previews; it's gone as of the third.
Also, your screenshots don't actually seem to indicate that a subview is missing, so I'm a bit confused here.
(I'm ahugele, sorry for mislogin) Yes it's Yosemite beta 4 (14A298i). You're right, I quickly assumed the custom subview was missing. The exact message is "NSWindow warning: adding an unknown subview: INMovableByBackgroundContainerView: 0x100237440" followed by the stack trace.
Anyway, the rendering is different as I of course want a full black background, even around the title. Note that I'm using a custom drawing block (because the black black background is in fact a gradient)
I also get this warning on the latest version of Yosemite.
Getting the warning in the public beta (14A299l), and getting the title field rendering issue that @ahugele showed above (though, for me, it only happens about half of the time I open the window!).
I have two different windows. The first one sees this problem but the second one doesn't. They use identical initialisation code. anyone got a workaround?
It sounds to me like more than a simple warning, see "Applications doing this will need to fix this problem".
https://developer.apple.com/library/prerelease/mac/releasenotes/AppKit/RN-AppKit/
New since WWDC seed: NSWindow has never supported clients adding subviews to anything other than the contentView. Some applications would add subviews to the contentView.superview (also known as the border view of the window).
NSWindow will now log when it detects this scenario: "NSWindow warning: adding an unknown subview:".
**Applications doing this will need to fix this problem**, as it prevents new features on 10.10 from working properly. See titlebarAccessoryViewControllers for official API.
Hm. I wonder if INAppStoreWindow could be re-engineered as a shim for new Yosemite NSWindow APIs...
That's not really a suitable workaround as you can only add accessory views to the right and bottom of the titlebar (see NSTitlebarAccessoryViewController.h - layoutAttribute
). Maybe this will change in the GM.
What the AppKit RN says is a little depressing. It officially states that the INAppStoreWindow way to customize the title bar is not supported. And NSTitlebarAccessoryViewController is not a replacement at this time.
I suggest we all radar that to apple.
Upgraded to Yosemite and encountering this problem here too now. Is there any fix in sight? If not I might have to stop using this otherwise nice control.
Also echoing that we're using InAppStoreWindow and running into the same issue.
Same here.
I have a production Yosemite app using this, and while the warning is logged, it doesn't seem to affect the functionality (at least for now). There's no workaround that I can see, so I'll file a radar but it's unlikely that they're going to reverse that decision.
I'd be very interested to know if any apps get bounced because of this.
@gregucsd My app got approved a few days ago.
There's no workaround that I can see, so I'll file a radar but it's unlikely that they're going to reverse that decision.
Why would (or should) they? We should simply rewrite INAppStoreWindow to use the proper APIs...
There are no proper APIs to do what INAppStoreWindow does. They added an NSWindow API for title bar accessory view controllers to compensate for this change, but it's nowhere near sufficient to implement INAppStoreWindow.
@indragiek Great. Thank you for confirming. @jakepetroules I haven't seen "proper" APIs for this. In my estimation it means recreating all of the window title / tool -bar functionality in a borderless window. I would've thought there would be a standard way to do this but looking through Apple's apps (iTunes, xCode, Calendar, etc) they all have different looks that obviously have very different requirements and backing to support.
This is how WebKit "solved" the issue: http://trac.webkit.org/changeset/170980/trunk/Source/WebKit/mac/WebCoreSupport/WebInspectorClient.mm
I tried adding this to INAppStoreWindow.m:
@interface NSView (AppKitDetails)
(void)_addKnownSubview:(NSView )aView positioned:(NSWindowOrderingMode)place relativeTo:(NSView )otherView; @end
if ([self.themeFrameView respondsToSelector: @selector(_addKnownSubview:positioned:relativeTo:)]) { [self.themeFrameView _addKnownSubview: container positioned: NSWindowBelow relativeTo: firstSubview]; } else { [[self themeFrameView] addSubview:container positioned:NSWindowBelow relativeTo:firstSubview]; }
which mostly works and no longer produces a warning. However, the container seems not to be positioned correctly or so. I see my own subview I added, but not, e.g., the traffic lights.
That's private API, so you won't be able to submit to the Mac app store if you use that method.
here is the solution https://github.com/guolai/mac-titleBar
If you only intent to have a custom title bar height on Yosemite: My current work-around is to check if it's running on Yosemite at runtime. If not, use INAppStoreWindow as usual.
Otherwise use a normal NSWindow, and add a NSTitlebarAccessoryViewControllerto the NSWindow's title bar using addTitleBarAccessoryViewController:, which controls an empty dummy view with the desired height.
Not feasible if you create the main window in your main xib (as you have to set the window class there).
www.soft-gems.net
I published WAYWindow, which aims to provide an interface similar to INAppStoreWindow, but exclusively for OS X Yosemite applications. Hope I can help some guys with it.
@mike-lischke You're right. One solution could be to create the NSWindow at runtime (either NSWindow, WAYWindow or INAppStoreWindow) and only define a view in the XIB, instead of a whole window, which will then be added to the window's contentView.
@raffael This is pretty cool. Thanks for that. What about adding something that can be used to switch between WAYWindow and INAppStoreWindow depending on the app kit we are running on? E.g. you could derive WAYWindow from INAppStoreWindow and disable functionality that only works on Yosemite if the app runs on older OSX versions. That would be awsome!
@mike-lischke
I had the same thoughts, but I wanted a separate repo for this.
So I just published WAYAppStoreWindow, which does the following:
At runtime it detects whether the app is running on OS X 10.10 or greater, and if so, the class implementation will be switch to WAYWindow
. Otherwise, INAppStoreWindow
will be used.
This is an ugly hack, and I haven't tested it yet profoundly.
However, setting a custom title bar height, hiding the window title and centering the traffic lights works beautifully.
Well, it's not that ugly and works pretty well (after applying my changes to avoid WAYWindow to crash). I recommend everybody here to try this out, even though there's still a layout problem (reported already).
We just updated the repo (WAYAppStoreWindow) with fixes for the mentioned bugs. Thanks, mike!
@raffael Thanks for WAYWindow
! However, I'm also using other properties of INAppStoreWindow
like verticallyCenterTitle
, titleFont
and titleTextColor
, which are not supported in WAYWindow
right now. Any plan to support them too?
@ishuo Thanks! Some of INAppStoreWindow
's features are not supported (yet?) by WAYWindow
. It's a starting point. For our projects it was important to have at least a window instance with customizable titlebar height and traffic lights layout. If you use WAYAppStoreWindow
instead of WAYWindow
directly, you'll get some decent warnings in the console, instead of exceptions for unrecognized selectors.
We might add more features in future!
I'm currently looking for a way to add a Subview to the Window Titlebar on Yosemite, so if anyone has an idea how to do it the right way, would be great if I could get an answer over at Stackoverflow. I am looking for the best approach which is less likely to break in the future… (I'm asking this here because here seem to be a lot people to have experience with it and INAppStoreWindow could benefit of a solution for this too)
Note that NSTitlebarAccessoryViewController with right layout actually adds a view that spans to the full width of the titlebar, not only to the right of then window controls, but there is a problem with the height (see linked SO above)
How can i use WAYAppStoreWindow with backward compatibility to OS x10.9.5?
utkarshagutpa, pls don't hijack issues for support questions. You could open an own issue or ask on Stackoverflow. WAYAppStoreWindow automatically handles compatibility by replacing the actual class that is instantiated depending on the OS.
@interface NSView (AppKitDetails)
bool isTenTenPlus;
(NSButton )_windowButtonToLayout:(NSWindowButton)defaultButtonType orUserProvided:(NSButton )userButton { NSButton *defaultButton = [self standardWindowButton:defaultButtonType]; if (userButton) { [defaultButton setHidden:YES]; defaultButton = userButton; } else if ([defaultButton superview] != [self themeFrameView]) { [defaultButton setHidden:NO]; }
if ( true == isTenTenPlus ) { [self.titleBarView addSubview:defaultButton]; }
return defaultButton; }
Hi guys, has anyone seen any solutions to this? I too need some of the INAppStoreWindow properties so usingWayWindow isn't feasible at the moment... :(
Same issue here. Would be great if it can be fixed.
Sample app logs this warning:
As far as I can tell, this is harmless (everything seems to work), but it would be nice to figure out a way to fix or suppress this warning.