-
Notifications
You must be signed in to change notification settings - Fork 202
Frameless examples without acrylic #48
Comments
Ok, so I took the time to inherit my |
I only changed the way of how the window blur, the frameless part is not touched except for some cleanups. But I did change the way of how to make a window frameless last year. I added a simple class called
Well, the If you only want to make a window frameless and don't need the acrylic background, it's not necessary to inherit from QtAcrylicWidget, just call |
I can add it back, if you wish me to do this.
Of course, as what I said above, the frameless code is not changed. If it works before, it will continue working.
FramelessWindowsManager won't do anything except making windows frameless. The window frame is draw either by qtacryliceffecthelper or the user himself.
The QtAcrylicWidget is just finished and I haven't test put some complex controls on it. But I'm busy dealing with the Acrylic background these days, so I do not have time to try this use case. Do you have any snapshots of this issue? Can you paste them here? |
I guess you don't need the Acrylic background. Then what about just use FramelessWindowsMananger to make the window frameless and draw the colored window frame manually in paintEvent? Will that help? |
This is what I did but ended up with the issues describes in my first post.
Not so easy to handle the frame color, maximized state, etc. Why reinvent the wheel if everything is already in QtAcrylicWidget. |
I remember you provided a small trick to make it work with QMainWindow, you just need to use that again. I need to repeat this again: I didn't change the frameless code, I only changed the way of how the window blur. What works before should also continue to work now.
Yes, you'll have to handle all those things manually if you want to draw the window frame yourself. It's quite annoying indeed.
Because currently QtAcrylicWidget will draw the acrylic background unconditionally. I'm not sure whether you want it. You can disable the acrylic background by commenting the |
QtAcrylicWidget will only draw the frame of itself. If you want all widgets have custom frame, maybe it can't be done in this way. Subclass QStyle and draw the frame in it may work. |
QtAcrylicWidget is a subclass of QWidget, not QMainWindow, I remember you told me the QDockWidget won't work under normal QWidgets, you must inherit from QMainWindow to let it work. And the snapshot you pasted here is much more complicated than the mainwindow example I removed, is it an improved version? |
Yeah I can see it from your snapshot, but currently I have no clue about it. |
It seems the frameless QMainWindow should be one pixel bigger in order to match the normal mode and avoid QDockWidget or QToolbars overlapping the frame |
Sorry, I'm not familiar with QStyle and its usage. I just know you can customize a widget's look and feel by implementing your own style.
OK, that makes sense.
Sure, I want to add it to the official examples if you allow me to do this.
Looks like we need to set some kind of contents margins to leave enough space for the window frame. What do you think? |
Should the window be bigger or the content need to be smaller? I think the latter is easier to achieve. |
I think the window should be bigger, but if you can explain how I can make the content smaller, let me know. |
I have just read QMainWindow's source code. It's inherited from QWidget as well. I'm going to figure out how to make a QWidget work with QDockWidgets. |
This is a simple QMainWindow demo developed by me. The green area is the menu bar, the yellow area is the status bar. From the snapshot we can see there's a large space between the widgets and the window frame. I just call |
The above comment is my answer. |
Sadly QMainWindow is using a special home-made layout to do all the things, its source code may be thousands of lines. And it's a private helper class, not accessiable from outside. Maybe this is not a good way to explore. |
A small hint: if you are using QtAcrylicWidget or QtAcrylicEffectHelper to draw the window frame, the window frame will always be drawn in device pixel, it will always be 1px no matter what the DPI is, this is also the standard behavior of Windows. But Qt will scale your margin automatically, so actually you should do something like this: // In Qt5, devicePixelRatio() will round dpr to integer.
// From Qt6 these two functions are the same.
const qreal m = 1.0 / devicePixelRatioF();
setContentsMargins(m, m, m, m); But the frame thickness can be changed by calling |
You can have a look at my branch https://github.com/JulienMaille/framelesshelper/tree/qmainwindow |
Thanks! I'll add it to the official examples of this repo. |
RIght now you can't, I dirty hacked |
QObject doesn't support template indeed. But QtAcrylicWidget is only a thin wrapper of QtAcrylicEffectHelper, you can write a QtAcrylicMainWindow as well. Maybe you can just copy QtAcrylicWidget and rename the class name. |
Yes I could copy paste in a new class but that sounds dirty. |
@wangwenx190 Do you want me to duplicate |
I think it's fine, there's no better way anyway. We can improve it if we find some better way in the future. |
Once it's done, I think your QMainWindow exmaple can be merged as well. |
Can I do this with just 2 |
Of course. just call them as early as you can. |
Looks like the |
also after playing with environment variable, the blur doesn't show all the weird bugs it had before (when resizing) and it shows the windows behind, not just the wallpaper. I'm not sure why I all those issues before, when looking at windows env vars, I can't find anything related |
That sounds weird! I think it's impossible. Do you have any clue?
Previously I was trying to switch between DWM blur and wallpaper blur dynamically, but I uploaded new code without testing. It turns out that the code is not working and is causing strange behavior. I removed these code in the next commit. Maybe this is what you observed. It's not related to the env vars indeed. |
@wangwenx190 can you show (maybe try first) how I can test the acrylic blur with qputenv(_flh_global::_flh_acrylic_forceDisableWallpaperBlur_flag, "True");
qputenv(_flh_global::_flh_acrylic_forceEnableOfficialMSWin10AcrylicBlur_flag, "True"); |
Yes, I've just tried. It doesn't work indeed. For now I have no clue. It's weired. I'll investigate. |
It did work 13days ago when you told me to try it. Must have been broken by a recent commit |
The acrylic background looks normal when using the wallpaper blur mode, however, it looks weired when using traditional DWM blur. The background is not transparent at all. |
Yes, but it used to work fine, just a week or two ago! |
It may worked on your side some time ago. But from my side, it has this issue since it's first merged into master branch. I've checked the commit history within recent two weeks, it seems no critical changes were made. |
Weird! Don't we need a |
I've just tried, it doesn't help. And it's not needed actually. We don't use it in QtAcrylicWidget either. |
I've figured out how to solve this strange issue. You need to subclass |
Do you have time to fix this issue? I'm quite busy with another open source project these days, I can fix it of course, but maybe some later time. |
Yes I will try to fix it |
Thanks! Then all the code in main() can be moved into its own ctor function. |
Well, with every update, it is getting more and more complex to understand how the acrylic behaves. Actually I think it stopped working when you removed This will fix it: void QtAcrylicMainWindow::showEvent(QShowEvent *event)
{
QMainWindow::showEvent(event);
updateContentMargin();
if (!m_inited) {
m_acrylicHelper.install(windowHandle());
m_acrylicHelper.updateAcrylicBrush(tintColor());
Utilities::setBlurEffectEnabled(windowHandle(), m_acrylicEnabled); // <---- HERE
connect(&m_acrylicHelper, &QtAcrylicEffectHelper::needsRepaint, this, qOverload<>(&QtAcrylicMainWindow::update));
m_inited = true;
}
} |
Now for the bonus part: the resulting exe does not lag when moving nor resizing on Win10 Build 21343 🎉 |
I'm really sorry for it. It's becoming more and more complex indeed. Maybe I should move the Acrylic-related things to a separate repo.
Yes, that's the reason.
That's really a good news! But since we are supporting two different blur modes, are you sure you are using the real acrylic blur provided by MS? |
For this version, is it a insider build? Does it have an official name like "1809" or "20H1"? Is it the first version that fixes the laggying bug? |
I've pushed new code. The mainwindow issue is now solved. |
|
The insider has no special name, sorry. framelesshelper/qtacrylicmainwindow.cpp Lines 148 to 151 in 95d7299
|
Thanks, but it's not needed now since it's a developer build.
The homemade blur comes from a commercial component, it has these lines, I'm not sure what's the exact usage of them, so I don't remove them for safe. |
I'm going to separate the frameless code and acrylic blur code within few days. This repo will only contain the frameless helper code. |
Hi, please check this repo: https://github.com/wangwenx190/qtacrylicmaterial |
I know you are quite busy finding a solution for the acrylic background.
However I think the initial target of this repo was to get a working frameless mainwindow, and I'm kinda lost how to do this with latest code.
I had a working toy project using the code from around November 2020 I think. My problem at that time was that I couldn't draw the 1pixel frame around my QMainWindow.
So I decided to update to the latest code (and also tried some commit in between) but I end up with unmovable window, graphical glitches, and still no frame.
Do you plan to restore the
QMainWindow
example I had contributed to? Does it still work on your side?Is
QtAcrylicWidget
in charge of drawing the coloured frame? Or is it a feature ofFramelessWindowsManager
?The text was updated successfully, but these errors were encountered: