darktable-org
Attempt to enable folder creation in file chooser dialogs on macOS
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
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?
@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?
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_folderswill 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 https://github.com/darktable-org/darktable/issues/18930 and https://github.com/darktable-org/darktable/issues/18591?
Let's leave them open for now until we give up on this.
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 ...
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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?
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.
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.