I am making an app that has fullscreen support (enabled via interface builder). The app has another NSWindow that appears from time to time as a sort of 'inspector' like in pages and such. However when the primary window goes fullscreen, the secondary one does not accompany it, and I have to go back to my desktop to see it.
Is there a way of fixing this? i.e. when Safari is fullscreen, you can open the activity window and it accompanies safari in fullscreen mode. Thanks a lot!
If you've actually built an inspector-style panel window (e.g., by dragging a Panel or HUD Window from the Xcode object library into your nib), it will automatically accompany the primary window in fullscreen.
I believe the minimum requirements are that:
collectionBehavior includes NSWindowCollectionBehaviorFullScreenAuxiliary
collectionBehavior does not include NSWindowCollectionBehaviorFullScreenPrimary
either collectionBehavior includes NSWindowCollectionBehaviorTransient or level >= NSFloatingWindowLevel
If you read the documentation on full-screen mode, most of this is explained, although a few details (e.g., when these values are checked…) need to be discovered through trial and error.
Related
Background
We are building a cross-platform application with "popup" reminders, they are custom windows/dialogs which uses QWidget.setWindowFlags like this:
self.setWindowFlags(
QtCore.Qt.Dialog
| QtCore.Qt.WindowStaysOnTopHint
| QtCore.Qt.FramelessWindowHint
)
These popups show up on the systems we have tested (MacOS, Lubuntu (LXDE)), even when we switch between different virtual desktops the dialogs are still shown in the current desktop. However:
Problem
When the user is in fullscreen mode on MacOS (Sierra 10.12.6) the dialog instead is shown in the last virtual desktop that was used
Question
How can we show our "popup" dialogs to the user even when the user is in fullscreen mode on MacOS?
The short answer is that you can't and neither can any other app.
Here's why.
The idea is that when you select the fullscreen view for an app, you want to focus exclusively on that app, to the exclusion of all others. So the app not only expands to fill the entire screen, it removes the menu bar and creates its own desktop space.
You can see how this works using Mission Control (by default, swipe up with 3 fingers). You will see all the apps and all the desktops across all your monitors. Next, set an app to full screen and swipe up again. You'll see that the app has a dedicated desktop (which I believe doesn't even have wallpaper).
The bottom line is that macOS fullscreen view does not support pop-ups.
Our agency has a Java web application that uses a third party Java applet as a TIFF viewer. In this application javascript spawns a separate window (and yes, it must be a separate window). We are currently using an in-house ActiveX control so that the HTML window can have the window state, window size and position, and screen device presisted and restored via localStorage. Our agency is IE11 only so for now using it is not a problem. It's embedded in the page and operates on the "containing window".
This control was made many years ago in VB6. It appears that Visual Studio doesn't support the creation of ActiveX controls, and I don't personally have the knowledge or skill to create one another way.
Please do not suggest the HTML DOM window and screen objects! Most answers I've searched for just refer to these! They can't get the entire browser window size (viewport + chrome + toolbars + titlebar), nor does javascript have any idea about Windows-specific things like window state and screen device (it's always the OS primary screen). I understand the HTML DOM can't be tied to anything OS-specific in order for it to be implementable on multiple platforms.
Up until now this control has worked pretty well - you can, for example, maximize on a given screen and restore the window to the same screen. But I realize that ActiveX won't be supported forever and it's IE only...It seems to me, though, that the need for such functionality can't be totally uncommon. I'm guessing that some may suggest that the application UI should be changed so that this is less of a problem - but being able to put the viewer on a different monitor from the application, and having that window be restored exactly to it's last position is important to us. I do understand that if you reuse that window the user only has to position it once, but we'd rather not require this of the user.
Question: are there any alternatives to interacting with the win32 API other than COM/ActiveX ? Are there any other methods of accurate window persistence that can know about screens other than the OS primary, and maximized/minimized/normal windows) that use something other than the Win32 API?
On Mac it is usual that there is a "hidden" main window.
The usual example is "Text Edit". When you open a file you with you don't see a "main frame". Instead every single file will be opened in its own "Text Edit" instance. This is OSX way of emulating the so-called MDI interface.
However, there is an exception. If you open Xcode and open the project there, you can click on the file and it will be open inside the main Xcode window. And if you double click the file it will be opened in its own independent editor window, keeping the main Xcode window visible.
My question would be: do I need to do anything special in order to make my program behave like an Xcode? Should I use different class for the main frame or maybe react differently on the opening document event?
Any hints/pointers where to look or even to the official Apple documentation would be helpful.
The TextEdit behavior you're describing is much more like “SDI” than “MDI”, and the terms “SDI” and “MDI” weren't even needed until Microsoft invented MDI long after Xerox invented the SDI-type interface of which macOS is a derivative.
Anyway, I think you are misunderstanding Xcode's behavior. You seem to think “its own independent editor window” is a different kind of window than “the main Xcode window”. But in fact the new window is of the same kind as the old window, with some optional parts hidden. You can show those hidden parts and make the new window look exactly like the old window. Demo:
The ability to open multiple windows showing the same document (or, in Xcode's case, project) is a matter of software architecture. If you carefully design your app so that multiple windows can share a single model object graph, and can be notified and redraw themselves when the object graph changes, then you have an app that supports multiple windows showing the same document. If you want multiple kinds of windows showing the same document, nothing about Cocoa stands in your way. As a matter of fact, Xcode does have at least one other kind of window in which it shows some properties of a project:
That project settings sheet is really another window; macOS keeps it attached to the main window, but it is in fact an instance of NSWindow (or a subclass of NSWindow), no doubt with its own custom window controller that references the same project objects as the main window.
If you use the Cocoa NSDocument architecture, then a small amount of multi-window support is built-in: an NSDocument knows about its associated windows (via their window controllers). If you want to use the NSDocument architecture, you should read Document-Based App Programming Guide for Mac.
It is unclear what you are after. The traditional Mac UI has been one window per document - i.e. SDI with a single instance of the app running multiple windows - but there has always been the ability for any app to organise the content of that window as it sees fit, including showing multiple "documents" within one window - i.e MDI type UI.
Apps approach such "MDI" in different ways, e.g. some use panes (views) and others tabs. From macOS Sierra the standard NSWindow supports tabs, this system is (semi)automatic for standard document apps. Read Apple's NSWindow Automatic Window Tabbing section in the Sierra release notes for more details.
If you wish to use multiple panes - e.g. like Xcode - you just use views (NSView) and arrange them how you wish.
HTH
I have an application for Windows which is basically a toolbar on top of all windows.
Unfortunately, our users ask why does it overlap a fullscreen video playing in Google Chrome. Since the application works with no issues along with other fullscreen applications (such as games), it seems to be a pseudo fullscreen mode. How do we hide the toolbar in such cases?
Right now there is only one idea: keep an eye on MoveWindow, compare window class name against a predefined list and rectangle against screen size then deduce whether it is the 'pseuso fullscreen' mode. Any better ideas?
I am trying to build an Adobe AIR app that runs on two monitors with an extended desktop. Is that possible?
I've read fullscreen is restricted to a single display and the only option is to maximize the app to both displays. Is that right? If so, how can I hide OSX top menu bar?
Just for the record, OSX does not allow you to have more than one full screen applications (of any kind, not just AIR) open at the same time nor it let's you to expand a full screen app to more than one display.
An application window can span multiple displays as long as the window is sized properly. Menubar and dock can also be hidden. Check NSWindow in the apple documentation for more info. Adobe may or may not support this feature.