Users of iObserve, you all have certainly tried the main Coordinates converter, located in the « Converters » section. And you also know that it loads all imported stars from the database, filling up the memory.
Surprisingly, I never knew what to really do for making this pane useful. Just recently, a friend of mine (and a very efficient bug reporter…) enlightened me! I will stop loading objects from the DB and allow to import coordinates from a file. Obvious, isn’t it? I’ll also add the obvious counterpart which is the export of the converted coordinates.
The most geeky of us have certainly wondered about a command-line helper / utility, that would ship with the main app. It would be great, indeed. As for now, I don’t know if it is possible inside the MacAppStore. But it is on my « do if possible » list.
An interesting feature request from a user of my power tabs KPCTabsControl on OSX: make them vibrant in Yosemite. The effect is subtle, but I managed to implement it. It requires some additional work though before release, to make sure the core feature of KPCTabsControl continues to work on older versions.
On Yosemite, make sure to use a NSVisualEffectView as container view, and that this view is layer-backed. The demo app will have everything for you to check.
That’s it. I managed to implement options for QLFits3, thanks to the fantastic help from the BetterZipQL developer (Thanks Robert!).
It has been quite an interesting challenge! Now a tiny “config” app is bundled with the QL generator and is running un background, listening for some custom URL scheme whose content is formatted in such way it is transformed into key-value pair, which in turns is saved inside a pref file…
Let me know if it works for you! The one-line installer:
QLFits is certainly the most well known of of my software. It all started just before iObserve, actually, back in 2010! Long ago, when QLFits was in version 2.0 (or even before, I think), there was the possibility to customise the output. This is a requested feature again. And indeed, some people want to customise the output, not really the look of it, but rather the presence, or not, of the headers, by defaults.
Given the very small amount of documentation that Apple is providing on that matter, I am struggling a bit alone. However, I got help from the developer of another great QuickLook plugin: BetterZipQL. You must definitely grab it. It’s free, and provide invaluable insight of your zipped files.
Let me introduce a new open-source project: SwiftVOTable, a simple VOTable parser written in Swift. It is really work in progress, but I am developing it for a coming app… Pretty nice to learn Swift finally!
iObserve 1.4.2 has just been pushed for review. This update fixes two small issues with manual coordinates for new objects, as well as the webservice URL for individual exoplanets. This should prevent the planet mass and other important parameters to disappear upon update. Oh, and the buttons (and other small visual tweaks) in Mavericks have been restored in their previous shine… Interesting to realise that many users are still on Mavericks! I guess you all wait to be sure that iraf, MIDAS, ds9 work as usual on Yosemite…
A workaround for the people trying to enter manual objects in iObserve 1.4.0 and 1.4.1: until the fix is available, enter the name of your object in the first tab, and then the coordinates in the third. You object will be imported.
While developing this new website, I was wondering from where my visitors were coming. The squarespace site make it easy to grab this information. And clearly, people find it directly.
This corresponds basically to what I think since the beginning: iObserve gets its reputation (and downloads) mostly through word-of-mouth. That’s great because I have not enough time and energy to spend for promotion. I did it once however in the famous ‘astrobetter.com‘ website: here, with a follow-up here.
By reading again the comments, I am horrified by the amount of things I promised I’ll develop inside iObserve. These are usually still in the to-do list, but overwhelmed by the new stuff. Achieving a complete release of a software is an exercise of trying to put a storm of complexity into a fairly solid box, and say: look, you can now surf on it! That’s particularly true for an app such as iObserve which has more than 80k lines of code (and many custom connectors to crazy webservices, yes, I’m looking at you JPL horizons…).