I just noticed the same thing with my small Carbon apps ...
Note 32 bit code is deprecated by Apple and pretty soon is no longer allowed
But seriously, ARM has come a long way hasn't it ?
And this thread does explain why I have been asked twice this morning about when my app will do 64bit on MacOS. Going to have to be real soon ......
But seriously, ARM has come a long way hasn't it ?
Yes, already a year ago people were noticing that the iPad Pro was edging into Intel i7 benchmark territory.
https://9to5mac.com/2017/06/14/ipad-pro-versus-macbook-pro-speed-tests/
In university I have a teacher that's using a tablet instead of notebook. Less weight and just as good for his needs.
But what if Apple marketed an ARM-based MacBook running macOS that's priced somewhere between the iPad (starts at US$329, $299 education) and the MacBook (starts at $999)?
Sure, the iPad price a good price for a good tablet. In my country is almost the price of a "regular" smartphone (I say is not cheap - for me - but also not expensive).
My boos says that in first place is macOS, then Linux, then Windows.
My boos says that in first place is macOS, then Linux, then Windows.
And Macs do tend to last a long time. I'm typing this on my late 2008 MacBook.
Well, I have a Lenovo from 2010 and is still running, I just changed the old school HD with an SSD, nothing more.
macOS 10.13.4 now warns the first time you run a 32-bit app.
Apple keeps ratcheting up the difficulties of small software developers, clamping down and shutting us out, while back in the day they championed us.
Looking at the Lazarus Roadmap, cocoa is coming along well, but I'm still hampered by the missing ScrollBar, Accelerator Keys, ImageList, ToolBar, DrawGrid, and PaintBox. Without these I can't compile.Could you please provide a test app for each of those components?
@skalogryzBugtracker is the best, but posting them here would work as well
Thanks, I will work on that. Is that something I should post in lazarus bugtracker?
- Harder One. I hide my main form on startup and on Carbon, when its active (but hidden) its MainMenu still occupies the Mac Main Menu space, across the top. However, with Cocoa, that main menu does not show up when form is hidden. So, for me, no control of the App.
- Nasty One. Again, trunk, not just Cocoa. When you run it from within the IDE, an app's main menu is, again, not shown across the top and an icon for the app is not shown in the plank. This seems similar to above but is not, I think, because - Not just a Cocoa problem; You can grab a terminal and 'open' the compiled app and it does work normally; no Icon in the plank (unlike 2 above).
These problems can be demonstrated with simple one form apps. 1. is probably just a sensible change, 2. and 3. I feel I need to have a further play before formally reporting. Interestingly, only 2. seems to be a pure Cocoa issue. Maybe test on Linux .....
With (2), perhaps it's just lost the focus? When you click on the app on the Dock, does the app's menu appear?
No, clicking the icon in the 'Dock" (see, I'm learning), does not appear to do anything.
..... When you run it from within the IDE, an app's main menu is, not shown across the top and an icon for the app is not shown in the Dock. Only interaction with the running app is to close (or full screen) it. But you can grab a terminal and 'open' the same compiled binary and it does work normally, the problem is only when running from within the IDE.
In a terminal, go somewhere suitable and -
mkdir laz-svn cd laz-svn svn checkout https://svn.freepascal.org/svn/lazarus/trunk . make CPU_TARGET=i386 open lazarus.app --args "--pcp=~/.laz-svn"
Check the setting and click "start IDE"
Then click Options, scroll down to Debugger->General and paste(inc the ") into the field "Debugger specific Options" and, IMPORTANT, press <enter> at the end of the line. Save.
"--eval-command=set startup-with-shell off"
Paste a button (or anything) into the blank form thats been waiting for you to come back, click the green 'Run' icon and, when the running form is displayed, can you interact with it ?
Hans, I don't need to change compiler when changing between Carbon and Cocoa. To go from carbon to cocoa, I change Target CPU family from default to x86_64 and then click the link that says "Select another LCL widgetset ..." and from there, I choose 'cocoa'.
Good idea Phil. Think I should use the Build Mode more often...
Phil, do you think the bug about an app not being usable in the IDE on Mac should be reported ? Three of us have now seen it .....
I have not had a lot of success in reporting bugs so my confidence is not high :-\
I think, the cocoa widgetset should be designed to look similar in sizes and proportions so that you can reuse your Windows or Linux code without modifications - and like it is for carbon today. Other implementations would make no sense.Totally agree ... or at least: this is how I'd like to see it as well.
However the devs appear to be aiming to match XCode - for example font size = 8 in XCode is much smaller than in Carbon/Windows/Linux.If you're using the trunk, you should be able to do it in the following manner:
It will not help with designed controls, but changing font in run-time will match Xcode.
Starting with 1.8 release, the Cocoa (and Carbon) PPI is 96, rather than 72.
Thus LCL selected fonts of the a particular size (in points) would not match the same font and the same size selected in Xcode or TextView.
I was trying to resolve the issue on case-by-case basis, however cross-platform needs took over. And 96 ppi rule remains.
The code above however allows to switch Cocoa back from 96 to 72 for run-time.
Where do I put this part of the code?
dbannon, regarding issue 33634, I think this is a replication of 32888. Does changing the lpi file as noted in that issue fix your problem?
It's in the CocoaInt unit, so be sure to include it in your uses.
Make sure you're using the latest trunk source. cocoaint.pas was modified on April 19.
However the devs appear to be aiming to match XCode - for example font size = 8 in XCode is much smaller than in Carbon/Windows/Linux.
I think, most Lazarus users on macOS are cross-plattform developers coming from Windows or Linux and want to make their programs run also on a Mac.
Lazarus - Write Once - Compile Anywhere, Lazarus's slogan and feature. Its the one thing (IMHO) that Lazarus is far better at than any alternative. Its silly trying to compete directly with (eg) XCode, better to play to our strengths and ensure absolutely minimum changes between platforms.
Davo
QuoteI think, most Lazarus users on macOS are cross-plattform developers coming from Windows or Linux and want to make their programs run also on a Mac.
Yes, I agree. Lazarus - Write Once - Compile Anywhere, Lazarus's slogan and feature. Its the one thing (IMHO) that Lazarus is far better at than any alternative. Its silly trying to compete directly with (eg) XCode, better to play to our strengths and ensure absolutely minimum changes between platforms.
Davo
Hans, with TMain menu,...
is there any project-example, built to run with xcode, and to target 64bit High Sierra ?
aahhh merci merci merci :D
and is there any way to add colors for key-words (like "begin" "end" and so on ) ?
(by the way : I miss CodeWarrior, where you could have several colored lists of key-words and not just only one…)
@skalogryzBugtracker is the best, but posting them here would work as well
Thanks, I will work on that. Is that something I should post in lazarus bugtracker?
If you are trying to port code that relies on 32 bit that is a big mistake and you just are caught out.....Ideally, to port your 'Lazarus' code from 32bit to 64bit you need to change CPU Target, the widget set (Carbon->Cocoa) and the compiler. Three settings and build.
Apple is phasing out/ has phased out 32 bit. When targeting MAC you *must* use 64 bit. If not now, within weeks... not years... Although some support will be provided until 2020.
Apple's warning dates from 2016....
If you are trying to port code that relies on 32 bit that is a big mistake and you just are caught out.....
I have no pity with the dumb.