macOS - open files from Finder and other apps

[michmill1970]

This PR fixes the issue where files can't be opened in Darktable by Finder or other apps that use macOS Launch Services.

I've tested the repro steps in all issues related to #17298. All previously reported issues all work fine now.

Issues tested:
#17298 - passed
#17539 - passed
#17671 - passed
#17704 - passed
#18043 - passed

Tagging @zisoft as the macOS dev.

Cheers,
Mike

[zisoft]

Works for me 👍

In src/gui/gtk.c we have a signal handler for NSApplicationOpenFile with the callback _osx_openfile_callback(). Can this be removed with this PR?

If I drop a single image from finder onto the lighttable of the running application, it gets imported but not switched to darkroom.

And I think @TurboGit will request some style changes :-)
(no space after for ( etc.)

[michmill1970]

Works for me 👍

In src/gui/gtk.c we have a signal handler for NSApplicationOpenFile with the callback _osx_openfile_callback(). Can this be removed with this PR?

I don't think so. I tried to only touch things that would affect application launch, and nothing after darktable entered main(int argc, char *argv[]) (other than the #ifndefs that blocked the code from running in MAC_INTEGRATION mode).

If I drop a single image from finder onto the lighttable of the running application, it gets imported but not switched to darkroom.

I'll be honest, I don't know if I ever used drag/drop into the Lighttable view so I don't know the existing behavior. I did test my changes so that it didn't break anything. Did it go to darkroom before my changes? I can revert my private branch and test if you don't know off the top of your head. It sounds like going to the darkroom view is proper behavior, but did the macOS build follow this?

And I think @TurboGit will request some style changes :-) (no space after for ( etc.)

No worries. I'll fix whatever @TurboGit tells me to.

Cheers,
Mike

[zisoft]

Did it go to darkroom before my changes?

No, I thought this was another complaint by others. All good.

[TurboGit]

I'm not a macOS guy, this is already validated so good to me.

Just some minor style to conform to current dt guideline. TIA.

[TurboGit]

Good to me now, thanks!

[TurboGit]

A side note, please never merge master branch into a topic branch like this one. I'll squash everything here, so no problem.

[TurboGit]

@michmill1970 : on macOS 13 XCode 15.2 this is failing with:

/Users/runner/work/darktable/darktable/src/src/osx/osx.mm:307:17: fatal error: no matching member function for call to 'push_back'
    openedFiles.push_back([filename UTF8String]);
    ~~~~~~~~~~~~^~~~~~~~~
/Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/vector:591:62: note: candidate function not viable: no known conversion from 'NS_RETURNS_INNER_POINTER const char *' to 'const value_type' (aka 'const std::basic_string<char>') for 1st argument
    _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI void push_back(const_reference __x);
                                                             ^
/Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/vector:593:62: note: candidate function not viable: no known conversion from 'NS_RETURNS_INNER_POINTER const char *' to 'value_type' (aka 'std::basic_string<char>') for 1st argument
    _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI void push_back(value_type&& __x);
                                                             ^
1 error generated.

[zisoft]

I would suggest to use a simple GList here instead of std::vector

[michmill1970]

I would suggest to use a simple GList here instead of std::vector

The issue isn't with the vector, but with the way earier versions of XCode casts the NSString to something that can be used by the std::string constructor. By being more explicit in the code casting and creating the std::string, the problem should be fixed.

The change has been committed and is awaiting your approval.

Cheers,
Mike

[michmill1970]

The issue was due to the way the older XCode compiler was casting the NSString when constructing the std::string. This should fix it by being more explicit in the code.

[TurboGit]

Please DO NOT merge master into your topic branch. TIA.

[TurboGit]

Thanks!