Skip to content

Conversation

victoryforce
Copy link
Collaborator

This is certainly not needed for Linux and Windows, where even without this setting, the native dialogs offer folder creation functionality. I don't have macOS devices, so I need this PR to be tested by macOS users to see if it will actually enable the ability to create folders, which is disabled by default.

attn: @MStraeten @zisoft

@zisoft
Copy link
Collaborator

zisoft commented Jun 15, 2025

Unfortunately not:

Bildschirmfoto 2025-06-15 um 09 28 58

The "New Folder" button should appear on the left.

@zisoft
Copy link
Collaborator

zisoft commented Jun 15, 2025

I put a gtk_file_chooser_get_create_folders() to see wheather the change get applied.
It returns TRUE.

So most likely a gtk bug?

@victoryforce
Copy link
Collaborator Author

@zisoft Thanks for testing!

I put a gtk_file_chooser_get_create_folders() to see wheather the change get applied. It returns TRUE.

This setter and getter simply set and query the value of the property, so it is logical that the change to the property is actually applied.

So most likely a gtk bug?

Yes, it looks like GTK doesn't implement support for controlling this functionality on macOS. Or maybe GTK has not yet adapted to the changes in macOS, if it worked in earlier versions of macOS. In any case, I don't think there's anything we can do about it then. Trying to get around this and work directly with NSSavePanel seems like an ugly solution.

So what would you decide about #18930 and #18591?

And maybe it makes sense to accept this PR anyway in the hope that if GTK implements support in the future, the call to gtk_file_chooser_set_create_folders will do the right thing and support for creating folders will then be guaranteed to appear even if it is disabled by default on macOS? What's your take on this?

@zisoft
Copy link
Collaborator

zisoft commented Jun 15, 2025

And maybe it makes sense to accept this PR anyway in the hope that if GTK implements support in the future, the call to gtk_file_chooser_set_create_folders will do the right thing and support for creating folders will then be guaranteed to appear even if it is disabled by default on macOS? What's your take on this?

+1
With that changes applied I can continue to dig further into the issue on macOS.
I can't believe that such a basic functionality is not working in the gtk base libraries.

So what would you decide about #18930 and #18591?

Let's leave them open for now until we give up on this.

@MStraeten
Copy link
Collaborator

the file chooser doesn't need the "new folder" button - this wasn't so also available in earlier macos versions. It's the missing support for "cmd+shift+N" that makes the difference between macos 14 and macos 15.
In my sonoma virtual machine for building 13.5 release version there's no issue with creating a new folder.
So it's not gtk3 that broke stuff, it's apple ...

@TurboGit TurboGit added the understood: unclear devs lack most or all important info and can do nothing, the report will be closed after 2 weeks label Jul 1, 2025
Copy link

This pull request has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

@victoryforce
Copy link
Collaborator Author

In my sonoma virtual machine for building 13.5 release version there's no issue with creating a new folder.
So it's not gtk3 that broke stuff, it's apple ...

OK, I understand. So what do we decide about the changes in this PR? I understand that in practice they do not change/fix the behavior on any of the platforms: for Linux and Windows the native dialog supports folder creation and enabling it is not needed, and on macOS the problem is a bug in the OS. In fact, the commands added by this PR to the code simply make our intention clearer for those who read the code, nothing more. On the other hand, code that is not actually needed can be replaced with comments...

What is your final opinion, should this PR be closed?

@MStraeten
Copy link
Collaborator

it doesn't make sense to keep it open since darktable uses the native os dialog and on recent apple macOS versions (>= macos15) and as long as apple doesn't decide to change that default behaviour there's no hope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

understood: unclear devs lack most or all important info and can do nothing, the report will be closed after 2 weeks

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants