Cocoa - How to get started with helping?

[skalogryz]

Thank you!

in the meantime, you want to keep using Carbon IDE - as it is user friendly.
There's no difference with you're using Carbon IDE or Cocoa IDE - the same code is being compiled.

[skalogryz]

TStdButton somewhat a painful subject, due to a certain design restrictions in macOS.

The worst issue is that sizing in Carbon and Cocoa for the button is different. (Replicating Carbon sizing in Cocoa has no benefit)
as of right now there's a restriction on Cocoa StdButton to be have a visual "cap" on height.

You can read more about it here.

Toggle box is could be brought to the similar look though.

[Hansaplast]

I'll admit that I have done a few attempts to work with XCode - but they lost me pretty fast in the different calls in Objective-C and even Swift. So not liking XCode. So I can imagine that you run into some limitations.


Attached the same (1st) project compiled in Windows (32 bit, win32).
Perfect placement, or at least near pixel perfect.
Compiled with Lazarus 1.8.0 (not SVN).

[Hansaplast]

Attached Windows for example2 - again Lazarus 1.8.0 win32.

[Hansaplast]

Took me a while to get my Linux running again (silly updates) ...


Attached example 1 - Linux (Mint 64 bit) Lazarus 1.8.0.1, GTK2 - all looks good.

[Hansaplast]

Attached example 2 - Linux (Mint 64 bit) Lazarus 1.8.0.1, GTK2 - all looks good.

[Hansaplast]

For those interested - the buttons under MacOS Cocoa are a mess.
I never realized that a seemingly weel organized OS has such a mixed bag of buttons (and button limitations).
I found this post a good read: A guide to NSButton styles (not resolving the nightmare though)

[skalogryz]

The issue is not with macOS buttons, but with LCL.

LCL buttons "logic" doesn't match macOS "logic".

for example, all buttons in LCL are expected to be drawn the same - rectangle or roundish.
I.e. StdButton, ToggleBox, BitBtn and even SpeedButton, ultimately should look the same if they only have center aligned button.
All of them have any width and any height.

Ultimately - a developer choses an appealing look and functionality (i.e. one could prefer BitBtn over StdButton, because they allow icons)
and places the button whenever is desired.

For example - placing StdButtons right next to each other (without any margins) look fine in Windows or Linux.

It doesn't apply to macOS. Where PushButton (stdButton), would look rounded with a fixed height.
All other buttons are supplemental buttons and should be used depending on their position on the screen.
(i.e. on the top bar, frame, "metal" frame, search box)

macOS suggest to peek "the use of button" and place it accordingly. (Apple UI Guidelines alway suggest what type of button should be used where and what for). Thus as macOS user interface evolves buttons placed would still look ok.

Placing StdButtons right next to each other look horrible and macOS guidelines discourage doing that.

macOS also impose an API limitation, where a font cannot be modified for a button  (thus all buttons looks the same)
(it seems like it could be by-passed, by using "formatted strings")
where LCL suggests to peek any font for any type of button.

I don't think there's an easy way to map macOS (Cocoa) set of buttons to LCL buttons.
The only option is to choose one approach and stick to it.

One could say that LCL cripples Cocoa - and it's true in some ways.

Later, it might be possible to overcome the limitation by some sort of LCL extensions in order to have more control, over how a certain button would look on a certain system. However it's not yet in the scope.

[Hansaplast]

Thanks for the crystal clear explanation - and what you're saying does make sense.


