Lazarus

Programming => Widgetset => Cocoa => Topic started by: Hansaplast on December 25, 2017, 05:48:12 pm

Title: Cocoa - How to get started with helping?
Post by: Hansaplast on December 25, 2017, 05:48:12 pm
Merry Christmas to all ...  :)


I've been using Lazarus for several years now, mostly under MacOS, which limits me to the Carbon widget-set and 32 bit applications.
With Apple's move to 64 bit / Cocoa, I think it's time Lazarus should be doing so as well.
Easier said than done of course, a lot of work still needs to be done, and a lot of work has already been done on the Cocoa widget-set (all respect for that!).


Note worthy is the very awesome bounty placed by Herman (see this bounty (http://wiki.lazarus.freepascal.org/Bounties#Cocoa_bounties) and this forum post (https://forum.lazarus.freepascal.org/index.php?topic=39117.0))
I'd be more than happy to chip in financially, but I'm just an amateur developer and my pockets are not very deep.


Since I'm no expert developer (I just do this for fun), I was wondering how we (Mac users) can do to help in other ways.
Obviously there is the bug reporting, but with the current state of Cocoa I do not even know where to begin since almost every visual component is placed incorrectly on a form. So should I list all the affected visual components in a bug report?


Just a few things I've tested:


1) Compile the IDE with the Cocoa widget set.


I'm aware that, since Cocoa in in Alpha stage, this will be problematic - so what I'm seeing is as expected.
When compiling with Cocoa and 64 bit, compilation simply fails (make clean all).


Code: Pascal  [Select][+][-]
  1. lazarus.pp(57,3) Fatal: Cannot find Interfaces used by Lazarus, incompatible ppu=/Users/hans/freepascal/lazarus/lcl/units/x86_64-darwin/cocoa/interfaces.ppu, package LCL


When leaving the CPU target to default (i386 I presume) however the IDE does compile ... well, after I install Quartz (https://www.xquartz.org/) since for some reason the linker seems to require a X11 library.


After installing Quartz (still confused why this is needed) the IDE compiles fine, but starts with a few problems:
2) Compiling applications with 64bit and Cocoa.


When compiling applications, with a Carbon IDE, the biggest hurdle is that the form doesn't come out as designed. Pretty much every visual component looks different and seems placed different than designed.
Designing a form with the IDE compiled with Cocoa will compile in the same looking result but ... it's very challenging to place and move components on the form, and when moving the code to another platform (for example Windows) things become a mess. When comparing Carbon vs Windows vs Linux then the form design is pretty much the same. Cocoa however makes a mess out of it.


Having listed all this, I'm wanting to help a hand, but I'm a little stuck in what to do.
Should I report all misplaced components (in one report or in individual bug reports)?
Should I report that Lazarus seems to need X11 to be able to compile with Cocoa?
Is the missing menu related to X11 or is this a bug?


I'm sure other Mac users are eager to get Cocoa to work. If we work together then maybe we can make some progress ...
Title: Re: Cocoa - How to get started with helping?
Post by: Phil on December 25, 2017, 07:15:21 pm
I'm sure other Mac users are eager to get Cocoa to work. If we work together then maybe we can make some progress ...

I hadn't looked at Lazarus since maybe July of last summer and after seeing your post thought this would be a good time to review where it's at with Mac.

I had no trouble building Lazarus against Cocoa widgetset. Here's the instructions I wrote up last summer in conjunction with the TWebBrowser control:

https://macpgmr.github.io/MacXPlatform/UsingCocoaFromTrunk.html

Cocoa doesn't have anything to do with any X server, so you've got something else going on with your setup. I haven't had an X server installed on my Mac for years. What do you need XQuartz for?

I think some of the problems you're seeing are just Lazarus and the incomplete Cocoa widgetset, not XQuartz. Certainly the IDE built with Cocoa seems worse than it was last summer.

Bug reporting for something like Cocoa in its current state could end up being a black hole, sucking up every available moment of your free time, so maybe just concentrating on bugs that directly affect your apps would be a place to start. I wouldn't bother with trying to use Lazarus itself built against Cocoa. Just use an IDE built against Carbon and then build your apps against Cocoa.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 25, 2017, 09:14:39 pm
Thanks Phil!


I'll follow you instructions to compile the IDE. I have no clue why "ld" was asking for the X11 library, it just did, made no sense to me either.
I did get the the latest from svn trunk (just recompiled it with your instructions and that worked! Thanks!).


As for developing Cocoa apps in a Carbon IDE: for some off reason (and this has been like this for a long time, even along several different Mac's that I have used for Lazarus) the design of a TForm under Carbon gives a very different result when compiled for Cocoa. Components are in the wrong position, different height/width, etc. Quite messy. That's why I was hoping that designing with a Cocoa IDE would make this more workable (obviously not a permanent solution since recompiling it under Windows or Linux requires me to completely reorganize the design).



With this post/question I was hoping I could get something started to get MacOS developers to get more involved as well.
Naturally, if everybody just sits back and waits for a miracle to happen, nothing will get done  :D
(no pun intended to those who actively work on Cocoa and Cocoa bug fixing!)


p.s. when you compiled the IDE with the Cocoa widget set - did you miss the menu as well?
Title: Re: Cocoa - How to get started with helping?
Post by: Phil on December 26, 2017, 05:57:46 pm
As for developing Cocoa apps in a Carbon IDE: for some off reason (and this has been like this for a long time, even along several different Mac's that I have used for Lazarus) the design of a TForm under Carbon gives a very different result when compiled for Cocoa. Components are in the wrong position, different height/width, etc. Quite messy. That's why I was hoping that designing with a Cocoa IDE would make this more workable (obviously not a permanent solution since recompiling it under Windows or Linux requires me to completely reorganize the design).

I don't think I see that problem here, although Carbon is now broken on some controls if you try to change the font and font size (bug reported last spring). All fonts are very tiny with Cocoa. This affects control height in some cases. But alignment is generally okay. Bottom line: Both Carbon and Cocoa widgetsets would be completely useless to me if I were still doing desktop app development.

Maybe post a bug report for this, although it's probably a combination of things that are broken or incomplete.

With this post/question I was hoping I could get something started to get MacOS developers to get more involved as well.

Quite frankly, I doubt if there are very many Mac users of Lazarus left. They've emigrated.

p.s. when you compiled the IDE with the Cocoa widget set - did you miss the menu as well?

Correct, no Lazarus menus at all. That was working last summer.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 26, 2017, 07:41:24 pm
Gentlemen! are there particular examples the Cocoa issues described? with screenshots?
Title: Re: Cocoa - How to get started with helping?
Post by: ChrisR on December 26, 2017, 08:48:46 pm
The Cocoa widgetset has seen rapid strides over the last month - Dmitry has been applying a lot of patches, and Herman has provided strong incentive. To help, I think it is important to
  1.) be on the latest SVN (as of today, Lazarus 1.9.0 56850) -
  2.) Run "svn update" to stay on the latest version -
if SVN updates any files in lcl/interfaces/cocoa/ you will want to delete your /lazarus/lcl/units folder to force the widgetset to be recompiled.
 3.) If you have any problems, report it on
   https://bugs.freepascal.org/my_view_page.php
