I just checked, right clicking on the icons as described by Vasconet, does in fact change the size of the icons on Mac OS X as well. But I don't think that is the issue here. It looks like the icons are bigger than their containers. As Jasem said, it is probably a QT issue.

Read More...

So when Ekos connects to any INDI server, whether it starts it or not, Ekos acts as a client for that server. If it connects to a remote INDI server, it doesn’t actually start another one locally, it just looks like it does.

I think the issue is not server related, but client related, if it is the same issue I had tracked it down to before, it has to do with the fact that the client is waiting for replies from the server and if the process is killed while it is still waiting, there is a crash. After I found the issue, I had told Jasem about it and I thought he had fixed it. But we can look again

Read More...

This only happens when shutting down KStars correct? If so I have seen this before. I think it has to do with the INDI server shutting down. I thought we had traced the problem down and eliminated it, but it still probably needs some work. We should look into it again. But no other issues correct?

Read More...

Can you try the 3.3.9 dmg that I just posted in the forum the other day? see if it is still a problem. I don't know that I have seen this behavior before. One way to check it would be to run KStars from the terminal to see if any error prints out. I suspect that there isn't any but just in case.

Read More...

Hi,

Sorry I meant to respond sooner, but it is the holidays and I was on a trip. It sounds like you made great progress! In terms of getting set up to develop INDI or KStars code on a Mac computer, I developed a repo with scripts and instructions to get it all set up. github.com/rlancaste/kstars-on-osx-craft Hopefully this will help you. It sounds like you are just interested in editing INDI though, not KStars as well? My script builds everything from scratch and then optionally prepares a DMG for distributing it all and optionally sets up a development environment for editing the code. That might be overkill for what you are trying to do right now. I might want to make an option that doesn't require building everything, so that someone can get set up to just try a quick change like you wanted to do.

In terms of the first issue you ran into, I would say your main problem was having the driver find the dylibs as you identified. When a driver gets built, it has to link to the dylibs and when it runs, it has to find them based on that link. Your solution was to "export LD_LIBRARY_PATH=/Applications/KStars.app/Contents/Frameworks". You did that before building INDI I assume? That will work as long as you don't move KStars and as long as all the libraries that you need are present in that frameworks folder.

The solution that I use in the distributed INDI drivers in the DMG is to define the libraries' ID's and links as an RPATH and then at runtime, they get the RPATH so they can find the libraries. This does require a couple of extra steps however, so might not be desirable for your application.

Do you have homebrew or craft installed on your computer? Either one of these could be used to get set up to edit INDI code without any dylib issues. Then when you built the software, it would point to the libraries in the homebrew or the craft directory respectively. This is the way I typically will edit INDI code, using either homebrew or craft.

But your solution does give me an idea, for folks who want to just edit something quick in INDI, it might be nice to have a version of the script that would let you use the already existing frameworks instead of building everything from scratch. Let me think about that.

In terms of the second issue, the uint issue you ran into. I ran into the same problem the other day when building the KStars 3.3.9 DMG. Apparently somebody made an INDI change that OS X didn't like. I addressed this as soon as I found it, but I think that was before you ran into the issue. It should be fine now.

As for the real issues you are looking into, the timeout and Serial to USB adapter, it sounds like you have made some great progress. For the Serial to USB adapter, often times you have to install some driver from the manufacturer, you said you did this from the Best Buy website for the Mac driver? I would recommend going to the manufacturer's website instead. Also, maybe try the Serial to USB adapter with another device to test it?

Thanks,

Rob

Read More...

I am not sure because I only found how the current hfr monitoring function works when I started looking into adding the hfr monitoring graph that started this thread. I knew that the checkbox was there, but I don’t tend to use that feature because I typically just start the autofocus myself when I feel it is needed. So I didn’t realize that it mostly did what we were looking for already, except that what I would like personally is a graph with a report as to how the hfr has progressed over time and I do not want it to autofocus itself automatically when the hfr gets to a certain value like the checkbox says currently. I still want to decide myself when to autofocus.

Read More...

I just built a new KStars 3.3.9 DMG for Mac OS X on my new MacBook Pro running Catalina. Please test and make sure that everything is working fine. It is possible that there could have been an issue in copying the files to the new computer and it is also possible that there could be an issue because now I am upgraded to Catalina. Not to mention that there could also be an issue because it is a new version of KStars, version 3.3.9. So yes, for several reasons, please test this to make sure there are no issues compared to previous DMG's.

Thanks,

Rob

www.indilib.org/jdownloads/kstars/kstars-3.3.9.dmg

Read More...

So the reason I mentioned comparing hfr values with focus frames vs light frames is because the current functionality uses a focus frame between each light frame to keep track of the hfr to determine if an autofocus is necessary. The simplest implementation of the idea that was proposed would be to just take what is already there and just log the results on a graph. But if we want to change that to make it use the light frames instead to keep track of the hfr we would need to think about this so that we don’t break the autofocus monitoring that works right now.

Read More...

Right, I forgot to make that part clear. It takes a separate focus image or subframe between each light image now. I agree that it would be nice to just use the light image for the hfr history and monitoring. But one issue I can see immediately is that a longer exposure will make the star appear bigger so using that for monitoring hfr and comparing it to a specific value that was derived from an autofocus image could prove difficult. Not to mention that the light images could be taken using different filters and the star could appear bigger or smaller in different filters due to the color of the star or chromatic aberration of the telescope or filter

Read More...

That reminds me, one thing we also need to consider is what happens to the hfr profile graph that is displayed there now

Read More...

I was thinking about doing this, but I have been rather busy so I haven't gotten a chance. I did look into it though. I found that the functionality is actually mostly already there.

The existing functionality is that if you do an autofocus and then you select the checkbox to have it "autofocus if the HFR > something" then it will take a reading of the HFR between every image using the same star that was used for the autofocus. This is not exactly what we had been discussing, but it is about halfway there. The current function requires you to have done an autofocus and requires you to check that checkbox. Also the current function performs the action entirely in the Focus Module but then does display the result in the summary screen. So one way of looking at it is that the only part of what we discussed that it doesn't do is to display a history of the HFR on the summary screen, it just displays the latest result. If that is all that we want to change, it actually would be very quick to implement.

However, I was also taking some time to think about it. I'm not sure that you would only want this function to work if you had checked that box in the capture module. You might still want to monitor the HFR over time, even if you don't want it to automatically perform an autofocus. Also you might not want to restrict the function to just the star that you last performed an autofocus on. Maybe you want to be able to click on a star in the Summary Screen image to change monitoring stars. Partially, I wasn't working on it because I have been rather busy, but also because I've been thinking about it.

Read More...