Would it be an idea (I'm sure you have thought of a lot of "fixes" already) to add a property to TButton/TBitButton saying something like "macOS guide lines" true/false (default: true when developing on a Mac, default false when developing on another platform)?


I've noticed that there are a few other components that have properties that are not available/compatible with other operating systems. Their values can be set, but would be ignored on the platforms where the property doesn't work or makes no sense?


One then could stick with the standard Cocoa push button or choose one of the resizable buttons (that look very different).


This way, developing cross platform, would still work even though it might not look all that great when ported to a Mac. The developer then has the option to choose to stick with Mac guidelines or stick with the same look across platforms.


Also;
Were the screenshot (Windows/Linux) useful?
I can do more testing if you'd like.

[skalogryz]

Were the screenshot (Windows/Linux) useful?
I can do more testing if you'd like.

Yes. The reason I asked for them is because of "Fonts" sections.
Cocoa Fonts sizing technique were recently changed, and I was wondering if results look alike between operating system.

Could you please do the following test.
Assign some (non-default) font to each of those labels. i.e. "Arial" (whatever is available in macOS).
Take a screen shot of how it looks in Carbon IDE.
Then launch Cocoa IDE and take another screen shot.
Then launch TextEdit and try to replicate those text fonts and most importantly selected size there.

What should happen is the font in the application should look like the font in TextEdit.

After that you could the similar test in Windows (using i.e. WordPad)
and Linux (not sure what text editor would be useful there. OpenOffice?)

[skalogryz]

Would it be an idea (I'm sure you have thought of a lot of "fixes" already) to add a property to TButton/TBitButton saying something like "macOS guide lines" true/false (default: true when developing on a Mac, default false when developing on another platform)?

Adding an OS-specific (macOS) property to a cross-platform library (LCL)?

No. If you do that, you're stepping on a slippery path of adding a platform specific properties for every little feature of every OS, that LCL would supports. The code size grows. The maintenance cost grows.

More general solution is needed.
One of the them could be like something like "DisplayStyle: String;"

Yet, it's not good, because it might require a developer to start using a lot of $IFDEFs like this:

Code: Text  [Select][+][-]

1.   Button1.DisplayStyle := {$ifdef COCOA}'PushButton'{$ENDIF}
2.    {$elseif GTK2}'SomeOtherFancyButton'
3.    {$elseif MSWindows}''
4.    {$else}''{$endif};
5.  

Thus a "general" style turns into non-cross platform property.

Maybe "DisplayStyle" should be more flexible, and provide some sort of "scripting" features or CSS-like notation:

Code: Text  [Select][+][-]

1. Button1.DisplayStyle := 'cocoa:PushButton; gtk2: MSCoollButton; windows: MSCoollButton';

That could allow to remove {$ifdefs} from the code.

Yet parsing of such structure might impact run-time.

Actually, some sort of parsing is already happening for button titles.
Button1.Caption:='&Hello World';

Shows as "Hello World" in Windows. With additional functionality to get triggered by pressing Alt+h.
While it is ignored on other systems, and a button caption would look like "Hello World".

I've noticed that there are a few other components that have properties that are not available/compatible with other operating systems. Their values can be set, but would be ignored on the platforms where the property doesn't work or makes no sense?

what are they?

[Hansaplast]

That makes perfect sense, the point of LCL is to work the same on all supported platforms.
I guess Delphi's FireMonkey is trying to do this by drawing the buttons/components themselves - but I'm not a fan of that approach (overhead, performance, inconsistent with the OS in future appearance changes, etc).


Not sure which is worse though, a restricted property (the "Restricted" tab in the object inspector - even a TForm has a few restricted properties), or parsing a string like your &Hello example, or introducing a DisplayStyle property.


As for the restricted properties, in hindsight, I might have been interpreting them wrong way. I guess that it's a regular property, used on all platforms, just with certain restrictions on certain platforms. My bad, sorry about that misunderstanding.


I guess DisplayStyle would of course be a new property for a TButton as well, right?
And then the question of course; how many styles would we like to see for this new property? (ie. fixed height button or a flexible height button under Cocoa).
Would this then have a "OSdefault" style (pick the system default one, so for Cocoa: Pushbutton), an "LCL" style (trying to match the LCL button, even though it's not part of the design guidelines of the OS, so for Cocoa a GradientButton), and maybe others in the future?
OSDefault and LCL would probably look the same under Windows anyway.


The previous implementation where the button style automatically changes when height does not match the default height of a Cocoa button, might be a good way to go after all? Obviously there was a good reason for removing it ... not sure what the reason was though.


Though topic indeed ...

[skalogryz]

I guess DisplayStyle would of course be a new property for a TButton as well, right?

Tbutton, TbitBtn, TEdit, TPassword (maybe)
Pretty much any control that's based on some system-native control could use DisplayStyle

And then the question of course; how many styles would we like to see for this new property? (ie. fixed height button or a flexible height button under Cocoa).

as many as a maintained of the widgetset would like to provide.
It's a system specific field anyway.

Would this then have a "OSdefault" style (pick the system default one, so for Cocoa: Pushbutton), an "LCL" style (trying to match the LCL button, even though it's not part of the design guidelines of the OS, so for Cocoa a GradientButton), and maybe others in the future?
OSDefault and LCL would probably look the same under Windows anyway.

an empty string (or undefined) for DisplyStyle - is "osdefault".
There's no such type as "LCL" type. LCL is osdefault. Where default is dictated by a widgetset implementation.

The previous implementation where the button style automatically changes when height does not match the default height of a Cocoa button, might be a good way to go after all? Obviously there was a good reason for removing it ... not sure what the reason was though.

There's macOS specific problem not to follow this approach.
Carbon and Cocoa metrics were different.

Where Cocoa's "regular" button height is 32, Carbon's "regular" button height is 30.
But for Cocoa this height applies to "small" button size.

Making a button too high or too low (due to the need of writting a cross-platform application), might cause a lousy interface for macOS.

[AlexTP]

Are you Dmitry from commiters? i want to thank you for your commits. for cocoa. many useful cocoa commits in last time. it 's very good because Felipe is not active now for Mac fixes. he says he has new job and no time for mac work.

[skalogryz]

thank you.

he says he has new job and no time for mac work.

I can definitely see how it works.
I'm myself have roughly a weak of available free time, and after that there's a high risk I'll stop working on Cocoa myself.