Oh, here is what the breeze icon theme looks like on OS X. I didn't find all the icons yet, so a couple of them are oxygen (since I made those the fallback)

That looks fantastic!!!! Please send me a pull request (or patch) for the theme inclusion and change. Great work Rob!

BTW: I just pushed a commit to fix the CachingDms build bug. Thanks for pointing it out. Please see if you can now build.

Regards
Akarsh

Ok sounds good. I should be able to do that after work today after I finish tracking down the last couple of icons. I will leave oxygen as the theme for now with breeze commented out so all you would need to do to switch would be to comment out oxygen and uncomment breeze. Oxygen looks better for now, but others have potential. I think it would be neat if that were a setting in the preferences. Once you guys see how I did it you can see what you think of that idea.

So I finished tracking down and solving as many of the icons problems as possible. My patch is complete and sent to Jasem via email. It should fix all the icon issues that I found on OS X and on some Linux distros. The icons should still work even with no theme installed. I also built in two modified custom themes based on both oxygen and breeze, but I set it so that it should load the oxygen icons. We might want to make that user configurable. I could also add more possible themes, which could be interesting.

Here are 3 comparisons of the two themes I implemented

for anybody who is following along, I worked with Jasem to get my changes merged and now he is currently working on it. We decided to go with the a fallback theme of Breeze on OS X and other OSes without themes working.

Great work with the icons! I really like that you choose breeze as default now as it fits the general OS X look quite well I just build it and it works great!
I still have some issues not related to the icons though:

First, when running kstars from the terminal, the output starts normal but then it goes crazy. It first prints several hundred lines of:

NOTE: This EquatorialToHorizontal overload (using dms pointers instead of CachingDms pointers) is deprecated and should be replaced with CachingDms prototype wherever speed is desirable!

and then several hundred like this:

Assert in Projector::toScreenVec failed!
using AltAz? true Refract? true
Point supplied has RA0 = "18h 33m 15s" Dec0 = "-9° 41' 15\"" ; alt = " 29° 00' 52\"" ; az = " 187° 19' 27\""
dX = nan and isfinite(dX) is false
Y = 0.506926 and isfinite(Y) is true

The full output is in the attachment.

Second, the azimuthal grid has a graphics bug as seen in the attached screenshot. The point to which the top of the grid seems to converge is always the same relative to the screen (it moves relative to the stars).

I also have some remarks to your instructions on things I had to change to get it working which I think are related to OS X 10.11+:
Because OS X 10.11+ has a system integrity protection, the /usr folder isn't user accessible. For custom software, the /usr/local directory is used so I had to change the install prefix of cmake to /usr/local when building libindi for it to install properly.
For kstars to find libindi during the build, I had to install pkgconfig using homebrew.
And last, to make kstars work, I had to symlink all files in /usr/local/share/kstars/ (I installed kstars to /usr/local instead of .kde) into ~/Library/Application Support/kstars/ using "ln -s /usr/local/share/kstars/* ~/Library/Application\ Support/kstars/" (which is also described in seanhoughton's gist but the command there didn't work for me).

I can confirm this bug, it seems it was caused by one the recent changes from one of the developers. We're working on it.

Awesome Adam, you got it all working!!

I haven't been running Kstars from the terminal, I have been using an app I created using Xcode.

Yes, the cachingDMS errors show up on mine as well as does the Assert errors. I know the cachingDMS error is not OS X related, but I don't know about the Assert error. The bug with the azimuthal lines is new. I saw that last night for the first time. I'm not sure what that is. I am just leaving them turned off until they solve it The amended information is very useful, thank you. I would like to see all the kde stuff as well as indi get wrapped up in the app bundle, but for now I'm glad its working great.

One issue you may not have encountered yet is that the download new stuff dialog box doesn't work because it doesn't want to load the https page for some reason. That one I was trying to solve, but haven't figured it out yet.

Another thing you will probably need to do is to make sure that you tell kstars where to get the xml files for the indi drivers in Ekos.

I hope to make a more completed list of directions. Thank you for the updates.

The CachingDms error is mostly a note for us developers. It has no real consequence on the functioning of KStars. It's just a warning that some trigonometric functions are being pointlessly recomputed, which is expensive if it is happening in the innermost loop with many stars, but is a non-issue otherwise. I've made sure that it doesn't happen in star rendering, which is bulk of the trigonometry that KStars does.

The assert failure, however, is more serious -- and I do not have it on my system. Could you tell me which projection you were using? Were you using Equatorial Coordinates ("Star globe view") or Horizontal Coordinates ("Horizontal View") in the view menu? I don't see that happening on my laptop (in debug mode, the assert failure would lead to a crash, and KStars is not being very crashy on my laptop)

Regards
Akarsh

You are correct, in debug mode, it does lead to a crash, which is why I have been running it in release mode. The error appears in horizontal mode as kstars is starting up. In star globe view it appears to not occur.

Hi

Unfortunately, I don't have time to work on this today -- I'm about to leave for an astronomy trip, so there's all the packing and stuff. If I do have time to work on it during the day over the next few days, I will. But if someone else wants to look into it sooner than I can, please do so.

Workaround: Avoid altaz grid and horizontal coordinates.

Some developer information: While I believe that the transition to CachingDms could be responsible for this, I haven't found any immediate evidence. The problem seems to be:
1. A line that returns a Vector2f(0, 0) in Projector::toScreenVec instead of failing an assert and crashing (added in Android transition efforts)
2. A call to NoPrecessIndex::JITUpdate() seems to mangle the azimuth. I guess this is the effect of calling HorizontalToEquatorial and then EquatorialToHorizontal when altitude = 90.0 (i.e. when alt = 90, azimuth is indeterminate).
3. It should be okay to set the azimuth to something finite just so computations don't turn out to become NaN all the time -- but I would refrain from doing it in toScreenVec, since it is called a million times per draw under certain settings.

Regards
Akarsh