I have made an cocoa mac application which can be called by a URL-Scheme. After a while I was unsatisfied by the current URL-scheme name and changed it. But my mac still reacts on the old URL-scheme.
Is there a way to list and even delete (custom) URL-schemes?
Ps. If I release a new version of the application, I am not certain that the URL-scheme is overridden by the new application, can some one confirm this?
Was Googling for a solution to this, saw your post, then was able to solve the problem.
Close all applications and
Open terminal and dump this into it:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
That should do it for you. Worked for me. This will Rebuild LaunchServices to Remove Duplicates for you.
Related
I have designed a GUI that I want to run as soon as I turn on my Raspberry Pi. It is currently set up to automatically log in as user on startup, but if that makes the process more difficult I can change that. My Raspi runs on Raspbian 10 (buster), which has made things difficult since I can only find tutorials for Raspbian 8 or so.
I have tried modifying autostart folder, but it is not in the same location as it was in previous Raspbian versions and doesn't seem to be working the way it used to. Tutorials have said to create a .desktop file in /home/pi/.config/autostart but I don't have a .config folder, or at least it's hidden. For me, autostart is in /etc/xdg/autostart and when I try to create a new file here using nano in the terminal, I get the message [Directory '/etc/xdg/autostart' is not writable] and it doesn't save my file.
I have also tried calling my script in /etc/rc.local but it did nothing. Some have said it doesn't work for GUIs.
Here's what I type into terminal:
$ nano /etc/xdg/autostart/gui.desktop
and a new file pops up, but at the bottom I get the warning [Directory '/etc/xdg/autostart' is not writable]
How can I get my GUI script to run on startup with Raspbian 10 (buster)?
There are a number of issues here, first when you are looking at tutorials recognize that Linux distros are built in layers, for simplicity let's say your "layer stack" looks like this: kernel, systemd, x11, xdg, lxde. The kernel boots, then starts systemd, which then starts x11 (and a lot of other stuff), x11 starts xdg (and some other stuff, I think), lxde is started by either x11 or xdg I'm not sure which.
You want to add something to this process, you can do it at the kernel level (bad idea), at they systemd level (probably not right unless its a daemon), at the x11 level (still probably bad as you still don't have a user session yet), or at the xdg or lxde level.
xdg is probably the right place as it has all you need ( a gui, a user session) while being common (xdg will still work if you switch window managers, probably)
With that out of the way, why isn't your solution of modifying xdg working? It's because '/etc/xdg/autostart' is a system configuration directory. Any changes made to it will apply to all users. You may want this, but the system is trying to protect other users on your system and only allows root to make changes to everyone. If you want to do that use "sudo" (documented elsewhere on stack exchange and the internet). If you want to do it just for you use ~/.config/autostart, (https://wiki.archlinux.org/index.php/XDG_Autostart) you might need to create that directory with "mkdir ~/.config/" and then "emacs ~/.config/autostart"
Would it be better to have the python program run in a terminal window from startup? That way you would see what it is doing in case of errors.
If so, perhaps check this out https://stackoverflow.com/a/61730679/7575617
By the way, in the file manager, hit CTRL+H to toggle viewing hidden files and folders.
I've recently purchased a BeagleBone Black. I installed the drivers, got myself a SD card and an external card reader,7yip and win32 disk imager just like the Beaglebone startup guide told me to. However, when I put my disk on the micro-sd card and insert that into the Beaglebone, I need to tell it to boot from micro-sd.
For that I need to go to the SSH terminal (putty) and type the following:
sudo nano boot/uEnv.txt
In that I need to remove the # at the start of
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
for it to boot off the SD. The first time I did this, it worked. I was just navigating down to the line of code when putty told me that it has disconnected. The next dozens of times I tried to access uEnv.txt, it was completely empty. I don't know why it crashed, nor have I found out how the hell I get it to work. I have unzipped the original file again and installed a new disk several times now, but it's still empty.
EDIT:
Hmm, I've heard win32 disk seems to be unreliable. I'll attempt to use another program, but I don't think that's the problem. But take this into consideration
I found the answer!
I asked a guy I know who has more knowledge in this area. It turns out all this time I was just creating a NEW uEnv.txt file. For all other people who might be struggling with this; The command to open the uEnv.txt file is
sudo nano ./boot/uEnv.txt
The ./ plays a very important role here. From there you can edit the file as you wish.
I hope this helps!
While developing a Cocoa application on 10.9, I have noticed that if I go to ~/Library/Preferences and delete the plist file for my app (to reset it), on the next build-and-run, the app behaves as if the plist file had never been deleted at all.
It took me a long time to track down why this happens and I did not see a question/answer about it on SO, so I'm writing this question and answering it myself to help others.
On 10.9, the system is doing some more robust "caching" of preferences. After deleting the plist file, I fired up Activity Monitor and force-killed the "cfprefsd" process. Be careful: there are multiple processes with this name running and you only want to kill the one running under your own user; do not kill the one running as root.
Doing this seems to flush the preferences cache and on the next run of my app, I get a pristine start-from-scratch launch.
Edit: As reported below, using defaults delete [your bundle identifier] at the command line also appears to eliminate the caching issue. I've had mixed success with this.
I found out that killing the user process cfprefsd will reflush the cache, so your changes will be kept
killall -u $USER cfprefsd
In terminal:
defaults delete com.somecompany.someapp
BTW, I've just released a GUI app that may be more convenient than working with the defaults command:
http://www.tempel.org/PrefsEditor
It works practically the same as Xcode's plist editor, but affects the user's app preferences directly.
To delete all your prefs, you could open your prefs in my Prefs Editor, Select All, then delete them with the Backspace or Delete key, and they're instantly all gone.
However, for this particular task, using defaults delete might still be quicker, especially if you put the command into a text file ending in ".command", and make it executable (with chmod +x). Then you can double click it from the Finder to execute it.
I'm an android developer. I acquired recently a Samsung Galaxy S3 (I9300) and I am having some problems with it.
The error management doesn't work. I mean, when an app crashes, it doesn't show "Force close", the phone just freezes.
I had an HTC before; I use it when I'm developing too, and with the same malfunctioning app, my HTC shows me force close, but the S3 freezes and I have to restart it.
As you can imagine, this is very annoying.
I found a temporary solution, but it affects wifi. Using this app
https://play.google.com/store/apps/details?id=com.issess.fastforceclose&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5pc3Nlc3MuZmFzdGZvcmNlY2xvc2UiXQ..
and enabling "old fast force close" seems to solve the problem, but it has wifi related problems.
Things I have tried
Clean ROM, wiping data and Dalvik cache (it works at the beginning, but suddenly the phone freezes and when I restart, the error management doesn't work any more)
Delete all apps
What am I missing? How can I resolve this?
see http://forum.xda-developers.com/showthread.php?t=1843837 , especially post #8
quoting:
I finally figured out what "Fast Force Close" app is doing to stop the freeze. It does something rather simple: it basically "hides" the /data/log folder, by moving it aside, and replacing it by a symlink. And this then also, causes Wifi to not connect after a reboot (dunno why)
mv /data/log /data/log_backup
ln -s /dev/null /data/log
To "disable" the fix, it just does the reverse.
Anyway, this got me thinking that the solution was somehow related to stuff happening in that folder. And one of the things happening in that folder, on a Force Close, is that it receives the output of the dumpstate command:
dumpstate -k -t -n -z -d -o /data/log/dumpstate_app_error
So, my solution for the "Freeze instead of Force Close dialog" issue is to put some files in the /data/log folder, with such permissions that dumpstate can not do its thing.
I found this to solve the issue, but I don't know if there are side effects.
If you want to implement this, you can do it in many ways (e.g. even through terminal emulator or probably some root file explorer). I'm attaching a flashable zip that will do this for you. (see XDA link)
Apart from some boilerplate code, the essential bit is this (in updater-script in the zip):
ui_print("Apply fix...");
delete("/data/log/dumpstate_app_error");
delete("/data/log/dumpstate_app_error.txt.gz");
delete("/data/log/dumpstate_app_error.txt.gz.tmp");
package_extract_file("placeholder", "/data/log/dumpstate_app_error");
package_extract_file("placeholder", "/data/log/dumpstate_app_error.txt.gz");
package_extract_file("placeholder", "/data/log/dumpstate_app_error.txt.gz.tmp");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error.txt.gz");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error.txt.gz.tmp");
The issue was resolved for me by updating the phone to the latest available android version.
I have been unable to overcome this error in Application Loader. I've quit, restarted, tried different computers - it's like the server is hung up on an op that I never initiated and it won't time out. Has anyone seen it before and beaten it?
Basically, you need to clear out the transport tokens. This can happen if you were to close out of Xcode while in the middle of submitting an app to iTunes Connect.
The token files now appear in the
Library/Caches/com.apple.amp.itmstransporter/UploadTokens/ subfolder of the given user's home directory. Which, honestly, is a better place for them anyway.
Delete any .token files in this directory.
--
If you are unable to find the .token files, this is because they are hidden in Finder. To hide/show hidden files in Finder, use the following Terminal command (TRUE = UNHIDE, FALSE = HIDE):
defaults write com.apple.finder AppleShowAllFiles TRUE;killall Finder
You need to clear out the transport tokens.
Open Terminal on your Mac, and paste:
rm /Users/<username>/Library/Caches/com.apple.amp.itmstransporter/UploadTokens/*.token
That should clear the stuck token. After this, try uploading the build again.
It might be because Xcode crashed as you were uploading your app. Either, all you need to do is delete the token files:
Open Terminal on your Mac, and paste:
rm ~/.itmstransporter/UploadTokens/*.token
That should clear it. If it still doesn't work (at this point you should try re-uploading your app), run that command on Terminal again, or manually go to...
/Users/<username>/.itmstransporter/UploadTokens/
...and delete all the .token files.
Hope that helps!
token was in here
/Users/(user_name)/Library/Caches/com.apple.amp.itmstransporter/UploadTokens/
Appreciated #WrightsCS 's answer It helps me to overcome Application Loader issue.
I would like to highlight one more thing here.
I proceed as per #WrightsCS answer and it resolved Application loader error:
Can not proceed with delivery: an existing transporter instance is currently uploading this package
But I found one more issue after removing all tokens from
/Users//.itmstransporter/UploadTokens/
I went to iTunesConnect and clicked on "My Apps", what I saw a message that "Can not connect... please contact Apple".
Here I don't know why it suddenly stops working!
I submitted the same build which was there on iTunesConnect for submission but it has shown as processing.
After submission of that build, iTunesConnect works fine! Also, I am able to see last uploaded build in a list for submission.
In my case (I am using OSX Catalina), I was not able to find the folder:
Library/Caches/com.apple.amp.itmstransporter/UploadTokens/
Under my user home directory (even when showing hidden files and folders)
but it seems my problem was a bit different and I just closed xCode completely (every xCode window opened) and reopened it again then I archived my project and uploaded it without any issues
maybe this could help someone else fix this issue
You need to clear out the upload tokens that are "stuck". To do this, open the tokens file found in /users//.itmstransporter/UploadTokens/. You should see one line of text at the top that refers to your current upload token. Simply delete this line and save the file. You should now be able to submit your app again.
Cheers