I've written a quick look plugin to preview my custom file type, but it doesn't work when embedded in my OS X app bundle. Running "qlmanage -m plugins" doesn't show my UTI
Manually copying the qlgenerator file from myApp.app/Contents/Library/QuickLook/ to /Library/QuickLook/ and running "qlmanage -r" makes the quicklook preview work.
Do you have to do something special in the hosting app to register the embedded quick look plugin with OS X?
Extra notes: (I don't know why these would matter since the qlGenerator works when I manually copy it, but maybe this information will help)
During build, I get this warning about the qlGenerator:
"warning: skipping copy phase strip, binary is code signed"
The copy build phase is set up like so:
I got it working, but there wasn't a straightforward solution. A couple things I did:
I didn't have the exported UTIs set up properly for my application. I looked at the plist of some other applications to see how they did it to fix this.
I had lots of copies of my app all over my system. They all mentioned the same UTI, so there is a possibility that these were confusing quick look. I deleted them all.
I disabled code signing on the quick look target. This fixed the warning I was getting. The ql plugin gets code signed by the application it gets bundled into.
I sent my application to other computer's /Applications/ folder and tested there. Seems like the quick look daemon wouldn't clear it's cache for application-embedded quick look plugins. I may have lost it a little, but it seemed like there might have been something special about dragging the application to /Applications/ and launching it from there that would kick start the quick look daemon.
Some combination of these things caused it to start working.
(Un)Happy coding :(
Related
Get a Unity project with a native low-level plugin .. Mac version.
Make a small change in the Xcode plugin project, and build.
You now have the new plugin library in the Unity project.
If you "Build" again, the final Mac app of course now contains the new library - no problem.
However .....
if you hit Play in the Editor,
it does not pick up the change in the library.
In fact it seems:
Every time you change a library in Unity, you must restart Unity!
Everything has been tried, "Reimport all assets", AssetDatabase.Refresh, renaming, etc etc. It seems you literally must restart Unity.
What's the deal on this?
More information on this:
It would seem that mac shared libraries/bundles cannot be unloaded. Article:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm
Apparently this was fixed in 10.5:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlclose.3.html
Maybe Unity could solve this now. At their usual pace it should happen anytime around 2035.
Sadly it comes down to you can't do anything about it.
As per .net's DLL handling DLL's cannot be unloaded individually without closing the application domain. And while Unity picks up the changes done to the DLL the old version is kept in memory and used at runtime in the editor. A "funny" thing you can do to see this in action is by deleting the native plugin from within the editor. Confirm that you want to delete the file. The file will dissapear from the inspector. However if you right click the folder and refresh (ctrl+r) you will see that the file gets reconstructed (this also happens when hitting "re-import all", as the application domain isn't closed, despite unity restarting).
When building the application it will however use the locally stored file, and not the memory stored file. Hence the plugin being updated on the build.
There is no way to unload an individual assembly without unloading all of the application domains that contain it. Even if the assembly goes out of scope, the actual assembly file will remain loaded until all application domains that contain it are unloaded.
source
This has been a problem for some time now, and people have made attempts for work arounds and/or fixes, but as far as I am aware the "work arounds" that exist now are for windows only. here are some links to discussions about it.
"Unload a plugin"
"Reloading native plugins"
I suppose something that could be done is writing a wrapper that automatically restarts Unity when the dll has been edited... Although this won't solve the issue it'll atleast make it somewhat less of a hassle.
I have developed a Firemonkey app for Windows and OSX. I have also developed an Apple Help Book containing the help for my application when it is run on OSX. (I have a different help system when running in Windows.) Apple's recommended location for the help bundle is in the app's Contents/Resources folder. I can copy the help bundle there manually but it gets deleted every time I run my app in the IDE or deploy my app.
I thought about trying to use the deployment manager but this only allows files to be deployed, not bundles. The help bundle contains a large number of files spread amongst various folders and it would be tedious to set each file up individually in the deployment manager. Moreover, I would have to change the setup every time I added or deleted a page from help since each page is a separate HTML file in the bundle.
So for now, I am manually pasting the help bundle into Contents/Resources. Does anyone know of a more efficient method to incorporate the help bundle?
After much research, I came to the conclusion that the only reasonable way to incorporate an Apple helpbook is to paste its bundle into the app bundle at the location Contents/Resources. I thought about locating it elsewhere but Contents/Resources is where Apple recommends it should go. This is inconvenient because it gets erased whenever I redeploy the app or run it from the IDE. But until Firemonkey is enhanced to make provision for helpbooks, this seems to be the only acceptable way to do it. The program 'Packages' http://s.sudre.free.fr/Software/Packages/about.html is then a great way to package the app for issue to customers.
I've read the tutorial at https://developer.apple.com/library/mac/documentation/cocoa/Conceptual/SpotlightCoreData/Articles/recordLevel.html so many times now, I can't seem to get it for some reason.
I've tried creating the spotlight importer, manually copying it to ~/Library/Spotlight with no success.
Can anyone be point me to a working sample of CoreData-Spotlight-OSX app? a remotely basic thing would suffice.
The xcode template default-stores .importer in the bundle-resources folder, I've read in other places that it should be in a Library/Spotlight folder if the app is sandboxed.
again, tried & failed.
help!
I’ve written a CoreData / Spotlight importer. It’s always a bit of a struggle, even in the best of times. I wrote mine before those docs, and before they’d written the daemon that writes out the records for you. When the CoreData team first did their version of my solution theirs had several critical bugs which prevented me from using it, so I reported them and switched back to mine—I hope by now they are fixed, but this is something to be aware of.
The other thing to know is that a lot of app-makers (including me) have found Spotlight importing of CoreData records is broken on Mavericks, apparently because of changes in the sandbox. This has been widely reported and I’ve filed a bug. If you’re on Mavericks you might be hitting this problem as well.
But, to debuggin:
The first thing you should do is add some NSLogging to your importer, and check your Console after you make a change to your database. Wait to see if any process that starts with “md” (metadata) reports errors, or if you see the logs your wrote.
Also, do a man mdimport and the run mdimport from the command-line on your plug-in with one of the record files. With mdimport’s -g option you can test your importer wherever it is, and with -d4 you’ll get a lot of debugging info.
You can also do a mdimport -L to see if your importer is being seen by the system.
In general, you need to find out ⑴ does your importer work or does it just crash (by running it directly with mdimporter) ⑵ does the system see your importer and recognize that it’s in charge of stubs with your chosen filetype (mdimport -L) and ⑶ does your importer have permission to see the record files (by running your app and watching the Console).
I built a simple app that I'd like to submit to the Apple store, but I am not sure whether my project Release settings are set correctly. I adjust a few things, based on what I could find online, but I might've created more problems than I solved.
I would very much appreciate if somebody could provide a copy of working Release settings which would sure work for my project. I don't store/read any files, the application just runs a few commands. Basically, I just need it to run and install in that /Applications folder so the user could trigger a launch.
Basically use default settings, move your source code to a new project, read up the guidelines and see if anything is told to change, otherwise it's just fine. Cheers.
I have an application to be distributed.
Pretty much everything is self-contained within one bundle so I could just put the bundle in a DMG for the first version-- however this won't work for upgrades, so I figured I'd best work out the process ahead of time.
I've been looking at PackageMaker and it seems straightforward enough. However I have a couple of very specific requirements which may cause problems, and it wasn't apparent from reading the PM docs as to whether this is even possible:
First of all, I want the installer to automatically choose between installing two different versions of the app, depending upon whether a previous version of the application has previously been installed.
Secondly, I don't want to just overwrite the previous application's bundle, I just want the installer to overwrite files within it and add new ones -- in other words, I want certain files within the application bundle to remain from the previous version.
Is this something I could achieve with PackageMaker, or should I look for a different approach?
You can do a lot with an installer package, for example run a shell script which in turn allows you to do everything.
I get the feeling that you're doing it not the Mac way. It's uncommon to store data in the application bundle, normally such stuff goes to ~/Library/Application Support/. I presume that those two different applications are quite similar, why not just set a preference?
Personally, I feel that today a .zip is the best way to distribute your apps. It gets automatically decompressed and shows up with your application icon in the downloads stack. (Only if you get it from the internet, of course.)
For updating look at the sparkle framework. The forst install is just copy the application bundle from the internet and te user then just asks to do update and does not have to leave your application to do anything