@Hyperspider-Software

Resizing and moving the window will cause updates, renders and repaints. If everything is done and nothing changes, it doesn't have to get updated at such high rate as it would, when you grab the window and move it around and change dimensions of the content.
Just a guess. Maybe it might be helpful if you show some code, how the window is rendered.
Is it just one window or does everything behave like this?

Well, Qt does not provide these capabilities. This means that you cannot easily use stylesheets for this purpose. However, there might be OS-specific ways to change the color of the title bar. On Windows (10 and later) you can use DwmSetWindowAttribute to enable dark mode for the title bar. Another way is to get a window without decoration/borders from the OS and then draw the entire title bar yourself using Qt. Then, you can also style the title bar using stylesheets. It might get a little complicated to draw the close and minimize buttons in the correct OS style yourself.

@Uchi
Correct! At the time the connect() statement is issued both the signal & slot objects must be set to the instances to be connected, that's what connect() does. Changing either of the objects later to an instance has no effect on the earlier connect().

@new-qt_user-2022 All the best! Feel free to post new questions if you'd like further help.

Then it's trivial. Look at the main function of B, it will probably instantiate a main widget, you can use that as a child widget of your application

Use QScreen::availableGeometry. It provides the geometry excluding window manager reserved areas.

@Pl45m4 I thought as much. As to the question how the app should know: Well, the window manager knows, and Qt should be my adapter to the system's window manager. But I do agree that it's something one doesn't need very often.

I've now implemented a workaround: I've subclassed the QQuickView and connect a slot to the following signals:

QWindow::xChanged() QWindow::yChanged() QWindow::widthChanged() QWindow::heightChanged()

In the slot, I first check if the window is in maximized state. If not, I store the current window geometry.
When persisting the window state, I store the geometry stored in this subclass, not the one returned by QWindow::geometry().

When I restore, I can first set the geometry and then open it in maximized state. When I now unmaximize it, I get desired geometry.

In any case, thanks for helping me out and confirming that this cannot be accessed directly through Qt's interface.

Omg, I've just ORed the flags, and now it works as intended.
In QtWidgets it should be:

// To set the window minimized setWindowState(windowState() & ~Qt::WindowActive | Qt::WindowMinimized); // To restore the window from minimized state setWindowState(windowState() & ~Qt::WindowMinimized | Qt::WindowActive);

So in QML it should work in the same way.

I finally found a solution which seems to work in my case. I added the Qt.MSWindowsFixedSizeDialogHint window flag, which seems to fix the issue.

So below is the modified code:

ApplicationWindow { // common properties id: awMainForm width: 602 height: 728 flags: Qt.Window | Qt.FramelessWindowHint | Qt.MSWindowsFixedSizeDialogHint visible: true // form content isn't relevant ... }

@J-Hilk said in How to get ALL the keyboard pressed keys WITHOUT RESTRICTION OR FILTER?:

Inside main.cpp install an eventfilter on the Q(GUI)Application

Thank you very much, this was exactly what I needed!

@texasRanger said in Multiple UI windows??:

Solved here:
https://forum.qt.io/topic/99477/multiwindow-in-qml-proof-of-concept/7

The solution in this post is unnecessarily complicated.

In your question about them being blank I don't understand what you are doing

//main.qml QtObject { property Window window1: Window { visible: true // ... } } //FirstForm window1 { //UI formating }

How are those two related?

Why not do this?

//main.qml QtObject { property Window window1: Window { visible: true // ... FirstForm { anchors.fill: parent } } }

Oh, yep, with this explaination is more clear. Thank you a lot ^^

Solved, overrode the standard event() and just used event.type() == QEvent::hovermove to get what I needed.

@morte

ApplicationWindow { Item { id: banner x: 0; y: 0 width: parent width; height: 50 } Item { id: content width: parent.width anchors { top: banner.bottom bottom: parent.bottom } } }

@wangfys
I got exactly the same behavior as you. Although I never used the scene graph before, your example (+ the doc and the Custom Geometry example in Qt's examples) gave me a little crash course in the topic.
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html

Your example really should work as it seems you did everything as required by the doc. At my side, the lines become visible once I hover the mouse one the exit button. Possibly this is a bug?

PS. Again, not being useful, I maybe I could suggest you to change the definition of your points from QVariantList points; to QVector<QPointF> points;

Then you can use:

const float x = static_cast<float>(points[i].x()); const float y = static_cast<float>(points[i].y()); vertices[i].set(x, y);

rather than

vertices[i].set(points[i].toPointF().x(), points[i].toPointF().y());

as it saves you a couple of calls to toPointF().