Make sure you check that you are not reporting a bug that already exists (in the search page, set the "widgetset" to be "cocoa").
 4.) I agree, there have been a few regressions in building the IDE relative to this summer (e.g. menus are missing, scrollbars missing in the source editor), but it does seem to be coming together for smaller projects. These have been reported, e.g. https://bugs.freepascal.org/view.php?id=32424
Title: Re: Cocoa - How to get started with helping?
Post by: Phil on December 26, 2017, 09:04:56 pm
Gentlemen! are there particular examples the Cocoa issues described? with screenshots?

The project included with this bug report from last May illustrates both Carbon and Cocoa problems:

https://bugs.freepascal.org/view.php?id=31912

On Carbon, some fonts are too small. Now on Cocoa all fonts are too small (new problem that wasn't present in May on Cocoa).

Carbon bug reported here is also still present:

https://bugs.freepascal.org/view.php?id=31908

Also, I see a tabbing problem on Cocoa too: jumps two controls instead of only one.

Laz SVN r56850. FPC 3.0.2. OS X 10.11.6 (El Capitan).
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 26, 2017, 09:24:25 pm
Also, I see a tabbing problem on Cocoa too: jumps two controls instead of only one.
very interesting.
Any local changes to cocoa widgetset?
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 02:14:15 am
Running SVN 56852.


When compiling the IDE with Cocoa


- Menu gone (reported in bugtracker)
- Component Window height incorrect (and height can't be changed) - component icons only partially visible (also reported in bugtracker)


Compiled with:


Code: Pascal  [Select][+][-]
  1. make LCL_PLATFORM=cocoa CPU_TARGET=x86_64

Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 03:35:43 am
Gentlemen! are there particular examples the Cocoa issues described? with screenshots?


First off all, all respect for all that do such a great job on Lazarus and Cocoa of course.
I'd be more than happy to provide as much as I can! Thanks for asking!  :)


IDE compiled with Cocoa;


I'd consider this less of an issue if I could develop reliably in a Carbon compiled IDE.
It's kind-a hard to take a screenshot when something doesn't happen, so the first issue (IDE compiled with Cocoa) is that I cannot select items on a form.
- some virtual component cannot be selected at all (buttons - they act like they are working in runtime),
- some components can't be selected (TListbox on a TTabSheet)
- Can't resize components (tried button, TImage, TListbox, TPageControl, TLabel) - can however manually type the values in the object inspector.


Cocoa applications build in a Carbon IDE;


So far the biggest issues seems [/size](design Carbon vs Runtime Cocoa)[/size][size=78%];[/size]
- font size not matching
- PaceControls height does not match
- Aligning something in a PageControl (will test others soon) is going goofy
- buttons height does not change


See screenshot (apologies for the poor JPEG compression - the file was larger than the allowed 250Kb).
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 03:53:38 am
Anchor problem might be PageControl specific, but as you can see in the screenshots, the different button/font/listbox size can make runtime design challenging.


Is this helpful?
I'd be more than happy to do more experiments.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 03:55:31 am
Forgot to mention;


I usually design an application on my Mac (Carbon) and move the code then to Windows and Linux.
I rarely have to change anything form design wise (just when components get real close to ach other).


When designing in Carbon, the Cocoa result is not so great ...
I'm afraid if I start designing in a Cocoa IDE that bringing the code to other platforms will not be good.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 27, 2017, 03:58:13 am
1) awesome samples! could you please share project source?
2) could you also provide  a screenshot of the same projects compiled in Windows (and Linux)?
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 04:12:40 am
Of course! No problem - anything I can do to help.


I'll have to post the code in 2 posts, because of the upload limitations of the forum.


