Now that INDI and XPlanet seem to work pretty well. The next one that will need to be done is astrometry, which we can take a look at later this week I think. Also as I said before, we probably should try to figure out why the versions compiled on Sierra so far have said "Illegal instruction: 4" when the CCD is exposed in the Capture module when using preview, but no such error is generated using the same driver in the Align and Focus modules, nor is this error generated when using the version I compiled on my old Mac.

I just tried editing Jamie's script to process the xplanet files and the astrometry files the same way it handles the Indi files, so everything is wrapped up nicely in the app. If I did it correctly, then it *should* do all the install name tool and file copying stuff that I did last night by hand to make xplanet work. Now, I am going to test it out on both of my laptops and see what happens. (And possibly revise it when it doesn't work ) Wish me luck!

I did attempt to edit Jamie's script to handle xplanet and astrometry. I think I was mostly successful. The first time I tried to run the script though, it ran into some errors because the install_name_tool wouldn't work on either set of files due to file permissions. Once I changed the permissions on the items in the astrometry bin and xplanet bin folder in homebrew to 755, however, the script had no problem with that. Running the script on my new computer still causes the Capture Module crash on My wife's computer, but running the script on my old computer does not cause the crash. I still haven't solved that one.

After I ran the script on my old computer, I still had to copy libnova, libinidi, and libcfitsio to their correct locations. (This might have something to do with my old computer, I don't know) And when I tested xplanet, I found that it had given the wrong file path for the two dylib dependencies. I had to manually run:

install_name_tool -change @executable_path/../Frameworks/libjpeg.8.dylib @executable_path/../../../Frameworks/libjpeg.8.dylib /Users/rlancaste/Desktop/kstars.app/Contents/MacOS/xplanet/bin/libtiff.5.dylib
install_name_tool -change @executable_path/../Frameworks/libpng16.16.dylib @executable_path/../../../Frameworks/libpng16.16.dylib /Users/rlancaste/Desktop/kstars.app/Contents/MacOS/xplanet/bin/libfreetype.6.dylib

After, I made all of those changes, everything was mostly working great! So, I decided to run a couple of tests. I tried copying the GSC data folder to my wife's computer's kstars folder. It didn't work. I finally figured out that we need to copy the gsc executable into the Indi folder inside the app. It was no big deal after I figured it out. Since I now had fake stars on my wife's computer, I could run astrometry on them. I cannot test the offline solver on her computer yet since she has no python or pyfits. But it worked in the online solver. I also tested running an indiserver with simulators on my computer downstairs and connecting to it remotely from her computer. It worked great!

So, I made progress, but there are still some stumbling blocks. However, the good news is that I have a fully working latest-version KStars.app compiled just today with support for xplanet, Indi, and gsc. So now you can test with fake stars, or maybe even with real ones if you connect to a real Indi server running equipment--I haven't tested this yet. I will post about that next.

Here is the latest version of KStars, compiled and working with INDI and xplanet, and GSC support on OS X.

drive.google.com/file/d/0B_ivMJINsdQ8d2J...czg/view?usp=sharing

As I mentioned in my last post, I added gsc support to this app. All you need to do to get fake stars in the KStars CCD Simulator, is unzip the following file and put the gsc folder it contains into ~/Library/Application Support/kstars/. The zip file is about 240 MB, but it is worth it for testing purposes.

drive.google.com/file/d/0B_ivMJINsdQ8cDh...Z0E/view?usp=sharing

This version does not yet support the offline version of astrometry fully, since I haven't had time to solve that one yet. But online astrometry should work great.

So more good news. Apparently, the work I had done last night with Jamie's script to get the Astrometry files packaged up DID in fact work. There are just some unmet dependencies. In order to run, Astrometry also needs python, pyfits, and netpbm to be installed on the machine.

I found a nice installer for python that worked well without needing home-brew or anything to be installed on the machine from www.python.org/downloads/ : www.python.org/ftp/python/2.7.13/python-2.7.13-macosx10.6.pkg

After python is installed, all you need to do is run "pip install pyfits" from the Terminal and pyfits will get installed, no problem!

Then I found I still needed netpbm. I searched a little but could not find a nice installer for that. Perhaps a little more looking is in order. For now though this procedure: macappstore.org/netpbm/ worked:

ruby -e "$(curl -fsSL raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null
brew install netpbm

Of course running that installs home-brew and the OS X command line tools, which is something I would like to avoid to make things beginner friendly.... However, it worked perfectly!! I was able to plate solve images on my wife's computer using the Align Module and using the fake stars of gsc.

Note that Python is installed by default on OSX; it's used by the OS. On my El Capitan box, python was installed at /usr/bin/python, and is version 2.7.10.

For some reason, pip is not installed by default in the OSX version of Python; you can get pip at bootstrap.pypa.io/get-pip.py or you should be able to sudo easy_install pip

Oh ok, I assumed it was the lack of python in general, I guess it was just the lack of pyfits that was causing the problem. Thanks!

I just solved another problem!

For a long time I have been trying to figure out why the Image Downloader in the details window does not work, giving an error about not being able to find http in any .service files. I knew the issue was with the kde plugins for the internet downloads. I just didn't know why it was a problem. It turns out all we need to do is simply copy all the files from the directory ~/IndiRoot/kstars-emerge/lib/plugins to ~/IndiRoot/kstars-emerge/Applications/KDE/KStars.app/Contents/PlugIns/

I tried that and it just started working!

I will have to test it on my wife's computer though.

I tested it on my wife's computer and the image downloader did not work unfortunately, but I understand why and I have started trying to fix the problem. Running the emerge/craft made the KStars app hard linked with some of the programs and libraries in the INDIRoot folder. On my wife's computer this file structure does not exist of course. Because I didn't have the image downloader that uses the other KF5 programs working until just this evening, I didn't know they were not working properly on her computer. The issue is that we need to copy more than just the plugins folder. We also need the program kioslave, which of course will need to have the install_name_tool run on it. I did manage to do that manually and that part worked. And there are a couple of other programs and dylibs in the app bundle that still need to have the tool run on them too in order for the image downloads to work on her computer. Luckily I have Jamie's script for automation. I copied the section where he did the install name tool so that I could run it on folders/programs that need it run in a fast and automated way. But there are more I haven't done yet, so It will probably be at least another day till I have the image downloader working on a non-development computer.

I have been looking at this website, which is the script that Kate uses to finish up their Mac app. It is possible that, if we set the right flags and environment variables, the macdeployqt program could do some of the file copying and install_name_tool changes for us, since I believe that is largely what it is meant to do. github.com/KDE/kate/blob/master/mac/emerge-deploy.sh

I am working on getting these changes into Jamie's script as best I can. I hope Jamie gets well soon so he can check my work . Through experimentation I found out that for the macdeployqt command, -executable does seem to work well (at least it seemed to do something for kioslave) and we might want to do some more with that. the -extra plugins command did nothing really, except break the deployment step because it did not recognize it. I ended up just copying the plugins and that worked fine.

I am actually traveling again, in Sweden this week.

Don't forget that you are listed as a contributor on the github repo - make a branch (not a fork) for your changes, and check them in! when you have it where you want it submit a pull request, and I will do some diffs and perhaps comment on enhancement.

I should be able to look at it next week

Ok, sounds good. Thanks Jamie. I will try to do so. I haven't done it before so we will see how it goes. I will probably do a little more work on it tonight before I try to post it.