|
|
|
|
|
Guys, I read 0031037, which actually I found: https://forum.lazarus.freepascal.org/index.php/topic,34896.0.html Thanks to Alextp and the other devs... I am doing cross-platform software: Vista_32/Delphi->Vista_32/Lazarus->Win10_64/Lazarus->macOS_Carbon (and NOW macOS_Cocoa)... Actually, (till NOW) I solved the issue for my software, with the following code for the main form: {$IFDEF FPC} ScreenInfo.PixelsPerInchX:=96; ScreenInfo.PixelsPerInchY:=96; {$ENDIF} But NOW I found the reported difference, which is not too big, but I found it and please, do not rely on this -> there is something. I built my software with and without the solution above, but I found no change. 1. Can I continue use my solution after your intervention? 2. Do you have idea what causes this difference? 3. Do you know some workaround? Best Regards, |
|
|
With Cocoa, some native widgets are drawn at a specific size, so a TButton will have a fixed height on Cocoa regardless of what height or scaling you request. The benefit of this approach is you are using the native widgets, and these widgets appear identical to other native Mac applications (style consistency). If this is unacceptable, you may want to choose a themed widget (like tspeedbutton) instead: this may make your applications appear more similar between Linux/Windows/Mac at the cost of looking alien in MacOS. The Font size difference between Cocoa and Carbon is described here http://wiki.lazarus.freepascal.org/Cocoa_Internals/Canvas A good resource is here http://wiki.lazarus.freepascal.org/Cocoa_Internals/Buttons For a cross-platform project, you may want to examine your auto-size anchor options http://wiki.freepascal.org/Anchor_Sides http://wiki.freepascal.org/Autosize_/_Layout |
|
|
With this set, on both Carbon and Cocoa: {$IFDEF FPC} ScreenInfo.PixelsPerInchX:=96; ScreenInfo.PixelsPerInchY:=96; {$ENDIF} On Carbon the Font Size is 12, but on Cocoa the Font Size is 16 - looking in the Font dialogs. As I already said the Fonts look nearly the same, but they are not (12 vs 16). You can reset the Font Sizes to be equal (to 12), but then the visual difference is big. When remove the condition on Cocoa: {$IFDEF FPC} //ScreenInfo.PixelsPerInchX:=96; //ScreenInfo.PixelsPerInchY:=96; {$ENDIF} The observations are the same. |
|
|
Is the last provided info useful? Do you plan to fix this? |
|
|
Guys, Again, on this issue... The problem is not in Carbon as you describe in the documentation (above), or we talk for different/ more problems. I think that because, as I already said: I found the DPI problem (above) and I do intensive cross-platform development and in CARBON the things behave more like in Windows (ws)... The issue appears on COCOA mainly when on assigning Font (or Font properties) and for the same thing (for example a TLabel component) the input differs from the output: the read Font.size value differs from the written one. This does not appear for Carbon. Please, take attention on this. I do not know where is exactly the problem in Cocoa ws in Lazarus or Cocoa macOS. Best Regards |
|
|
Addition: the diff between the read and the write Font.size value (ex.: TLabel) appears after reading the value in the Font dialog/ after open the Font dialog in runtime (ex.: for TLabel) (and it appears with sign "-" if you print it). |
|
|
forms.png (26,465 bytes) |
|
|
I've attached a screenshot from Cocoa, Carbon and Windows. Could you please explain in details - your concern. Cocoa and Carbon look alike to me. Yes, the "font" for label is different (but this is due to different APIs used to get "system default" font) macOS systems vs Windows look different, is likely due to different DPI (96) (PPI 72) used. |
|
|
Hi, Dmitry, Thank you for your attention. The difference in Font representation is small and as I already described above is not the problem. The problem is that for the same component TLabel with Font.size = 12 (pt) on Carbon Font dialog opened for the TLabel to get/set shows size 12, but on Cocoa - 16 and when you try to set it to 12 the difference is big - its as first. The second is that in case that you just open a Font dialog for a TLabel, just to get/ see the size value, but even do not try to set it and next to print the Font.size for that TLabel the printed value is with sign minus, which is not correct - and this is on Cocoa only. Those are my concerns: I extensively work with the Font dialog to read/get and write/set the Font.size values and to write and read them to/from a file. Thank you, Dmitry, Best Regards |
|
|
if Font dialog is the issue, then it certainty can be be. could you please provide an example? preferably with screen shots, indicating the difference between Carbon and Cocoa. |
|
|
Today I will prepare an example... I thought the same that the problem is in the Font dialog, but that I saw in the code, it just uses Font.Assign() for the SET and in Font (classes hierarchy) the .size and the .height props are set with formula, taking in account the DPIs, from where the sign MINUS appears for the .size (I am not compared the diffs between Carbon Font (classes) and Cocoa Font (classes), but it is like the .height value is assigning to the .size OR vice versa, or the DPI params are swapped... |
|
|
|
|
|
1.png (210,791 bytes) |
|
|
2.png (221,731 bytes) |
|
|
See the attachments on Cocoa: On Carbon (compiled on Laz 1.8.4) FontDialog get/ set the correct values. |
|
|
Dmitry, do you need additional info? |
|
|
Merry Cristmas and Happy new year! |
|
|
Merry Christmas! I'm afraid there's no movement in the area to resolve ppi conflict between nacOS and LCL |
|
|
Your description of issue is vague, I dont understand what is the issue. Attach simple demo with source to show the problem, it must differ on Carbon/ Cocoa. |
|
|
The problem is with system font dialog sizes not matching the ones assigned by LCL |
|
|
please test and close if ok |
|
|
I wish you a very happy new year, Dmitry! I tested it on 62536 and it seems OK. The Cocoa WS status seems pretty good, when is planed to be officially released as stable? |
|
|
OK |
|
|
yes, the fix is already scheduled for the next release |
- Anonymous
