I have an application that at times can bring a view into fullscreen mode on a second display. The application does this by using the "enterFullscreenMode:withOptions" api on the view.
How ever what's odd is that while in fullscreen mode on another display, system shortcuts such as cmd+tab or alt+space doesn't work any more, all normal characters work though. And when I bring the view out of fullscreen mode the keyboard works normally again.
How can I fix this?
Related
ISSUE:
On a touch panel with no keyboard, my QT C++/QML app running on Windows 10 IOT has the fullscreen GUI "frozen", when the monitor turns on (after the user has triggered the touchscreen), after it has timed-out earlier and turned off due to power settings. Mouse cursor still updates.
The QML GUI has "flags: Qt.FramelessWindowHint | Qt.Window"; I do not want to add "Qt.WindowStaysOnTopHint" as it will block the control panel window when it is open from the app. The program is verified to be still running, only the GUI has frozen from the point in time when the screen turned off.
TEMPORARY RESOLUTION:
The only way to "unfreeze" the fullscreen GUI is to connect a keyboard & press the Windows key to show-hide the start menu, or do it programmatically with a manual QML button placed at a known position or on detection of monitor WM_POWERBROADCAST messages.
When the app is not fullscreen, the freezing doesn't seem to be happening.
Is this due to some missing WM_MESSAGES (e.g. WM_PAINT, WM_ACTIVATE, etc) sent by the OS to the app when it is fullscreen, or when the start menu button is pressed?
Can the app-fullscreen-freezing on monitor-turn-back-on be rectified by the app programmatically sending a sequence of WM_MESSAGES to itself, but not the Win button keypress (as the normal user is not supposed to access the OS or see anything related to the OS when the app is running)?
I tried using winAPI SetForegroundWindow() function...?
:-( Fast forward a few days...
With further testing, it seems that using SetForegroundWindow() alone is not consistent/reliable. Sometimes it works, sometimes it doesn't.
The most reliable that works 99.999% of the time is still the VK_LWIN keypress sent by the app. But, as mentioned before, the app user is not supposed to see the start-menu appearing then disappearing. Best if the behavior of the VK_LWIN keypress could be duplicated to the app without seeing the start-menu...
I have a MacBook Pro running Catalina with an additional display. I typically have my development-related apps on one display (iTerm2, VSCode, etc.) and everything else on the other display (Chrome, Slack, etc.)
Sometimes (not all the time), when I switch desktops (Ctrl+left or Ctrl+right), access an app using Spotlight (Cmd+space and type), or use Cmd+Tab to switch applications, the focus would suddenly jump to iTerm2 or VSCode. This happens even if iTerm2 or VSCode isn't currently showing; for example, if I try to switch to Chrome on display 1 and iTerm2 is on a different hidden desktop on display 2, Chrome would appear on display 1 and then display 2 would show the desktop containing iTerm2 sliding into view (along with focusing iTerm2).
This severely impacts workflow, since this behavior is unpredictable and involves a lot of typing in the wrong application and reaching for the mouse. What is causing this behavior?
I found that it only happens when I have windows of the same app on both screens.
Say I switch desktop on a screen 1 and Chrome should become active there, then if I also have a Chrome window on my screen 2, it's actually the one on screen 2 that becomes active. Very frustrating..
This bug still exists in macOS Big Sur 11.4. Another symptom is that, after the erroneous focusing happens, manually switching to a space with no windows in it will leave that focused app focused, after briefly focusing Finder, rather than just focusing Finder. It's this last erroneous focusing that causes the space-switching.
Workaround: when it happens, invoke "Show All" from the menu bar (I have a keyboard shortcut for this). Note that switching to an empty space now does a single focusing of Finder, and no further space-switching happens.
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.
Following up on this ( Display System Keyboard Mac application? ) question, the keyboard is coming up fine, but if my application is in fullscreen mode, the keyboard launches, but remains in the background. How do I get around this? Any help is much appreciated!
Thanks,
Teja
Full screen is, by definition, above other windows and elements. I don't know how well this would work, but you could try asking the view for its -window, then using -setLevel: to lower the window level. Unfortunately, assuming it works at all, this would probably allow other elements (like the dock or other floating panels above your full screen view as well.
Somehow, Expression Blend has entered full-screen mode (no window chrome), but I can still minimize/maximize/restore/move through the taskbar button. I don't see any menu options for full-screen mode, and the normal keyboard shortcuts don't work (F11, Alt-Enter).
I'm not sure how this happened, but I would sorely love to get my chrome back to make interacting with the window easier.
I've never seen a Full-screen mode in Blend. Maybe you accidentally hit Tab or F4 and did an Auto-hide to all of the panels?
you can press ESC button
in code use:
Application.Current.Host.Content.IsFullScreen = false;
check this
After not even trying to use Blend for my application for a really long time, it turns out it was my own fault to begin with. I had created a custom chrome control that would find its parent Window and remove the frame. I wasn't checking design mode, so whenever my control was instantiated by blend, it would remove all the chrome from the window :).