Cocoa - How to get started with helping?

[skalogryz]

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

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

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.

[Hansaplast]

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.

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

Agree 
Thanks again for your efforts! 
Let me know if you'd like me to test something.

[skalogryz]

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

I also tried Cocoa IDE and it actually feels slow and laggy compared to Carbon and especially Windows versions.

[skalogryz]

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"

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

[Hansaplast]

Naturally, fixing one thing, brings up another thing immediately.

You're welcome  ....
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" 

Hahah no kidding ... 
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.

[skalogryz]

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.

[Hansaplast]

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)

[Hansaplast]

Due to size limitations, I had to post the after.png in a separate post ...

[ChrisR]

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"

[Hansaplast]

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.

[Trenatos]

I just reported an issue, but uh, does anyone know why there aren't options for Cocoa in the widgetset options?

[Hansaplast]

Hi Tretanos,


what do you mean with "options for Cocoa in the widgetset options" ?

[Trenatos]

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.

[Phil]

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?