sbarex
Persistent "access data from other apps" dialog
Every time I interact with Finder for the first time after a restart, I see the attached dialog, despite "Allow"ing it each time.
very strange, the app does not access any external files unless the user explicitly requests the QL preview
Tbf, it looks like I see this the first time I select a .md file, without necessarily pressing space to open up the quick preview.
Sadly I experience exactly the same issue. This is under macos 15.1.1 (24B91) have not tested on other versions in a while.
I think it's due to the system I used to access the app settings from the quicklook plugin. The app doesn't access settings of third party apps.
Hi! Just FYI, this happens because the app does not have "Full Disk Access" regardless of what access it actually needs. Either it's missing an entitlement or there's some temporary storage in use.
The workaround in Sequoia is to pop over to System Preferences > Privacy & Security, click on "Full Disk Access" and drag and drop the app to that pane.
I have the same issue. I understand that Full Disk Access will work around this, but it shouldn't be necessary.
I remind you that the application is only made to set the preferences of the quicklook preview setting (it is not a markdown editor or a standalone viewer). It is reasonable therefore that it is opened sporadically and therefore the warning should not be so annoying.
The same warning appears the first time you preview a markdown file after a reboot, or in case the plugin is automatically released by the system to free up memory.
The application does not access any preferences of other applications except its own quicklook plugin.
As I said before, this behavior is due to the trick used to share preferences between application and plugin without using an apple developer license.
In a future version I will look for alternative solutions.
@sbarex you're wrong here. The warning appears every time the quicklook plugin is activated. There is something in the plugin itself, not the app, that requires an extra entitlement.
My system has 36GB of RAM. Hardly likely. You really should check what is going on, because that argument does not make sense independently of RAM or the plugin being loaded/unloaded.
On my system I only one warning after the boot.
You could open the Activity Monitor (inside Application/Utilities), search for QLMarkdown Preview Extension and check if the PID changes after each view request.
My brand new M4 Mac has 24 GB of RAM. Even if the PID does change, this is a problematic way for your extension to be structured. Of course the main app is only for configuring settings. That is all I use it for. Similarly, of course macOS may quit and restart the extension as much as it decides based on who knows what variables. That is how extensions, and frankly all apps when no window is open, work on macOS. It does not mean that the extension should need to ask each time for permission to read its settings.
Are you using Containers vs Group Containers for the app properly? I notice both have sets of files for QLMarkdown, but maybe the extension is trying to read specifically from the main app's sandboxed container, rather than the main app writing into the shared group container the extension also has access to?
Certainly for now Full Disk Access works around this application/extension structure issue. But it is not an acceptable solution. macOS provides appropriate mechanisms for extensions to access their parent app's data. Even your Syntax Highlighter app/extension seem to be doing this appropriately. But QLMarkdown isn't.
Group Containers require an apple developer license. This application is currently unsigned because I don't have a developer account at the moment. On my system (M4) I have no external preference access warnings.
You mean in Syntax Highlight? Yes, I do, as I make it similar to my IDEs, all sharing more or less the same color scheme. But I'm not, as far as I know, doing anything like that in this app, QLMarkdown.
I rewrote the preference management code. The problem should now be solved on release 1.0.22.