OpenPictureDialog is not openning?

[cobata]

Hello, Guys,

In order to prepare myself to the new Apple Mac OS X 64bit requirements (they come), I started testing/ porting my software from carbon to cocoa...
1. The issue I am observing is that I can open Open and Save File Dialogs, but cannot open Open Picture Dialog... Do you know something regarding this?
2. Have I expect some surprises related to App Store sandboxing like in carbon and the required usage of NSPanels in place of Open/ Save dialogs, that I solved here: https://forum.lazarus.freepascal.org/index.php/topic,35843.0.html

Thanks in advance!

[skalogryz]

You need to use trunk version

[cobata]

Is it fixed in the Trunk?
What about my second question?

Talking about my second question, I have nothing against the dev branch (Trunk) and to contribute to it, but now the questions are about the App Store, the Stable releases and the Base lines I can step on for my next software releases - those all relate to my responsibilities to my customers.

Actually, I can focus to contributions: tests and code level (and I think I do it) that relate to the official FPC/ Lazarus releases, to help devs developing to/from FPC/ Lazarus.

Actually, since Lazarus 1.4.4 (there I was advised to use newer) to 1.8.4, I am finding just compilation improvements of cocoa, but I was advised to use cocoa as primary widget set, but carbon is more stable.

Also, I found that it will be hard to switch from carbon to cocoa - how much hard... = how much it was to switch from Delphi for Win to Lazarus for Win...

I think (I think a lot ) that the port to cocoa has to be based on carbon (not on win32), because carbon is "previous", cocoa is "next" - native to Apple ecosystem.

If the Trunk is more stable is it possible to release the trunk as official release(s)?

It's by me.
Thanks!

[cobata]

GOOD MORNING!

ERROR ITMS-90240: "Unsupported Architectures. Your executable contained the following disallowed architectures: '[i386 (in com.COBATA.XHTMLConstructor1Init.pkg/Payload/COBATA (X)HTML Constructor 1.0 Init.app/Contents/MacOS/COBATA(X)HTMLConstructor1.0Init)]'. New apps submitted to the Mac App Store must support 64-bit starting January 2018, and Mac app updates and existing apps must support 64-bit starting June 2018."

When is planed the Cocoa to be stable - NOW the ONLY possible Apple Mac App Store GUI native solution?

We have hard ports: from Delphi Win to Lazarus Win; from Lazarus Win to Lazarus Mac Carbon; from Lazarus Mac Carbon to Lazarus Mac Cocoa.

[Phil]

We have hard ports: from Delphi Win to Lazarus Win; from Lazarus Win to Lazarus Mac Carbon; from Lazarus Mac Carbon to Lazarus Mac Cocoa.

If you haven't seen these notes, you might find them useful for getting started with trunk Cocoa without touching your existing Carbon installation:

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

Time to get crackin with Cocoa! Report bugs as you encounter them, but only if you're testing the very latest from trunk.

Sounds like you're already well-versed in submitting a sandboxed app, but you might still find the sandboxing notes here useful:

https://macpgmr.github.io

[cobata]

Phil,

Thanks!

Good work guys!

I was very skeptic (I already said why), but now I am very impressed...

Lets say, the quick test, I performed, shows:
1. The Cocoa components positioning is like in Carbon - in Lazarus 1.8.4 (Release), it is not, mainly related to radio group items.
2. The Dialogs are opening - in Lazarus 1.8.4 (Release), OpenPictureDialog is not opening.
3. The functionality works.

The version:
"Checked out revision 58509."

Of course, it is just initial quick test!
1. I found that in some radio groups the "&" char appears in front of the shortcut key. Your comment, please?
2. What about the sandboxing, in Carbon, I replaced the LCL dialogs with the NSPanel alternatives (The attached file above.). What is the case with Cocoa, have I use the LCL dialogs OR have to use my Carbon solution here OR both are possible - I read somewhere in Apple, that Cocoa uses NSPanels?
3. When LCLcocoa will be officially released?

Best Regards!

[Phil]

Of course, it is just initial quick test!
1. I found that in some radio groups the "&" char appears in front of the shortcut key. Your comment, please?
2. What about the sandboxing, in Carbon, I replaced the LCL dialogs with the NSPanel alternatives (The attached file above.). What is the case with Cocoa, have I use the LCL dialogs OR have to use my Carbon solution here OR both are possible - I read somewhere in Apple, that Cocoa uses NSPanels?
3. When LCLcocoa will be officially released?

