@JonB
@JoeCFD

OK found that Wayland just doesn't allow to windows to move themselves.

Not a necessary feature for me and can't solve the black screen problem when logging with Xorg.
Will just ask gnome to center new windows with tweaks.

Closing the topic.

Thanks to both you.

@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.

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 ... }

@JonB
I am passing to QML for this reason. There, placement and dimensioning of graph oblect is very easy to do. I like also the stong division between frontend a nd backend!!!

@Wieland I was afraid of that. Seems like a glaring omission. Oh well, I needed to download the sources anyway to peek at Scene3D. Thanks.

Well seems that it needs to emit model's layoutChanged() to do what I need. I created new class which inherits QListWidget and there I connected signal to layoutChanged signal of model() object and it worked.

Yes i did.

And with that clue i figured it out! QApplication::desktop()->screenGeometry(screenIndex); works like a charm.
Tyvm!

Hi and welcome to devnet,

Are you trying to modify the geometry of your main widget on iOS ?

@mrjj Yes. For this test case, I believe it would be setSizePolicy(QSizePolicy::MinimumExpanding, QSizePolicy::Expanding), but it does not work.

There's a Qt Canvas 3D module in Qt 5.5 that provides WebGL-like interface to hardware accelerated 3D. It is layered on top of existing Qt's OpenGL support.
As for non-QML stuff, on WinRT Qt uses ANGLE, so if you stick to functions provided by Qt (e.g. QOpenGLFunctions) and not try to talk to the driver directly it should work just fine cross-platform.

Well yes, but you're painting that color with alpha over whatever widget is under the button, since the event filter is called before paint event of the button and you return true from it so the button's paint event is never actually called. To see the button painted underneath you need to actually call the paint event of the button manually before you overpaint it with your color.

Unrelated comments:

You seem to have a very bad habit of just casting types with a C cast to whatever you think you need at the moment. I'm referring to the QWidget *widget = (QWidget *)object; cast in the eventFilter. If I used any non-widget QObject derived type with your class it would compile successfully and crash at runtime. There's a isWidgetType() method on a QObject that you can test with before casting. Also please don't use C style casts. It's just plain evil and you will cause bugs with it. Either to yourself or other people that use your classes. There's a lot safer qobject_cast for QObject derived types that will return nullptr that you can test for if the type can't be cast.

Painting in response to a timer with interval of 10ms makes no sense on almost any of user's machines. The typical display is ticking at 60Hz (i.e. little over 16ms) so anything lower than that is just giving Qt more work in filtering out the update requests you are flooding it with. Displays with a higher refresh rate are still very rare and even on them there's not gonna be a noticeable difference if you stick to 60Hz animation.

Using == operator on a floating point numbers is on borderline of being a bug. You should practically never do that unless you're actually testing floating number stability, which is like super rare. Use non-strict comparisons (< and >) or just stick to fixed point integers for steps like that.

Well I might have not been entirely truthful saying a layout has no size. After all it is a QLayoutItem and, as you pointed out, it has a setGeometry method. What I should have said is you shouldn't think about a layout in these terms.
There is rarely a case where you would manipulate a size of a layout directly or care about it at all, unless you're for example implementing your own layout, which is rare. You either change the size of the parent or the children and the layout with its (let's call it "virtual") size is a sort of bookkeeping mean to calculate the dependencies of parent and children. You can think of it as sorta "the magic that needs to happen", but I personally treat it as a publicly documented implementation detail :)