Note: I created these projects in a Carbon IDE targeting 64 bit and Cocoa.
A Cocoa IDE would not even let me create a new project since the menu is gone. Menu gone also means keyboard shortcuts gone  :(
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 04:13:05 am
Second example (less significant)
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 27, 2017, 04:17:13 am
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.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 27, 2017, 04:28:42 am
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 (http://wiki.freepascal.org/Cocoa_Internals/Buttons).

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

Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 04:32:56 am
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).
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 04:42:00 am
Attached Windows for example2 - again Lazarus 1.8.0 win32.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 05:31:17 am
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.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 05:31:42 am

Attached example 2 - Linux (Mint 64 bit) Lazarus 1.8.0.1, GTK2 - all looks good.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 05:45:21 am
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 (https://mackuba.eu/2014/10/06/a-guide-to-nsbutton-styles/) (not resolving the nightmare though)
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 27, 2017, 06:06:36 am
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.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 05:05:05 pm
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.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 27, 2017, 05:35:52 pm
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?)


Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 27, 2017, 05:51:12 pm
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?
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 27, 2017, 07:03:25 pm
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 ...
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 27, 2017, 07:22:00 pm
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.
Title: Re: Cocoa - How to get started with helping?
Post by: AlexTP on December 29, 2017, 10:53:59 am
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.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 02:25:05 pm
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.
Title: Re: Cocoa - How to get started with helping?
Post by: AlexTP on December 29, 2017, 02:38:48 pm
btw. I see strange bug on cocoa- on CudaText. or ATTabs demo. it is strange dark rectangle around tabs, and around x icons of tabs.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 02:46:13 pm
I think you already reported this one and what you're seeing is a regression.

28692: Cocoa: toolbar, icons repaint with black pixels (https://bugs.freepascal.org/view.php?id=28692). This one?

If that's the one, then the regression was caused due to changes made for this issue
32749: Cocoa: Unable to draw on top of JPEG images (https://bugs.freepascal.org/view.php?id=32749).
Title: Re: Cocoa - How to get started with helping?
Post by: AlexTP on December 29, 2017, 04:19:46 pm
not this one, it is another issue only with painting rectangles on canvas (FillRect seems).
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 04:30:55 pm
a stand-alone example would really help
Title: Re: Cocoa - How to get started with helping?
Post by: AlexTP on December 29, 2017, 05:06:21 pm
It exists. download ATTabs repo [online package manager], demo_lazarus shows this bug.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 06:09:06 pm
in that case other bugs takes priority.

an example demonstrating the issue without AT package (LCL only) can boost the priority to the top.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 07:46:57 pm
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?)


I totally overlooked this message - apologies for that.
Did you mean compile the IDE in Carbon and look what the labels look like (with another font) and then compare to the IDE compiled withy Cocoa?
Or did you mean create an application with TLabel and some font; compile it Carbon, then Cocoa? (I'd assume that would do the same?)
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 07:56:31 pm
Just the application itself (no need to recompile IDE)

and then application rendered fonts needs to be compared to the same fonts and size in TextEdit application. (which is a default macOs text processing application)
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 08:42:40 pm
Just the application itself (no need to recompile IDE)

and then application rendered fonts needs to be compared to the same fonts and size in TextEdit application. (which is a default macOs text processing application)


Attached:


- Project file


(screenshots in next posts)
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 08:44:53 pm
Test on the Mac. I've updated Lazarus to the latest SVN version.


The IDE is compiled with Carbon for both screenshots.


1) Compiled the application with Carbon
2) Compiled the application with Cocoa


You can clearly see some size issues in Cocoa.
Note that all TLabels are left aligned, and each "line" has the same "top" value.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 08:45:55 pm
TextEdit. How does it look in TextEdit?
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 08:45:55 pm
Same project compiled under Windows (Windows 10, Lazarus 1.8.0) and Linux (Mint, Lazarus 1.8.0.1).
Both look good.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 09:01:57 pm
TextEdit. How does it look in TextEdit?


The height some how resets in Carbon but not in Cocoa.
Looks like the fonts are OK in a TEdit under Cocoa.


I carefully assume you didn't need Linux/Windows with this. If you do need them; let me know  :)
Title: Re: Cocoa - How to get started with helping?
Post by: Phil on December 29, 2017, 09:02:02 pm
Test on the Mac. I've updated Lazarus to the latest SVN version.


The IDE is compiled with Carbon for both screenshots.


1) Compiled the application with Carbon
2) Compiled the application with Cocoa


You can clearly see some size issues in Cocoa.
Note that all TLabels are left aligned, and each "line" has the same "top" value.

Why are there two screenshots in each .png? What am I missing?

Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 09:03:03 pm
Forgot to include the project files.  :)
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 09:03:47 pm

Why are there two screenshots in each .png? What am I missing?


Top window is the application in runtime, bottom window is design time.
Title: Re: Cocoa - How to get started with helping?
Post by: Phil on December 29, 2017, 09:04:36 pm
TextEdit. How does it look in TextEdit?


The height some how resets in Carbon but not in Cocoa.
Looks like the fonts are OK in a TEdit under Cocoa.

By "TextEdit" he meant the app TextEdit, not the control TEdit. TextEdit will show how the fonts are supposed to look. If Carbon or Cocoa widgetsets can't reproduce that, then they're wrong.

Title: Re: Cocoa - How to get started with helping?
Post by: Phil on December 29, 2017, 09:07:36 pm

Why are there two screenshots in each .png? What am I missing?


Top window is the application in runtime, bottom window is design time.

Got it.

Note that Mac apps never use "Arial" - that's something that Windows apps used to use. Try a common font for Mac apps like Lucida Grande.

Edit: Lucida, not Lucinda (woman's name).
Title: Re: Cocoa - How to get started with helping?
Post by: Phil on December 29, 2017, 09:11:58 pm
Looks like the fonts are OK in a TEdit under Cocoa.

I carefully assume you didn't need Linux/Windows with this. If you do need them; let me know  :)

I would do Windows and Linux too. I believe the fonts are too small in TEdit. Compare Laz 1.8.0 Carbon with Laz 1.6.4 Carbon. I think that's a regression.

See this bug report's example app for various controls that show problems with both Cocoa and Carbon.

https://bugs.freepascal.org/view.php?id=31912
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 09:21:53 pm
By "TextEdit" he meant the app TextEdit, not the control TEdit. TextEdit will show how the fonts are supposed to look. If Carbon or Cocoa widgetsets can't reproduce that, then they're wrong.


I think I need more coffee haha ... thanks Phil, I totally misread that. I'll try again in TextEdit.
Anyhoo ... Cocoa runtime and design time next to TextEdit.
Looks like Carbon, Windows and Linux show the same size amongst each other and in design vs runtime.
Cocoa (the test app and TextEdit) seem to use a different size than those other 3 widgetsets.


Interesting problem. Make Cocoa match the other 3 (so cross platform compiling doesn't become a nightmare designwise) or stick with the Cocoa rules ..  :o
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 09:42:40 pm
Yes. This is exactly what I'm looking for.

Now, the question is - how do you set the label size?
Do you use HEIGHT or SIZE?  - if you're using HEIGHT, please switch to SIZE and repeat the try.

In TextEdit you always set SIZE. (but the size is measured in Points (PT) not Pixles (PX)
Title: Re: Cocoa - How to get started with helping?
Post by: Phil on December 29, 2017, 09:44:44 pm
Interesting problem. Make Cocoa match the other 3 (so cross platform compiling doesn't become a nightmare designwise) or stick with the Cocoa rules ..  :o

Here's example of what I mean about the current regressions and problems in fonts with both Carbon and Cocoa widgetsets.

- Carbon, Laz 1.6.4
- Carbon, Laz SVN
- Cocoa, Laz SVN
- TextEdit

Note how Carbon fonts under previous Laz 1.6.4 matches what's in TextEdit. Carbon SVN now shows some controls small, some like 1.6.4. And Cocoa SVN shows all controls small.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 09:45:10 pm
I had to redo the TLabel test for Linux - I just now noticed that Comic Sans MS and Courier New fonts did not exist on my Linux setup.
So attached; a new TLabel test for Linux and a TEdit test.
I have no easy editor like TextEdit on my Linux setup. The closest I have is LibreOffice but Writer scales the window, so that would not be a correct replication right?
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 09:53:42 pm
Here a screenshot, runtime, design time, and WordPad - not sure how reliable all these rich text editors are.
Wordpad does seem to do scaling as well (default set to 100% - just not sure what they mean with 100% haha).


In all examples I used Font - Size. Not height.
And I'm intentionally not using the font dialog, just manually setting Font - Name and Font - Size.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 10:05:27 pm
Looks like Carbon, Windows and Linux show the same size amongst each other and in design vs runtime.
Cocoa (the test app and TextEdit) seem to use a different size than those other 3 widgetsets.
No.
The screenshot explicitly shows the problem with Carbon font-sizing.
While Cocoa sizing is accurate and is matching to what system would produce.

There test has an issue with "Standard" font.
The default font selected for macOS is not Lucida Grande. It's something else (and it varies from macOS versions as well)

If you look carefully on the screenshot, you might notice the following differences in "standard" font for Cocoa and TextEdit
* number 2 (in 24px) has different shapes
* number 4 is also a slightly different shape
* the space between letters is different
So what you're trying to compare are two completely different fonts.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 10:09:33 pm
Note how Carbon fonts under previous Laz 1.6.4 matches what's in TextEdit. Carbon SVN now shows some controls small, some like 1.6.4. And Cocoa SVN shows all controls small.
would the following test be fine:

* create a form with only 1 standard button on it. Set Height to 32 (will be explained later).
compile for Cocoa and run.
* create a Cocoa Application project in Xcode. Add a PushButton of a Regular Size (for height 32).
Make sure that title match.

Compare the results between Cocoa app and the interface built in Xcode.

Expected results: they should match in look and feel.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 10:16:43 pm
I can see your point on Carbon font sizing being an issue.
Not sure (yet) how this translates to Windows and Linux (when moving code from platform to another), but maybe that's a worry for later.


I can create a project in Lazarus and XCode if you'd like.
So the button has to have height set to 32? Or did you mean the font size of the button?
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 10:18:09 pm
I can create a project in Lazarus and XCode if you'd like.
So the button has to have height set to 32? Or did you mean the font size of the button?
32 should be height of the button.

But!!! if you find the way to change font of the button in Xcode in design time, please let me know ;)

Not sure (yet) how this translates to Windows and Linux (when moving code from platform to another), but maybe that's a worry for later.
At this point, I want to make sure that a widgetset renders
Font X with Size Y (in points)
in exactly the same manner, as a system text editor with
Font X with Size Y (in points)
selected.

That is a measurement for a widgetset to render a font properly.

If we assume that Carbon-WS is correct, and Cocoa-WS should render the font in same manner, then we're actually bringing Carbon-WS bug into Cocoa-WS. And I'd like to avoid that, taking system font rendering as a standard

Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 10:28:03 pm
Hahah, the minute you wrote your reply, I already noticed the font size problem with XCode and design time hahah.


So, the PushButton has a fixed height, and in designtime the fontsize doesn't show - as you expected.
Funny thing though ... during runtime it DOES show a different font size.


In the XCode screenshot (let me know what you'd like me to change):


On the left: runtime. On the right: design time.
Top button is a gradient button (which can be resized, and height set to 32), the button at the bottom is a Push button.
Font is in both cases set to 32.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 10:32:53 pm
There's no need to change font size to 32.

We're trying to compare 32 height button between LCL and Xcode, with default Font settings.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 10:50:34 pm
Is this what you had in mind?
(maybe minus the Carbon version)
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 29, 2017, 10:59:27 pm
Cocoa-WS font seems to be smaller than Xcode :/
Not good.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 29, 2017, 11:32:49 pm
Not sure how helpful this is, but a few things seem "off" (I matched width and height and tripple checked).
I couldn't find any button with flexible height in XCode except for the gradient one.
I think the fonts are actually the same size, or am I not seeing this right?
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 30, 2017, 01:12:59 am
I think the fonts are actually the same size, or am I not seeing this right?
let's magnify a bit

Xcode on top
LCL at the bottom
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 30, 2017, 01:34:26 am
Allright, I think your name is eagle-eye  ;) ! Anyhoo; you're right!
Let me know what else you'd like me to test.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 30, 2017, 03:54:36 am
Can you figure out why LCL font size is smaller that Xcode’s?
By default is should be identical.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 30, 2017, 04:40:18 pm
I'd love to help figuring this out, but my experience with Cocoa/XCode/Objective-C is pretty much zero. I did do a few attempts to work with Objective-C/Swift and XCode, but XCode is just not the tool for me (that's why I use Lazarus haha).


If you can give me some pointers to get started, I'd be more than happy to toy with it.


Do I understand this right; we want CocoaWS to behave like XCode, and we do not want to try to have Cocoa match Windows/Linux? With the latter I mean; if I design a Form, I'd like it to look comparable between all LCL versions so I can recompile apps with minimal effort on other platforms.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 30, 2017, 05:16:46 pm
If you can give me some pointers to get started, I'd be more than happy to toy with it.
If you look at  TCocoaWSButton.CreateHandle (at CocoaWSStdCtrls)
you should find a suspicious line
Code: [Select]
btn.adjustFontToControlSize:=true;
How does LCL button look like, if you change the value  to false?

Do I understand this right; we want CocoaWS to behave like XCode, and we do not want to try to have Cocoa match Windows/Linux? With the latter I mean; if I design a Form, I'd like it to look comparable between all LCL versions so I can recompile apps with minimal effort on other platforms.
Yes, your understanding is correct.
We're trying to match CocoaWS to native controls look and feel as much as possible.

Yet, the code itself should remain compatible with Windows and Linux.
Design should be as close as possible to Windows and Linux, yet it's understood that some elements might not match.

For example, if buttons are a little bit different? well, that's Apple's fault. (I showed that on the Wiki)
But rectangle controls (i.e. placing a list-box or a memo in a tab-control) should actually match.

And I'm 100% sure, that fonts would always look a little bit different on every platform. Because every platform has its own dirty little tricks on how to render a font.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 30, 2017, 11:07:41 pm
OK I modified line 486 in CocoaWSStdCitrls.pp (class function TCocoaWSButton.CreateHandle) to :


Code: Pascal  [Select][+][-]
  1. btn.adjustFontToControlSize:=false;


And it seemed like there was difference. Then I noticed that the "B" character seemed different.
So I looked in XCode and the font family is called "System" - which I assume is an alias for the actual font (?).
Anyhoo, in Lazarus is simply entered the font name 'System" and ran the test again and noticed that the fonts now look more alike.
See screenshots. Both are with adjustFontToControlSize:=false !

Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 31, 2017, 12:43:16 am
As for the differences in positioning and sizing, I think CocoaWS might need a little fine tuning.
I'm OK with TButton being different - I suppose users could divert to TBitButton inn case they need a little more flexibility.


I'd be happy to test anything you'd like me to test. :D


I've included a screenshot showing another example a positioning issues (obviously not font related).
Not sure if this is to early to mention - just started working on a little project and this is the first thing I ran into ...  :)
I'd be happy to investigate, but I will need a few pointers in the right direction.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 31, 2017, 12:48:53 am
are you referring that client are of TGroupBox is different for Cocoa and Carbon?
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 31, 2017, 03:10:10 am
In this example I'm not anchoring or align anything.
So placing straight forward TGroupBox and place (in this example) a TListBox in it. Resize it so it looks "nice", compile and run.
No alignment, no anchoring except of course the default left and bottom.


So I'm referring to the fact that TListbox (in this example) is placed higher (top) and wider (width) than designed.
Since I cannot design in a Cocoa IDE, one would be depending on a proper/reliable design in Carbon.
If I'd correct the design so it looks OK in runtime, then it would break compiling under Carbon, Windows and Linux - since for those the position and size would be wrong.


I've attached the example project.


Hope that makes sense - apologies if I didn't explain that properly.
And: I'd like to express my appreciation for helping out. I totally understand we all have responsibilities outside of Lazarus time (including myself). So I'm definitely not expecting you, or anyone-else for that matter, to drop everything and spend all their time on these issues - but any help would be welcome  :D
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on December 31, 2017, 04:18:11 am
hmm... can you build an interface in Xcode with groupbox and listbox (actually any other control)
If possible change the color of the embedded control to something different what white (blue or green is the best)

I'm wondering where "top-left" starts in Xcode version of groupbox.

Thoughts: it might be that Carbon-WS metrics doesn't match Cocoa-WS metrics. Thus if Cocoa-WS matches whatever Xcode do - I'm afraid we would stick to it. If Cocoa-WS is showing something completely different OR if Xcode version matches Carbon-WS, then it would clearly indicate a bug in Cocoa-WS.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 31, 2017, 09:35:09 pm
So with XCode (and I haven't done much with it - so I am aNoob when it comes to XCode), the coordinates work different than in Lazarus.
Where in Lazarus (0,0) = top, left corner, in XCode (0,0) means bottom left corner.
Note: I left all default values unless mentioned otherwise for all components in XCode and Lazarus.


In XCode:
I created a form 400 wide and 300 height.


Then I created a "Box" (that's what XCode calls it) - which has
- title = "Title"
- borderstyle = bezel
- width = 360 (planning in 20 space all around the box for easy of calculation)
- height = 260
- left = 20
- bottom = 20 (since XCode flipped the Y axis)
- Box type = primary (there are some options like secondary, old style, custom, etc)


In the box I created a "Scroll view", which has:
- height = 200
- width = 310
- left = 20
- bottom =20
- Under behavior all op the scroll and scrollbar options have been unchecked


The design and runtime appearance are identical (see screenshot).


Note: with all these different options (title, style, bezel, etc) I can imagine this to be very tricky to figure out.


In Lazarus (Carbon IDE - project file attached):
I created a form also 400x300.


I placed a GroupBox;

- title = "Title"
- borderstyle cannot be set
- width = 360
- height = 260
- left = 20
- top = 20 (300 - 260 - 20)
- Box type cannot be set


In the GroupBox I placed a TListBox;
- height = 200
- width = 310
- left = 20
- top =20 (260 - 200 - 20)
- Style = standard



Compiled with CarbonWS: Design and runtime do match.
Compiled with CocoaWS: Design (in Carbon IDE) does not match runtime (top, height and width are off).

Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 31, 2017, 09:41:06 pm
FYI, tested this under Windows as well - just for the fun of it, and here things align correctly (as expected).
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 31, 2017, 09:44:00 pm
Lazarus just reminded me that I had not saved my project. So just to make sure; again the project files (after clicking "Save") ... sorry.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on December 31, 2017, 09:58:00 pm
Not sure if this makes things more confusing or if it's even relevant.
The apparent width of a TListBox is not the same as that of a TShape at design time, but seems a  - suggesting this might be border related.
In the screenshot: Top is TListbox and botton is TShape.
Less visible in this example, but there seems to be a positioning with TShape issue as well.


P.s. You requested using a color in the Xcode example.
I did change the background color of the Scroll view, but that didn't do anything.
For the Box and the form I was unable to find an option to change the color.


Either way - not being sure where everybody is located on planet Earth: Happy New Year for you and your family!  ;)
Title: Re: Cocoa - How to get started with helping?
Post by: AlexTP on December 31, 2017, 11:11:43 pm
Dmitry, i localized bug from ATTabs
https://bugs.freepascal.org/view.php?id=32914
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 01, 2018, 01:19:02 am
Dmitry, i localized bug from ATTabs
https://bugs.freepascal.org/view.php?id=32914
Thank you! That was an easy one.
Pen and Brush colors were turning into different colors within Cocoa-WS.

now the question is - if the resulting color is a correct one. (if it's actual the color set, or a few shades off)
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 01, 2018, 07:52:39 am
2 Hansaplast
the issue seems to be in placing TTabControl under cocoa-ws.
Title: Re: Cocoa - How to get started with helping?
Post by: AlexTP on January 01, 2018, 08:02:03 am
now fix causes new bug:
Canvas.Font back color is different.
posted repro and screenshots there.
we need 3 colors the same: Pen.Color, Brush.Color for FillRect, Brush.Color for TextOut.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 01, 2018, 05:09:02 pm
Alextp, thank you for the quick resting!
do not hesitate to report any other issues identified.
Title: Re: Cocoa - How to get started with helping?
Post by: AlexTP on January 01, 2018, 05:13:12 pm
I reported new in this forum- new topic in "Cocoa" forum.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 01, 2018, 05:15:32 pm
2 Hansaplast
so, here's the update about "Archive1" sample, indicating problems with TPageControl.

1) TPageControl was not returning the proper client rectangle, causing controls to overflow.

2) TPageControl client rect and bounds rects are different for Cocoa and Carbon. Similar to buttons, and will not be fixed.
However, as long as proper alignment rules (anchors are used) the results would be fine.
With Cocoa IDE, the layout would match the runtime.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on January 01, 2018, 06:47:14 pm
so, here's the update about "Archive1" sample, indicating problems with TPageControl.

1) TPageControl was not returning the proper client rectangle, causing controls to overflow.

2) TPageControl client rect and bounds rects are different for Cocoa and Carbon. Similar to buttons, and will not be fixed.
However, as long as proper alignment rules (anchors are used) the results would be fine.
With Cocoa IDE, the layout would match the runtime.


OK, thanks for looking into that issue. So the solution is always using anchors I guess. I can work with that.
Could it be that there are some border/bezel width issues/differences?
These differences, even though I understand where you're coming from, make it very difficult to design for Cocoa Apps with a Carbon IDE.  :(


Screenshot: Top designtime (Carbon), bottom runtime (Cocoa).
Left is my old way of designing (only use the default align left and top), right is the "new" way (for me anyway) where I align left and right.
As you can see though, the TPageControl/TTabsheet are much more narrow (image: borderspace.png).


So to remedy that, I have to shift the TPageControl 8 pixels to the left and make it 16 pixels wider (image: borderspace_plus8.png).
I did this at the Form.Create event. Obviously something I'd like to avoid.


Note that Top seems to be pretty close, yet height is off again (also about 8 pixels) - see image: borderspace2.png.
Is this by design (ie differences between Cocoa/Windows/Linux and Cocoa)?
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on January 01, 2018, 06:49:48 pm
Forgot to mention: I updated to the latest SVN just before doing this test (SVN Revision 56899M from 1/1/2018).


Also: will there ever be a Cocoa IDE?
Right now most of the components, at designtime, cannot be moved/resized/selected.


Sorry for asking this much - again: I very much appreciate your time in helping out.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 01, 2018, 08:55:17 pm
These differences, even though I understand where you're coming from, make it very difficult to design for Cocoa Apps with a Carbon IDE.  :(
The problem is that Cocoa and Carbon are two different measurement systems, even though they look alike.
In theory, we could go of the premises:
"Carbon IDE should be WSYSIGW for Cocoa apps"
and that would require LCL to emulate Carbon measurements for Cocoa (adding or subtracting a extra pixels here in there).
While in theory it's possible to do, in practice that would cause a lot of useless code.
That would become even more useless, if Apple changes their design again.

Looking into the future (of x64 only apps, w/o any Carbon), there would be nothing to replicate. So what's the point?

I'd recommend to see Carbon and Cocoa as two separate widgetsets in this case.
When you develop cross-platform apps, you understand that controls might look different on macOS vs Windows vs Linux.
You should take the similar approach, while designing in Carbon IDE. Don't expect that it would be 1 to 1 in Cocoa.

OK, thanks for looking into that issue. So the solution is always using anchors I guess. I can work with that.
Could it be that there are some border/bezel width issues/differences?
Yes, borders/bezels might be different.