You should be able to use the normal TOpenDialog, etc. in a sandboxed app that uses the Cocoa widgetset. I don't see any need for NSPanels unless you like that for some reason.

The only issue I found is with my own Recent Files list, which does not work as described in these notes:

https://macpgmr.github.io/ObjP/SandboxingAppsOnMac.html

If you see bug with the radio group display, you should report them with a small example app's source to the bugtracker.

Is anything ever officially released here?

[cobata]

OK, Thanks.

Is anything ever officially released here?

I mean on https://www.lazarus-ide.org as official release version? As Lazarus 1.9.0 (I guess)? When it is planned?

[Phil]

OK, Thanks.

Is anything ever officially released here?

I mean on https://www.lazarus-ide.org as official release version? As Lazarus 1.9.0 (I guess)? When it is planned?

No idea. You would have to ask the Lazarus owners.

Note I have not tested TOpenPictureDialog, but if it uses standard Cocoa dialogs it should be okay.

I don't use Lazarus and don't do desktop app development anymore, so none of this matters much to me. However, I do test an old app occasionally against the latest LCL / Cocoa widgetset code to check its status. The app has about 15 forms, maybe 25K lines of code. As of today, it works very well when sandboxed, with the exception of its Recent Files list, as mentioned above. Here's what I use for the entitlements file:

Code: XML  [Select][+][-]

1. <plist version="1.0">
2. <dict>
3.         <key>com.apple.security.app-sandbox</key>
4.         <true/>
5.         <key>com.apple.security.network.client</key>
6.         <true/>
7.         <key>com.apple.security.print</key>
8.         <true/>
9.         <key>com.apple.security.files.user-selected.read-write</key>
10.         <true/>
11.         <key>com.apple.security.temporary-exception.apple-events</key>
12.         <string>com.microsoft.Excel</string>
13. </dict>
14. </plist>
15.  

The Excel thing is only because my app runs Excel remotely. Normally you wouldn't need this.

Don't forget that to access the Internet in a sandboxed app, you can't use an OpenSSL-based HTTP client (Indy, Synapse, FPC). Use something that uses one of Apple's ObjC classes instead.

Also, other than some scrollbar issues, my app works pretty well under Cocoa.

[cobata]

Note I have not tested TOpenPictureDialog, but if it uses standard Cocoa dialogs it should be okay.

TOpenPictureDialog is opening now... (not tested in sandbox, yet).

   <key>com.apple.security.temporary-exception.apple-events</key>

I remember, that Mac App store rejected me, because of temporary entitlement usage.
I am not sure that I understand your issue, but... I use:
com.apple.security.files.downloads.read-write
because of the intensive read-write need from some directory, actually I posted a RFE, Apple to created an entitlement for the "documents" directory - I think that it's more useful and appropriate than "downloads" (by security issues too), but Apple rejected me
(Try with this entitlement...)

Don't forget that to access the Internet in a sandboxed app, you can't use an OpenSSL-based HTTP client (Indy, Synapse, FPC). Use something that uses one of Apple's ObjC classes instead.

Useful!

Also, other than some scrollbar issues, my app works pretty well under Cocoa.

Yes, I found this too in Lazarus 1.8.4 and Lazarus Trunk. Even the main form is not scrolling neither horizontally nor vertically... Is it posted as a bug?

[Phil]

com.apple.security.files.downloads.read-write

My temporary entitlement is for running Excel remotely, as described in the article.

My problem is unrelated to that. It has to do with how Lazarus prevents the normal use of Cocoa-managed recent files. See discussion in article.

Don't see how enabling user access to the Downloads folder has anything to do with either issue.

The scrolling problem I believe has been reported. Check bugtracker to make sure that what you're seeing has been reported.

[cobata]

Don't see how enabling user access to the Downloads folder has anything to do with either issue.

Where you look for those recent files..., where they have to appear...
My idea (just idea and I will not spam anymore) with the "downloads" entitlement was that: if you have permanent access to some dir (OSX "knows" for it and allows it for the sandbox) you will probably have records for the already read and write files from this dir. In the other cases (for example: you allow access to some dir by dropping it on the running app icon) - it is just, lets say, per app running session... This is my logic - it seems that you and me think that the problem somehow relates to sandboxing and entitlements.
Some other idea could be - to specify (in .plist...) the file types used by your app...