How to make the top QWidget modal? - qt

I'm developing an application in PyQT5 which has a QWidget object on the top. This application needs to be able to run in 'kiosk' mode, so my aim is to make that top QWidget modal and prevent any other running application of being focused.
The skeleton of the main class is below. Note that I'm calling the setWindowModality() method which in theory sets the behavior of the window to the chosen one:
class MyApp(QWidget):
def __init__(self):
QWidget.__init__(self)
self.setWindowModality(3)
My main method is the following:
app = QApplication(sys.argv)
MyApp()
sys.exit(app.exec_())
As per the setWindowModality() method documentation:
Qt.NonModal 0 The window is not modal and does not block input to other windows.
Qt.WindowModal 1 The window is modal to a single window
hierarchy and blocks input to its parent window, all grandparent
windows, and all siblings of its parent and grandparent windows.
Qt.ApplicationModal 2 The window is modal to the application and
blocks input to all windows.
The problem is that the window is not modal at all, I can switch to a different application (say a Web browser), which is exactly what I want to prevent. I've also tried 1, 2, 3 as values and they produce the same behavior.
I'm afraid this could be a design restriction in order to avoid apps block other apps, but I'm not sure of it and I'm unable to confirm it.
Am I missing something obvious here? In case the problem is the design restriction, is there a way to still simulate a modal window?

Modality is only with respect to current application. If application has only one open top level window, then there's no difference between application and window modal. This modality has no effect on other applications, so you are not able to achieve what you want with it, there's no simple "desktop modal" flag.
You can use Qt to make the window full screen, but you have to use other means to prevent user from accessing the desktop, or closing the app (often bound to ALT-F4 keyboard shortcut). If your platform is Windows, then I don't know how to do that, but I'm sure there's a way. Under X11 (used on Linux usually), the most straightforward way to do that is not have a desktop at all, simply by just running the app without desktop. Look up nodm package for an easy way to do this.

Related

notifyiconwpf and GUI automation

I have an application that uses this application type that I need to automate. Unfortunately, the application window is invisible to my automation tools. Are there any suggested ways of working around this problem? I'm using pywinuto for automation. I can't even inspect the window data for this application.
EDIT:
from pywinauto import Application
from pywinauto import taskbar
app = Application().start("path/to/my/app")
#make the window visible
taskbar.ClickHiddenSystemTrayIcon("My App")
#When I query the number of windows the app has.
len(app.Windows())
#I get zero windows. There should be at least one window
#because the window is currently visible.
I've also tried the findwindow methods for which I can get a WindowSpecification but it is not connected to any window.
In order for this app to be automatable, the developer had to wrap the NotifyIconWPF in a standard window, conditionally, depending on command line switches. Once this was done, the windows for this application became accessible to pywinauto. It looks to me like Caliburn Micro, intentionally, disabled accessibility for this window class.

How to "embed" one window inside another

I have inherited a Qt-based app that handles the master/detail relationship by presenting the detail screens as separate windows. The main window includes a list, and when you tap on a row a separate detail window is opened up.
In the code base, the detail windows are handled by a QML file and a matching .cpp file (the main window also has its own .cpp file). The problem I am facing is that a new client wants me to modify this application for them, except that they want everything to occur within a single window. They want the list to be shown on the left side, and then when a user taps a row, the detail screen is to be shown on the right side of the window in its own panel (but not in a separate window).
For various reasons I can't easily refactor this application. A quicker solution for me would be to continue to present the detail screen in its own window, but to make it a borderless window and position this borderless window over top of the main window (on the right) so that it appears to be a panel within the main window.
Is something like this possible with Qt? I have written Windows apps in the past that hooked into the Windows API to do something like, but I don't know whether this is even possible in a native Mac OS app, so I don't know whether Qt can handle it in some way automaticaly.
One thing you could try is to create a widget based "main" window and then use QWidget::createWindowContainer() to wrap the QtQuick windows for positioning them with QtWidget means, e.g. layouts.

What to use with Qt for independent windows: a QDialog, a QWindow or a QMainWindow?

