-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NSWindow warning in Yosemite #169
Comments
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. |
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). Anyway, the rendering is different as I of course want a full black background, even around the title. |
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/
|
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 |
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. |
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)
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 |
Mike |
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 |
@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 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 |
@ishuo Thanks! Some of |
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. |
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;
|
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.
The text was updated successfully, but these errors were encountered: