Cocoa - How to get started with helping?

[Hansaplast]

Lazarus just reminded me that I had not saved my project. So just to make sure; again the project files (after clicking "Save") ... sorry.

[Hansaplast]

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! 

[AlexTP]

Dmitry, i localized bug from ATTabs
https://bugs.freepascal.org/view.php?id=32914

[skalogryz]

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)

[skalogryz]

2 Hansaplast
the issue seems to be in placing TTabControl under cocoa-ws.

[AlexTP]

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.

[skalogryz]

Alextp, thank you for the quick resting!
do not hesitate to report any other issues identified.

[AlexTP]

I reported new in this forum- new topic in "Cocoa" forum.

[skalogryz]

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.

[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.

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)?

[Hansaplast]

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.

[skalogryz]

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.

[AlexTP]

https://github.com/graemeg/lazarus/commit/71996baaae574b51ef5e691c6a6945d7f1c588c1

+    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:

+    tx := bx + 0.05 * deltaX;
+    ty := by + 0.05 * deltaY;

---
same fix works for Carbon. please apply too.

[skalogryz]

so make simpler fix:

yeah... I thought about the same ... after the commit.

please answer to the question related to this bug report.

[Hansaplast]

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.