I'm sure other Mac users are eager to get Cocoa to work. If we work together then maybe we can make some progress ...
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.
p.s. when you compiled the IDE with the Cocoa widget set - did you miss the menu as well?
Gentlemen! are there particular examples the Cocoa issues described? with screenshots?
Also, I see a tabbing problem on Cocoa too: jumps two controls instead of only one.very interesting.
Gentlemen! are there particular examples the Cocoa issues described? with screenshots?
Were the screenshot (Windows/Linux) useful?Yes. The reason I asked for them is because of "Fonts" sections.
I can do more testing if you'd like.
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)?
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?
I guess DisplayStyle would of course be a new property for a TButton as well, right?Tbutton, TbitBtn, TEdit, TPassword (maybe)
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.
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?an empty string (or undefined) for DisplyStyle - is "osdefault".
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.There's macOS specific problem not to follow this approach.
he says he has new job and no time for mac work.I can definitely see how it works.
Were the screenshot (Windows/Linux) useful?Yes. The reason I asked for them is because of "Fonts" sections.
I can do more testing if you'd like.
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?)
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)
TextEdit. How does it look in TextEdit?
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?
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.
Why are there two screenshots in each .png? What am I missing?
Top window is the application in runtime, bottom window is design time.
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 :)
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.
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
Looks like Carbon, Windows and Linux show the same size amongst each other and in design vs runtime.No.
Cocoa (the test app and TextEdit) seem to use a different size than those other 3 widgetsets.
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:
I can create a project in Lazarus and XCode if you'd like.32 should be height of the button.
So the button has to have height set to 32? Or did you mean the font size of the button?
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
I think the fonts are actually the same size, or am I not seeing this right?let's magnify a bit
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)
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.
Dmitry, i localized bug from ATTabsThank you! That was an easy one.
https://bugs.freepascal.org/view.php?id=32914
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.
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.
OK, thanks for looking into that issue. So the solution is always using anchors I guess. I can work with that.Yes, borders/bezels might be different.
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. :(As a matter of fact, it's not. Even though Carbon and Cocoa metrics are different, they're not very far.
Forgot to mention: I updated to the latest SVN just before doing this test (SVN Revision 56899M from 1/1/2018).I'm not trying to fix IDE.
Right now most of the components, at designtime, cannot be moved/resized/selected.
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. :)
+ tx := bx + 0.05 * sign(deltaX) * absDeltaX;
+ ty := by + 0.05 * sign(deltay) * absDeltaY;
+ tx := bx + 0.05 * deltaX;---
+ ty := by + 0.05 * deltaY;
so make simpler fix:yeah... I thought about the same ... after the commit.
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.
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
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.
oh yes! as soon as Apple switches to x64 only, we won't have much options left. :)
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.
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.
And trying to fix each pixel might be useless as well - like you said: what if Apple changes something yet again.Well, you should read it literally "write once and compile anywhere"
"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.
Naturally, fixing one thing, brings up another thing (https://bugs.freepascal.org/view.php?id=32935) immediately.
Well, you should read it literally "write once and compile anywhere" :D
But seriously - I do understand the complications to accommodate all.It depends on how you're demanding to yourself about "native" look of an application.
Just loved how well this worked when moving projects between the Carbon/Windows/Linux platforms.
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.