View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0034625||Lazarus||Widgetset||public||2018-11-30 18:06||2018-12-01 18:53|
|Reporter||Zeljan Rikalo||Assigned To||Zeljan Rikalo|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Product Version||Product Build|
|Target Version||Fixed in Version|
|Summary||0034625: Qt/Qt5: Wrong PPI calculation on Mac after r57679|
|Description||Mac only: in revision r57679 specific DARWIN code is moved from application.inc to the carbon and cocoa widgetsets, but not for qt/qt5 which are supported for darwin targets too.|
|Tags||No tags attached.|
|Fixed in Revision||r59708,r59709,r59711|
See my email from 2018-04-20 "Mac (Cocoa) DPI 72 or 96"
On 20.04.2018 5:30, Ondrej Pokorny wrote:
> On 20.04.2018 4:07, Dmitry Boyarintsev wrote:
>> Btw, comment #99128 https://bugs.freepascal.org/view.php?id=31037#c99128 also needs to be enforced.
> See my comments below, especially https://bugs.freepascal.org/view.php?id=31037#c99171
> But if you all want to move the IFDEF to the widgetset code, I'll do that. But remember that we can't get rid of the IFDEF - it will appear at least in LCL-Qt because it is not a widgetset problem but OS problem.
I see you moved the 96 PPI from TApplication.Initialize to the widgetsets. OK.
BUT do not forget about Qt and Qt5 widgetsets - they are valid widgetsets for the Mac as well. And they both return 72 PPI on Mac now.
Gtk2 will probably have the same issue on Mac, but I cannot check, I haven't installed it.
||I've moved that part to Qt/Qt5 and it's fine now, but treeview drawing is bad in that case. When Qt was on 72 contols were upscaled to 96 and fonts of handles were bigger. Now have problem with treeview (see issue 34461).|
||While trying to fix it somehow, I'm wondering why we don't have an const eg DefaultOSDPI in LCLType and use such const instead of hardcoded number 96|
||And the "96" even is in function names: TControl.Scale96ToForm, .Scale96ToFont, .Scale96ToScreen and their reverse .ScaleFormTo96 etc.|
> While trying to fix it somehow, I'm wondering why we don't have an const eg DefaultOSDPI in LCLType and use such const instead of hardcoded number 96
It's been discussed several times on the Lazarus Dev mailing list. It would be a valid design pattern as well.
There is 1 advantage I remember: The font size/height ratio is now always the same on all OS/WS at 100% scaling. (In Lazarus 1.6 it was different between Mac and other OS.)
The current state (96 PPI = 100%) is also easier to handle and understand for the end-programmer.
||Additional fix needed in TQtWidgetSet.InitStockFont()|
||Finally qt4 is resolved too.|
||Works fine now.|
|2018-11-30 18:06||Zeljan Rikalo||New Issue|
|2018-11-30 18:07||Zeljan Rikalo||Assigned To||=> Zeljan Rikalo|
|2018-11-30 18:07||Zeljan Rikalo||Status||new => assigned|
|2018-11-30 18:12||Zeljan Rikalo||Fixed in Revision||=> r59708|
|2018-11-30 18:12||Zeljan Rikalo||Status||assigned => resolved|
|2018-11-30 18:12||Zeljan Rikalo||Resolution||open => fixed|
|2018-11-30 19:18||Zeljan Rikalo||Relationship added||related to 0031037|
|2018-12-01 06:49||Ondrej Pokorny||Note Added: 0112284|
|2018-12-01 09:56||Zeljan Rikalo||Relationship added||related to 0034461|
|2018-12-01 09:58||Zeljan Rikalo||Note Added: 0112285|
|2018-12-01 11:25||Zeljan Rikalo||Note Added: 0112286|
|2018-12-01 12:38||wp||Note Added: 0112289|
|2018-12-01 17:28||Ondrej Pokorny||Note Added: 0112299|
|2018-12-01 17:40||Zeljan Rikalo||Note Added: 0112304|
|2018-12-01 17:40||Zeljan Rikalo||Status||resolved => assigned|
|2018-12-01 17:40||Zeljan Rikalo||Resolution||fixed => reopened|
|2018-12-01 17:40||Zeljan Rikalo||Fixed in Revision||r59708 => r59708,r59709|
|2018-12-01 17:40||Zeljan Rikalo||Status||assigned => resolved|
|2018-12-01 17:40||Zeljan Rikalo||Resolution||reopened => fixed|
|2018-12-01 18:50||Zeljan Rikalo||Status||resolved => acknowledged|
|2018-12-01 18:50||Zeljan Rikalo||Fixed in Revision||r59708,r59709 => r59708,r59709,r59711|
|2018-12-01 18:50||Zeljan Rikalo||Note Added: 0112307|
|2018-12-01 18:50||Zeljan Rikalo||Status||acknowledged => resolved|
|2018-12-01 18:53||Zeljan Rikalo||Note Added: 0112308|
|2018-12-01 18:53||Zeljan Rikalo||Status||resolved => closed|