Borderless Window on Windows (almost have it working)
-
@ambershark It looks like this:
That's using only C++ and Qt widgets (no QML). Both this and the QML version were based on the implementation found in this github repo. This is clearly doable, but it seems Qt is making assumptions about the geometry.
If you notice, that repo has this blurb at the bottom:
What this example does not do: Draw anything to the client area. You will need to fill the entire window with an opaque color, or the window frame may be visible inside your client area in borderless mode. In my use case I simply fill the D3D backbuffer covering the window's client area.
I suspect there may be a way to hack around this without modifying Qt, but I'm not sure.
In the case of QML, the OpenGL context is clearly filling the window (take a look at my first post, notice how the entire window is aqua). That aqua is all from OpenGL so its clearly filling the window. Why the purple bar doesn't appear in the correct position must be due to the QML implementation making geometry assumptions.
I'm curious if Qt will ever officially support a borderless window. I've never dug into the Qt implementation before. I wonder where the changes would be needed...
-
@Henry_S I think the problem is supporting it in all the platforms. It's doable in windows, but not necessarily doable in other platforms.
As for making a borderless window I would have to play around with it. It isn't something I could do off the top of my head. I am 95% linux/osx coder these days. I haven't coded outside Qt for windows since like 2001. So I'm a tad rusty. ;)
I'm curious though so I might play with the idea later this weekend if I have time.
-
Did you find any solution?
@Henry_S -
That nativeEvent handling to report faked window size seems fishy.
Setting Qt::FramelessWindowHint flag should be enough and has worked for me in Linux desktops.
Maybe faking window size with nativeEvent handling causes QQuickWindow scenegraph/surface/whatever to still use real size which maps QQuickWindow contentItem to position with frame -
Yeah just using
Window { flags: Qt.FramelessWindowHint }is enough, no need to subclassQQuickWindow. -
I have made sample template project about this topic!
Have a look :)
https://github.com/tongmon/qt-frameless-windows -
@Pl45m4 I don't see that it is necessarily a problem if something new is being added to the thread.
Even though I keep an eye on this site anyway, I often also end up here via Google searches when I am stuck on something. At that point I am not particularly concerned about whether a thread has been revived at some point - I just want to get some information from it.
Given the general lack of activity on this site I would rather encourage people to contribute than criticise them for doing so.
-
Reviving "dead" / old topics is even a reason to get banned in other places :)
That's why there is the option to "close" resolved topics, so nobody else can comment further on them.
(which is not used here... mods can lock or delete topics in this forum)If people have similar issues as mentioned in old, existing threads which they found via google and they keep commenting on these topics, they get longer and longer until nobody will understand what the main issue was/is. Nobody reads through all posts from like 10 years ago again. Especially when all the new comments are just like "I have the same issue" without any more information. The chance that everything is really the same, is pretty low... Platform(s), involved hardware and also the software version are probably not the same as 5, 10 or 15 years ago...
So even if it appears to be the same issue due to some error message, your problem still can be somewhat unique. Therefore better create your own, fresh topic where you describe your current issue.Unless the “old” topic is only a few weeks old. Then you could possibly discuss the same problem. But not for topics that are like 5 years or older.
