I currently have a NSWindow that allows for full screen. The window has a video player and a playlist below it. When the user goes fullscreen, I want to get rid of the playlist and just show the video.
My first thoughts for doing this is to swap out the window when I detect a fullscreen entry point. I have found that I can detect this with the following:
- (void)windowWillEnterFullScreen:(NSNotification *)notification
{
NSLog(#"My window is going fullscreen");
}
But I have been unable to figure out how to swap out the window for a new one at this point. One option I haven't yet attempted would be to modify all of the resizing flags of the video and hide the other components but I'm not certain if this would be the best solution.
Does anyone have any suggestions on a better way for doing this?
Why do you want to swap the window? Just manipulate the views in the window.
Just remove the playlist from your view when you go fullscreen with -removeFromSuperview and then resize the video view so that it fills your window.
Make sure you hold a reference to the view as an ivar somewhere, because otherwise the view will be deallocated. You can then use that reference to add the view back when the window exits full-screen mode.
Related
The user clicks a button and I present a new viewController as show.
Inside that VC there is a AVPlayerView, the same size as the VC.
The app itself can change size if the user drags any of its corners but the VC displaying the movie cannot.
Why things like that that should work by default, don't work as expected? What can be done to make this work?
Example:
This is the main app.
I can drag its corners and make it bigger or small. I can click on the green semaphore and make it full screen and it works fine.
When I press the Help icon, this "window" appears. It is a viewController that was added the story board.
This cannot be scaled. It "appears" to be a window, because it contains a semaphore. I cannot scale this but I can make it full screen by the green semaphore.
Note: I have added the view to a WindowController and now when the user presses the Help button this window controller is launched and the video appears. No change. Video cannot be scaled.
Found the problem.
I had to add a window controller controlling that View Controller.
View controller was not resizing even after #1.
Then I found that I could not have
self.preferredContentSize = CGSize(width: 940,height: 504)
inside awakeFromNib.
Now it works perfectly.
"The app itself can change size" –– what you're saying is that the window can be resized by the user.
"but the VC displaying the movie cannot" –– Again in this case, you're not trying to resize a view controller, you're trying to resize a window. The window contains your view controller.
The reason the window can't be resized is probably due to the layout constaints. I imagine there must be constraints somewhere in the view hierarchy which specifies that the video player (or some other view) has a specific width and height. Because it's a constant value, the window can't resize.
I'm writing a program that needs to get the mouse position in the screen, (not just my view). I need to continuously update variables xPos and yPos. I've heard about subclassing nsview and adding mouseDidMove, but it is never called. (Yes, I set my window view to my custom view.) How can I do this?
You need to set the NSWindow which contains the view to window.acceptMouseMovedEvents = yes. Also if you're just looking for mouse position in the screen consider NSEvent.mouseLocation
I'm using Window Services' CGWindowListCreate and CGWindowListCreateDescriptionFromArray to get window information. When getting kCGWindowBounds in a regular Space everything works fine (I'm drawing borders around the frontmost window on the 0th level). However, when I use the same method while on a fullscreen application's Space, I get nonsense bounds: (0, 855, 480, 1).
I wouldn't care much about this if there was an easy way to tell if I'm currently at a fullscreen app's Space, because then I'd just draw a border around the screen (well... it would depend if the menu bar is showing...).
Is this a bug, or is there a reason for this behavior?
EDIT:
Figured out my problem. It's a bigger issue than I would have liked. The thing is the API goes through ALL NSWindows, even the ones that aren't, well, normal windows. Chrome's loading bar on the bottom is a window by itself, for example, and Mail also has some window on the top of the app. This is a problem because I have no way to differentiate the window that looks to be frontmost.
For my app, I would like to capture a specific window to intercept mouse events in it. I would have liked to be able to have the user press a hotkey and then click on the desired window to select, but there is no API to get the window under the cursor. I have no clue how to proceed.
Edit 2:
To better help people find a useful answer, changed title from: "Quartz Window Services returning wrong window bounds for fullscreen apps"
Have you got these methods defined for the window delegate?
- (NSSize)window:(NSWindow *)window willUseFullScreenContentSize:(NSSize)proposedSize
{
NSRect mainDisplayRect = [[NSScreen mainScreen] frame];
CGSize cgScreenSize = CGSizeMake(mainDisplayRect.size.width, mainDisplayRect.size.height);
return cgScreenSize;
}
- (void)windowWillEnterFullScreen:(NSNotification *)notification
{
}
- (void)windowDidEnterFullScreen:(NSNotification *)notification
{
}
- (void)windowWillExitFullScreen:(NSNotification *)notification
{
}
I proceeded by going through the description dictionaries and checking if the current cursor position was inside the bounds of the windows. The first window to satisfy this would be the window right under the cursor, which is exactly what I needed.
Separately, to find the current top-most window, I used the iChat Apple example of the Accessibility API to register ApplicationActivatedNotification and MainWindowDidChangeNotifications. Both notifications combined would let me keep track of the main window of the active app (top-most). To get the bounds in this case, I just got the main window's position and size using the Accessibility API.
I am in the process of creating a small image editor.
What I aim, is to create a window with transparent titlebar, but not what contains inside the window.
I have check HUD Window, but it's really is a panel, not a window. And I am missing the regular close,maximize and minimize button.
Is there anyway to create such window?
Or can we modify HUD to hold regular close,max and min button?
Thanks so much in advance!
Eko
Use a standard borderless window approach and provide a content view that draws something. Even if the content view's bounds rect is just filled with [NSColor whiteColor].
Update: Re-reading, I see you seem to be asking for just a transparent title bare but still with the window controls. See this StackOverflow question for an approach at customizing a window's title bar. Careful, though - I'm not sure this would be accepted into the App Store. Best to have a backup plan in case it's not.
Here is what I found that match to what I want : window trasparency
The trick is making the main window transparent, but not the content by creating a special view for this.
Is there a way to preserve window position in Interface Builder? Every time I reopen a nib file, the MainWindow.xib window finds its way back to the top left of the screen, behind the window containing the interface I'm laying out. Moving it back to where I had it before every time is starting to get on my nerves. Seems like there should be an easy way to do this, but if there is I haven't been able to find it.
Thanks!
Interface Builder does not save window location/size on a per-nib basis, but it does automatically remember the size and position of the last nib window and uses that when opening future nib files. For example, if I open up nib file A, change its window's position, and then quit IB, then open up nib file B, its nib window shows up with the same location/size I had set for nib file A.
However, it appears that Interface Builder also cascades multiple windows down and to the right slightly when you open them up, so that a second nib file's window doesn't appear directly on top of one that's already open - makes sense. The problem appears to be that if you have a nib window positioned all the way at the bottom of the screen, so there's not enough room to open the next nib window, it results in the window being placed all the way at the top of the screen. Then of course once that happens, IB remembers that window position as the default, so subsequent windows also get opened at the top of the screen.
So, the "solution" is a) file an enhancement request on Bug Reporter to remember per-nib window positions :-), and b) in the meantime be careful about positioning your windows too close to the bottom of the screen.