I'm making an OSX screen saver in Xcode (Objective-C, ScreenSaverView class, etc.), and it runs within Xcode correctly. When I navigate to the build output folder and double-click on the the .saver file, it opens System Preferences/Desktop & Screen Saver and asks if I want to install it. All correct.
But when I email the .saver file to myself and open it, System Preferences opens but not to Desktop & Screen Saver and no option to install it is presented. I think it may have to do with the fact that when I build it (with, as far as I can tell, build settings specifying "Release" instead of "Debug"), the output file is still in /Users/Me/Library/Developer/Xcode/DerivedData/ScreenSaver/Build/Products/Debug/ rather than a release folder.
What am I missing here? I have very little experience with configuring build settings, compiler flags, etc.
Edit:
For what it's worth, it seems to work if I compress the output .saver file as a .zip and email that instead. Not a great solution though.
As described in the comment above, apparently it's being built correctly; email messes up binary file attachments so to have it work correctly it should be encoded (e.g. by zipping it) before attaching.
Related
Is there a way to activate Xcode Source Editor option in System Preferences > Extensions? For some reason, it's not showing on my Mac (the last option).
If the Xcode Source Editor is missing from the left pane (see image above), try one of these solutions before resorting to a reinstallation:
In the Applications folder, rename Xcode and then change the name back to Xcode, or move Xcode.app out of the Applications folder, then back in, as described by this Stack Overflow answer.
Move the Xcode app to the Trash and re-install it from the AppStore.
I install the Xcode manually that's why not found on Extensions.
To fix quickly:
Quit Xcode
Rename Xcode in the applications folder temporarily with any name.
Launch renamed Xcode
Quit Xcode
Name it back to the old value ("Xcode")
Go back to Extention you will find the Xcode
The entry is shown if the system detects that both Xcode and at least one Xcode extension is installed. Yet the code to detect Xcode has a few issues.
If you install Xcode first and don't have an extension, the entry is not shown. If you then install an extension, the system re-checks if Xcode is still installed and if yes, it should add the entry. However, the check code will fail in some situations. E.g. if you renamed Xcode.app to something like Xcode_13.4.app (as you need to manage different versions of Xcode), the detection code may not find it. It also may not find it if you moved Xcode to a different location outside of /Applications. And even if not renamed and still in the default location, the detection code sometimes fails and the exact reason why that happens is unknown (it may have issues with certain ownership, certain file permissions, case-sensitive file systems, etc.)
In all these situations, renaming Xcode causes it to be re-detected by the system and then the system sees that Xcode and at least an extension is installed and the entry appears immediately. No need to reboot or start the renamed Xcode; you rename it, you rename it back, and the entry is there and will stay there (even after deleting all extensions, it stayed on my system).
If you first installed any app with an extension and then Xcode, the problem does never appear as in that case you immediately trigger the rename-fix above, because the moment you install Xcode, the system will always detect it correctly (regardless how the app is named or where it is located or any other issue the scan code might have) and detecting Xcode and knowing there is an extension, the menu entry appears at once. The code that detects Xcode extensions seems to always work correctly.
This is probably one of the issues where the Xcode detection code has not been tested very well by the Apple but since it seems to work for the vast majority of users, Apple sees no reason to further investigate why it would sometimes fail.
It will get activated by default if any plugin are added in Xcode.
You have to download XcodeClangFormat plugin from GitHub and follow the installation steps. Then Xcode Source Editor will be visible automatically.
Please refer this link
I'm fairly new to OSX development. I'm currently writing an app which has its own (cross-platform) custom XML-based file type.
I want to write a quick look plugin so that things look good in the finder, and have found the tutorial on how this is supposed to work, but apparently I must be doing something wrong since I see in /var/log/system.log that I get a segfault when my Quick Look plugin is ran. I'd like to see where it's crashing, but I can't for the life of me figure out how to do that.
Where does OSX store core dumps (if it even does that)? Do I need to set some system option or something to enable that?
How do I get Xcode to look at these core dumps?
I'm lost.
EDIT SIP prevents you from debugging protected processes. Because of that, it is currently (at least since SIP was introduced, through Mojave) impossible to debug QuickLook plugins without turning off SIP, at least partially.
As you've probably discovered, since your QuickLook plugin is a plug-in instead of a standalone executable, you need to debug the process that hosts the plugin. To do that, you can hook yourself to the qlmanage executable.
The first step is to make your .qlgenerator plugin available to the Quick Look server. To do that, you need to copy it to ~/Library/QuickLook and run qlmanage -r. The first can be implemented as a post-build action, the second has to be specified in the debug options.
For the post-build action, you should follow these steps:
hit Alt+Cmd+R to open the run configuration window;
unfold the "Build" tab on the left and go to post-actions;
click the plus at the bottom of the window and select "New Run Script Action", and use the following code.
absolutely ensure the "Provide build settings from" is set to your QuickLook extension target.
rm -Rf "~/Library/QuickLook/$FULL_PRODUCT_NAME"
cp -R "$BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME" ~/Library/QuickLook
qlmanage -r
Then, you need to configure Xcode to launch qlmanage:
in the same window, go to the "Run" tab, and select "Info";
in the executable drop-down menu, pick "Other...";
hit Shift+Cmd+G to enter a path, put in "/usr/bin/qlmanage", and select that file;
check "Debug executable" if it isn't already;
move to the "Arguments" tab, add a "-p" argument, and then add arguments as you see fit for the files that you need to preview.
Now, when you use the Run action, you'll be able to debug your plugin through qlmanage.
I haven't tried this personally, but this page:
Debugging Quicklook Plugin in Xcode 4.6
has a description of how to debug your plugin in Xcode 4 - 6. That will probably be much more useful than trying to grub through the core file after the fact.
I have created a Mac app, now I want to add a Preferences to this. I looked up and came to know that I need to use NSPreferencePane. I have created a separate Xcode project for this and it will get generate a .prefPane file. On running this it will ask whether to add to system preferences or not and adds it if selected.
How can I bundle my app and preferences together ?
If I package this as a dmg file should I put both .app anf .prefPane file in the dmg file ?
It sounds like you want to magically (or programmatically) copy the preference pane into the right place (~/Library/PreferencePanes or /Library/PreferencePanes).
If you're going to copy it into your user's Preference Pane folder (i.e. ~/Library/PreferencePanes), you should be able to simply copy it from your Application bundle into there.
If you want to copy it into a system-wide Preference Pane folder (i.e. /Library/PreferencePanes), you'll need to write a privileged tool or helper app that gets Administrator priviledges so it can do the copy. Creating these things is not the most trivial of tasks.
If you are not distributing via the Apple App Store, you could use an installer package to install both your application and your preference pane. The newest option from Apple is "productbuild", which is a command line tool. PackageMaker is Apple's older tool for creating installers, and you can get it as part of the Auxillary Tools for Xcode, available from the Downloads section of developer.apple.com, and there are a bunch of other installer-building tools you could use to ship your Preference Pane with your app, such as "Iceberg".
It would be much easier to simply add the preferences interface to the app itself.
I've just started playing with Xcode 4, and found that, no matter how I setup debugging symbols in the project, Instruments refuses to display source lines for stack trace items that correspond to my code. In only shows hex offsets and identifies my executable as the owning module. Turning on "Source Location" draws a blank too. This occurs even for the skeleton OpenGL ES project generated by Xcode (File → New → New Project... → iOS → Application → OpenGL ES Application).
This problem only occurs in Instruments (I've tried CPU and OpenGL tracing so far). Gdb picks up debug symbols just fine.
Do I have to do something special to see the source code for stack traces in Instruments, or is this a bug in Xcode 4?
So far, I've:
Changed Debug Information Format from DWARF with dSYM File to DWARF.
Changed Strip Debug Symbols During Copy from Yes to No.
Changed the build scheme to use the Debug build instead of the Release build with Instruments.
The other answers are good long-term fixes. If you'd rather not wait for Spotlight to rebuild its index and just need to get symbols for one Instruments session, you can ask Instruments to symbolicate the current session.
Choose File → Re-Symbolicate Document…
Locate your binary in the list that appears. It should be the same name you see on the Springboard. Select your binary and click "Locate."
Go back to Xcode. Control-click on your .app build product and choose "Show in Finder".
This will reveal the directory containing your binary as well as its dSYM file. Go back to Instruments, navigate to this directory, and select your dSYM file. The easiest way is to just drag the dSYM file straight from the Finder to the "Select dSYM" dialog in Instruments.
Finally, click "Symbolicate" in Instruments. You should now see symbols in the traces rather than hex offsets.
I had this issue today and solved it this way:
Edit scheme
Click on "Profile" on the left (this is the important step)
Change Build Configuration to Debug
That should do it. Note that for whatever reason, the build target is not set to the same build configuration as the profile target and this has tripped me up more than a time or two.
Try selecting a different code signing identity, i.e. provisioning profile, for the Release configuration.
I found out what the issue was, as I had the exact same problem.
The answer comes from: Missing symbol names when profiling IPhone application with Instruments
Ensure that you have compiled your code with debug flags enabled (e.g. -g3).
Execute dsymutil on your binary/dynamic library that you want to be able to access the debug information for.
This generates a dSYM bundle folder, and when indexed by Spotlight the debug information necessary is made available to Instruments.
I suppose in your case, it took some time before Spotlight had things indexed - and when it had, then things magically worked out.
It just started working; no rhyme or reason.
I have spent the last half-hour trying to get it to fail again, in the hope of providing a more useful answer here, but I can't, even after recreating the skeleton OpenGL program from scratch, retracing all of my steps.
I did open the symbolicatecrash script in emacs (It has been implicated elsewhere, wrt this kind of problem), and it started working after I did this. But at no point did I change or save it.
It's a mystery.
One reason for instruments having no symbols could be that Spotlight cannot find the dSYM file. So your change from DWARF with dSYM to DWARF is not a good idea. You should change it back since without a dSYM file, you won't get symbols anyway (at least this seems to be the case for Snow Leopard, I have seen reports that some people also got symbols without dSYM files, however, all those people were using Lion). After making the change, make sure you create a clean build (sometimes Xcode fails to generate the dSYM file on my system for non-clean builds).
If you still get no symbols after all that, something is wrong with your Spotlight database. Try adding the folder that contains the dSYM files after a build to the list of folders Spotlight shall not index and then remove it again from that list. This causes Spotlight to reindex the files.
If this also doesn't help, maybe your Spotlight index is completely corrupted. In that case, try the following on a Terminal:
sudo mdutil -i off /
sudo mdutil -E /
sudo mdutil -i on /
This causes Spotlight to first stop indexing your main hard drive, then delete all index data collected in the past and then start reindexing it. The lines above assume that your dSYM files are located on the main hard drive (and not on any other hard drive or network volume, otherwise you must replace '/' with the appropriate mount point of that volume). Give Spotlight some time to reindex before you try again.
In newer versions of Instruments (I have 5.1.1 (55045)), you can add additional paths to be searched for the dSYMs and source code
Open up Instruments' Preferences, then click the "dSYMs And Paths" tab.
Then add your path to the list.
Here's my environment...
XCode 8.2
Mac OS v10.12 Sierra
I had the same problem running in the simulator, and it was driving me nuts because ALL the standard go-to fixes were not working.
What did it for me was plugging my iPad into the MacBook and running an instruments session against said app on my plugged in iPad. Instruments properly symbolicated my app when running on the iPad, and then continued to work when I disconnected the iPad and ran instruments later in the simulator.
I suspect it had something to do with updating my project to use the following...
libsqlite3.tbd instead of libsqlite3.dylib
libstdc++.6.tbd instead of libstdc++.dylib
I don't know why that would be the case, but that was the ONLY project change I had made before my symbols were lost in Instruments.
Is there any way to change Firefox system icon (the one on the left top of the window)?
Precision : I want to change the icon of a bundled version of Firefox with apache/php and my application. So manual operation on each computer is not a solution.
I try Resource Hacker and it's the good solution. The add ons one is good too.
Resource hacker does the job of swapping application icons in Windows (up to XP, not tested with Vista yet).
Available at:
http://www.angusj.com/resourcehacker/
#phloopy's good suggestion to use http://iconpacks.mozdev.org/ unfortunately doesn't work with newer versions of Firefox (I think to the omni.jar change). You can still use their ICO files (or your own), but you now need to do the following manual steps...
Unzip omni.ja in your Firefox application directory.
Delete omni.ja or rename it (e.g. omni.ja.off).
Create directories icons/default in the Firefox chrome application directory.
Copy the icon file you want to chrome/icons/default/main-window.ico
Start Firefox and enjoy your new icon
Notes:
There are other ICO file names you can use for other windows. The ones I have personally seen work are:
main-window.ico for browser windows and Scratchpad
downloadManager.ico for Downloads
If you know others please comment so I can add them. I personally would love one for Firebug and the Error Console. One for Library (Bookmarks) would be nice also (bookmark-window.ico does not work).
Your start time will be a little slower (due to the unzipping of omni.ja). In theory you can jar it up again, but I am not 100% sure that will work once they get the omni.ja optimization working again (it's "broken" in Firefox 10 so omni.ja is actually normal JAR/ZIP file).
If you let Firefox update you will need to do this again
Note many zip tools cannot read Firefox’s variation on the JAR format (see https://bugzilla.mozilla.org/show_bug.cgi?id=605524).
More info is available at http://iconpacks.mozdev.org/docs/faq.html
There are icon packs available at http://iconpacks.mozdev.org/ that work by installing an extension. If you want to use your own icon, extensions are just zipped files so change the extension from xpi to zip and examine the source code and images it contains to customize it. If you do customize it, I suggest changing the GUID that so it doesn't auto-update and overwrite your customizations.
I think you mean the system icon, not the site icon as someone else thought. On a Mac, you can hold-Click -> Get Info on Firefox.app, then drag or paste an image on top of the icon.
I'm not sure about Windows, but I think you may need to compile from source to change it.
If you're talking about the application icon (which under Windows is typically located in the top-left corner of the application's window), then... no... and yes.
Like most windows apps, the icon you see there is probably a resource compiled into the application itself, so you can't change it.
There may be add-ins to Firefox that let you do this, but I doubt it - that icon is trademarked and "identifies" the Firefox "brand" (if you will). So it's unlikely that you could change it at run-time.
Firefox is open-source; you could always just download & compile your own version, replacing the icon resource with your own. A bit dramatic, but possible.