These differences, even though I understand where you're coming from, make it very difficult to design for Cocoa Apps with a Carbon IDE.  :(
As a matter of fact, it's not. Even though Carbon and Cocoa metrics are different, they're not very far.
So using anchors should allow you to create a fluent UI that would look nice for either widget (Carbon or Cocoa)

Forgot to mention: I updated to the latest SVN just before doing this test (SVN Revision 56899M from 1/1/2018).
Right now most of the components, at designtime, cannot be moved/resized/selected.
I'm not trying to fix IDE.
Instead I'm trying to resolve issues related to Cocoa-WS. Once those are done, IDE should work just fine as is.

Also: will there ever be a Cocoa IDE?
oh yes! as soon as Apple switches to x64 only, we won't have much options left. :)
Title: Re: Cocoa - How to get started with helping?
Post by: AlexTP on January 02, 2018, 07:03:57 pm
https://github.com/graemeg/lazarus/commit/71996baaae574b51ef5e691c6a6945d7f1c588c1
Quote
+    tx := bx + 0.05 * sign(deltaX) * absDeltaX;
+    ty := by + 0.05 * sign(deltay) * absDeltaY;
 

i know that sign(A) * abs(A) == A.
e.g. sign(-3)*abs(-3) == -3.
so make simpler fix:

Quote
+    tx := bx + 0.05 * deltaX;
+    ty := by + 0.05 * deltaY;
---
same fix works for Carbon. please apply too.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 02, 2018, 07:19:05 pm
so make simpler fix:
yeah... I thought about the same ... after the commit.

please answer to the question (http://forum.lazarus.freepascal.org/index.php/topic,39499.0.html) related to this bug report.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on January 02, 2018, 07:44:41 pm
p.s. Dimitry (I believe he is the one that fixed it - correct me if I'm wrong) fixed the missing menu and the height of the component window in Cocoa.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 02, 2018, 07:50:47 pm
p.s. Dimitry (I believe he is the one that fixed it - correct me if I'm wrong) fixed the missing menu and the height of the component window in Cocoa.
yes, he did it.

what's so big of a deal about it? this is how it should work.
he (or whoever) should have done it earlier
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on January 02, 2018, 07:58:46 pm
p.s. Dimitry (I believe he is the one that fixed it - correct me if I'm wrong) fixed the missing menu and the height of the component window in Cocoa.
yes, he did it.

what's so big of a deal about it? this is how it should work.
he (or whoever) should have done it earlier


Just thought it would be a nice to know thing.  :)
And yes, I agree this should have been done earlier. I carefully assume not too many people noticed it since Cocoa IDE has never been working all that well - so they simply didn't try and discover this to be a problem.
Anyhoo ... I'm just glad it's fixed.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on January 02, 2018, 08:05:20 pm
Looking into the future (of x64 only apps, w/o any Carbon), there would be nothing to replicate. So what's the point?

I'd recommend to see Carbon and Cocoa as two separate widgetsets in this case.
When you develop cross-platform apps, you understand that controls might look different on macOS vs Windows vs Linux.
You should take the similar approach, while designing in Carbon IDE. Don't expect that it would be 1 to 1 in Cocoa.


Honestly, I don't care about Carbon - it's in the past, you're absolutely right about there not being a point to pay attention to Carbon minutia.
I am however interested in Windows and Linux behavior matching close to Cocoa.
I'll try to work with anchors more and see how good/bad that will work when developing an application for Mac(Cocoa)/Windows/Linux.


And trying to fix each pixel might be useless as well - like you said: what if Apple changes something yet again.
"Write once and compile anywhere" becomes a little more challenging. But if it's only buttons and a PageControl, then I can work my way around that.

Quote
oh yes! as soon as Apple switches to x64 only, we won't have much options left. :)


Agree  :D
Thanks again for your efforts!  :)
Let me know if you'd like me to test something.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 02, 2018, 08:07:42 pm
Just thought it would be a nice to know thing.  :)
The typical way of getting notified about issues you're interested in is to Monitor them.
Just login to bugtracker (i'll need to create an account)
choose an issue and "Start Monitor" it.
Once tired of waiting or have it resolved - end your monitoring.

And yes, I agree this should have been done earlier. I carefully assume not too many people noticed it since Cocoa IDE has never been working all that well - so they simply didn't try and discover this to be a problem.
Looking at the status of at least three duplicated items. (That are now closed), there are at least 5 people knowing about it.
3 reports
+ two of us

so, that's something to start with.
Naturally, fixing one thing, brings up another thing (https://bugs.freepascal.org/view.php?id=32935) immediately.

I also tried Cocoa IDE and it actually feels slow and laggy compared to Carbon and especially Windows versions.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 02, 2018, 08:16:11 pm
And trying to fix each pixel might be useless as well - like you said: what if Apple changes something yet again.
"Write once and compile anywhere" becomes a little more challenging. But if it's only buttons and a PageControl, then I can work my way around that.
Well, you should read it literally "write once and compile anywhere"
It doesn't say "design once and use everywhere" :D

but seriously, UI design is a problem when it comes to cross-platform issues.
The big corps started addressing it at the mobile device revolution.
(When it turned out that's a "mobile" version of the site is needed.
or when the same app needs to run on 4" smartphone  and 10" tablet)

This is when all these autolayouts (https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/index.html) started coming into play (Google provides its own version for Android).
Before that, it was up to a cross-platform library (LCL, Qt) to handle those issues.
And actually self drawn libraries (Qt) have a benefit on that - they look the same no matter what the platform is.

Thanks to Mattia's input in the first place, LCL has pretty nice API to handle automatic sizing and layout.
http://wiki.freepascal.org/Autosize_/_Layout
It's actually pretty strong, but it would be nice to have more platform - specific configuration.

I.e. Apple suggests a certain offsets, order and size of buttons (other controls), while Windows suggests others.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on January 02, 2018, 08:27:26 pm
Naturally, fixing one thing, brings up another thing (https://bugs.freepascal.org/view.php?id=32935) immediately.


You're welcome  :D ....
But I guess this is the way to move away from Carbon - I wish I was a better developer so I could do my share with development.


Well, you should read it literally "write once and compile anywhere"  :D


Hahah no kidding ...  :D
But seriously - I do understand the complications to accommodate all.
Just loved how well this worked when moving projects between the Carbon/Windows/Linux platforms.
Title: Re: Cocoa - How to get started with helping?
Post by: skalogryz on January 02, 2018, 08:39:23 pm
But seriously - I do understand the complications to accommodate all.
Just loved how well this worked when moving projects between the Carbon/Windows/Linux platforms.
It depends on how you're demanding to yourself about "native" look of an application.

Try to create an app (even Carbon app) that would look like designed in Xcode, rather than Lazarus.

Yet at the same time would not look foreign in Linux or Windows environments (i.e. due to large buttons or too wide spaces between controls). Also, try not to use any run-time ago that would rearrange controls, change their behavior or look. Try to do it in a designer only.

Try something very simple - like recreation Date & Time configuration in Mac OS Preferences.
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on April 04, 2018, 05:45:40 pm

After some more testing (SVN 57576) I did find that for a TPageControl (same for TNotebook and TExtendedNotebook) one would need to :


1) Increase top by 2 (Top+2)
2) Decrease left by 6 (Left-6)
3) Increase Height by 8 (Height+8)
4) Increase width by 12 (Width+12)


