On Wed, 2 Oct 2024 12:50:11 +0000 Morten Sørvig via Development <development@qt-project.org> wrote:
> Yep, so it depends on the point of view: is the rounding API for > controlling a particular part of the Qt implementation, or for > declaring application intent with regards to support for fractional > scale factors. Now made relevant by recent changes to the Wayland > platform. > > I think we need the following: > > 1) a proposal for getting to the current state to the new state (a > QTBUG Task, or similar) > > 2) a consensus that we do want to expand the usage of the > RoundingPolicy etc APIs > > As you can see from my previous reply and replies on gerrit I’m not > completely convinced myself, but if there is a consensus in the Qt > maintainer group that this is something we want to do then let’s go > ahead. Oof... I haven't ever created a QTBUG Task... Should it have something special or just describe the problem as usual (as in bug report/feature request)? > I think applications which have their own scaling engine wold be > quite small subset of all Qt apps? That use case could be supported > but we should keep in mind that the majority of apps will rely on > functionality provided by Qt and the native platform. I believe it's quite a large subset of applications setting rounding policy. It's not a rocket science after all: divide screen's logicalDotsPerInch by 96 or 72 and multiply all the sizes/drawing by the resulting factor. Qt had hidpi support opt-in and of quite a bad quality for all Qt 5 time while the need to support hidpi was present all that time so people were doing it the way they can. GitHub shows quite a lot of results for logicalDotsPerInch as I was mentioning earlier. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