I am making my first steps with Qt. As an exercise, I am writing a GUI for a many-core processor, and individual cores are shown in a separate window. From this window, there may be several copies, with their independent life, including menus, status line, etc. That is, they are essentially like a QMainWindow, but having a QMoreMainWindow :). Might be any side effect if I use QMainWindow several times?
Nothing prevents you from using any of them for anything. They do have different roles and properties:
QMainWindow is just that: a main window. It has a toolbar, dockwidgets, a menu bar, a status bar, and a central widget. If you don't need all (most of) those things, you clearly don't want a QMainWindow.
QWindow is a barebones object in which is useful if you don't want/need QWidget's functionality.
QDialog is meant to be used for pop-up windows (i.e. "dialogs") like a messagebox or an open file dialog.
QWidget is the basic window or window element. If in doubt, use this.
Reading your question, it seems you want each of those windows to be a QMainWindow. Note I'd still prefer a custom QWidget with only the parts I needed if I were you. Adding a statusbar and menu isn't that much code.
multiple main windows is no issue at all. I also use them in my application and they work fine. You can either have the main windows separately (no parent) or dependant on some main mainwindow, so that they are closed when the main mainwindow is closed.
When your main windows have independent lives and menus, status lines etc., this speaks even more for multiple main windows that probably should all have no parent assigned.
So, yes, your approach seems perfectly fine to me.

Application viewer setfullscreen function not hiding ubuntu sidebar

I'm building the UI for an application using Qt and QML for Ubuntu Linux. I have a viewer window with a canvas element which is supposed to be fullscreen by default. On opening the application this works fine (i.e. Ubuntu sidebar and top taskbar are hidden). However, once I minimize my application and then maximize it again by using viewer->setFullScreen();, the Ubuntu sidebar and top taskbar are still visible and there is an offset while writing on the canvas due to the same.
Any help would be appreciated.
According to this topic on askubuntu, your problem do really looks like Unity bug (or feature). But, according to somehow related bug on Launchpad, it seems that you can get desired behavior by:
Turn "Always On Top" on via right-clicking the titlebar of your window, before making it go fullscreen.
This will prevent the Unity panel from rendering on top of this fullscreen-window, when using the other screen.
In Qt you can set Qt::WindowStaysOnTopHint to your window/widget via QWidget::windowFlags.
Pay additional attention to notes in official documentation:
This function calls setParent() when changing the flags for a window, causing the widget to be hidden. You must call show() to make the widget visible again.
About Qt::WindowStaysOnTopHint -- Informs the window system that the window should stay on top of all other windows. Note that on some window managers on X11 you also have to pass Qt::X11BypassWindowManagerHint for this flag to work correctly.
Hope this helps.

Flex-AIR: Make application with NO tab in taskbar?

I have an AIR app about half way done right now. I was informed by the client today that he does not want a tab to show up in his task bar. I already have this in place for new windows by making them lightweight. I do not know how to make the main window lightweight though. If there is not a way, is there a work around, like not not having a main window and just opening lightweight windows, don't know how that could be done either though? Anyone know how to do this?
Thanks!
Check this doc out. -- Yes, you can do this. In short, you have to hide the initial window - then display your application in a lightweight window.
Also - do note: On a Mac - the behavior is different. By convention, a window is not shown in the 'task bar' when it is displayed. When it is minimized it is in the bar. To hide the application when minimized on a Mac - you have to make the window 'invisible' instead of minimizing it. The doc mentioned above gives further details.
The key part of the doc for your case:
On the Windows operating system,
windows created with the types utility
or lightweight do not appear on the
taskbar. Invisible windows do not
appear on the taskbar, either.
Because the initial window is
necessarily of type, normal, in order
to create an application without any
windows appearing in the taskbar, you
must either close the inital window or
leave it invisible.
To close all
windows in your application without
terminating the application, set the
autoExit property of the
NativeApplication object to false
before closing the last window. To
simply prevent the intial window from
ever becoming visible, add
false to the
element of the
application descriptor file (and do
not set the visible property to true
or call the activate() method of the
window).
In new windows opened by the
application, set the type property of
the NativeWindowInitOption object
passed to the window constructor to
NativeWindowType.UTILITY or
NativeWindowType.LIGHTWEIGHT.

Resources