In order to match the design in Carbon, Windows, Linux. See screenshots before.pnh and after.png.


Since TNotebook and TExtendedNotebook are affected as well, I assume this is something that could be done in TCustomTabControl? It's a little over my head. I did try to find or create a fix myself with no luck (so far).


The logic I have followed so far;
It's Cocoa specific, so I expect something to be changed in lcl/interfaces/cocoa (cocoawscomctrls.pas?), where the native control is being created and/or sized/positioned. I just get lost after that ...
Any suggestions, ideas, comments?


p.s. reported this in a relevant bug as well (bug 32887 (https://bugs.freepascal.org/view.php?id=32887))
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on April 04, 2018, 05:46:18 pm
Due to size limitations, I had to post the after.png in a separate post ...
Title: Re: Cocoa - How to get started with helping?
Post by: ChrisR on April 06, 2018, 05:08:27 am
Hansaplast
 Thanks for your input. It is great to have a few more people testing the Cocoa widgets.
 Perhaps Dmitry can clarify, but I think this is because Cocoa uses a different size. Therefore, the native Cocoa widgets created by Lazarus match native Cocoa widgets made by XCode. The cost of looking native is that the widgets do not precisely match those of other operating systems.

See
  http://wiki.lazarus.freepascal.org/Cocoa_Internals/Buttons
 "Most buttons in macOS design have fixed height"
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on April 06, 2018, 08:57:50 am
Thanks Chris!


Yeah, I was aware about the button issues - Dimitri kindly showed me in XCode that this indeed is a Cocoa/Apple limitation and that would be OK with me.


I think TPageControl (and all controls derived from TCustomTabControl that seem to be affected as well) may not be the same issue. I can easily position them right.
For now I correct it this way, which obviously is totally not the right way to do it, by doing this:



Code: Pascal  [Select][+][-]
  1. procedure TForm1.FormCreate(Sender: TObject);
  2.   {$IFDEF LCLCOCOA}
  3.   procedure fixCocoaPageControls;
  4.     var counter:integer;
  5.         pc:TPageControl;
  6.     begin
  7.       for Counter:=0 to self.ComponentCount-1 do
  8.         begin
  9.           if self.Components[counter] is TPageControl then
  10.             begin
  11.               pc:=TPageControl(self.Components[counter]);
  12.               pc.SetBounds(pc.Left-6,pc.top+2,pc.width+12,pc.Height+8);
  13.             end;
  14.         end;
  15.     end;
  16.   {$ENDIF}
  17. begin
  18.   {$IFDEF LCLCOCOA}
  19.   fixCocoaPageControls;
  20.   {$ENDIF}
  21.   ...
             
The controls positions really bad - when comparing designtime with runtime.
For now now it's even worse, since Cocoa cannot really be used in designtime. But I'd also like to be able to rely on the big pieces of a UI design to work at least in comparable way. That the buttons are not the same is OK - I can work with that.  :)
I'd love to find the place to fix this and post a patch, but I honestly couldn't find where I should do this. Some pointers may be helpful.
Title: Re: Cocoa - How to get started with helping?
Post by: Trenatos on July 11, 2018, 10:20:34 pm
I just reported an issue, but uh, does anyone know why there aren't options for Cocoa in the widgetset options?
Title: Re: Cocoa - How to get started with helping?
Post by: Hansaplast on July 12, 2018, 10:05:33 am
Hi Tretanos,


what do you mean with "options for Cocoa in the widgetset options" ?
Title: Re: Cocoa - How to get started with helping?
Post by: Trenatos on July 12, 2018, 04:21:17 pm
When reporting the issue there are many options for describing the issue, including what widgetset it relates to, I saw several but not Carbon or Cocoa.
Title: Re: Cocoa - How to get started with helping?
Post by: Phil on July 12, 2018, 04:25:19 pm
When reporting the issue there are many options for describing the issue, including what widgetset it relates to, I saw several but not Carbon or Cocoa.

I see carbon and cocoa in Bugtracker Widgetset. Maybe just added?
Title: Re: Cocoa - How to get started with helping?
Post by: Trenatos on July 12, 2018, 04:59:33 pm
Maybe? I'll make sure to use them next time  :D
TinyPortal © 2005-2018