Open bryce-happel-walton opened 2 days ago
That's bizarre :). The handling of the preferred size should be in the winit backend, independent from the renderers. Am I correct in assuming that you're using Wayland? How exactly do you select the renderers? Do you have a small example for us to reproduce maybe (I have the feeling this is a setup issue).
That's bizarre :). The handling of the preferred size should be in the winit backend, independent from the renderers. Am I correct in assuming that you're using Wayland? How exactly do you select the renderers? Do you have a small example for us to reproduce maybe (I have the feeling this is a setup issue).
Yes, after testing I found this to be a backend issue with the Qt backend rather than the renderer. I have updated the issue. I am using Wayland.
To reproduce just make a window and set the preferred size to be greater than your monitor's size and the window will be resized to be within bounds rather than respecting the preferred size.
@ogoffart I've updated the issue. It is not a femtovg bug.
I believe this might be a duplicate of https://github.com/slint-ui/slint/issues/3847
Are you able to run this Qt program and report what is the size of the window?
#include <QtWidgets>
struct W : QWidget {
QSize sizeHint() const override { return QSize{1920, 720}; }
};
int main(int argc, char**argv) {
QApplication app(argc, argv);
W w;
w.show();
qDebug() << w.size();
return app.exec();
}
For me, it looks like Qt doesn't respect the sizeHint (Qt6.8.0 plasma 6.2.3 x11)
Bug Description
slint/backend-qt
will prefer to keep the window within the monitor's bounds rather than using thepreferred-size
.slint/backend-winit
will use thepreferred-size
(this is the preferred functionality)The live preview uses the
preferred-size
This does not occur with QML/Qt native, so not sure what's happening here.
Reproducible Code (if applicable)
Environment Details
Product Impact
Not a huge deal, but definitely inconvenient.