It’s been a long time since I last wrote about SkyPlanner development, but I still kept working on it, enabling lots of new features.
The Telescopes page has been redesigned to include also eyepieces and barlow/focal reduces, and therefore has also been renamed to “Optical Instruments” in your settings menu.

Instruments Page

Adding at least a telescope and an eyepiece will show a new panel in the session pages, with all possible combinations, calculating magnification and field of view.
It will also add a new menu when clicking on a DSS preview image, that will show you field of view circles overlay.

Field of View Menu

Field of View Overlay

Filters have been heavly improved. We have now lots of new filters, and the existing ones were redesigned to offer a better experience.

Now you can filter by object type, by magnitude, time of transit, altitude, constellation, previously observed objects, angular size, catalogue. Filters are available both in the main objects list and in the “Suggested Objects” panel, allowing you to fine tune SkyPlanner suggestions for planning your stargazing night.

The “Suggested Objects” list can now be sorted also by magnitude and time.

A new interesting feature is the post-session report: when reviewing a past session, you can mark as observer each object in your list.

After doing so, a “report” button will appear for that object, allowing you to write an extended description of your observation.

Finally, clicking the “Report” button on the top toolbar will display your report almost ready to be printed. You may wish to click the “Write report” button to write some notes about the whole session, instead of single objects.

Additionally, you can share your report. By default this is disabled, but clicking the “Share” button will make it publicly available.

You can share it with a few options: first, a web address, that you can embedd on your blog/website, or send via email. But you can also one of the predefined buttons for social sharing, on Google+, Facebook, Twitter.

But sharing is now enabled also for the regular session planning: in the “preview with images” section of a planned session you’ll see the same “Share” button.

Lastly, there were a few additions to the objects catalogues, most notably the Barnard catalogue of dark objects.

When programming in C++ it can often happen to be using C-style API.
These usually come in the form:

C

1

intsome_api_call(char*inputParameter,char**outputParameter);

where the return value is never a real output value, but instead an exit code, and usually 0 means success.

To handle such API in a sequence of operations, one is then usually blinded to do something like this:

C++

1

2

3

4

5

6

7

8

9

10

11

12

13

14

intresult=first_c_api_call();

if(result!=0){

cerr<<"Error executing first_c_api_call: "<<result<<endl;

return;

}

result=second_c_api_call();

if(result!=0){

cerr<<"Error executing second_c_api_call: "<<result<<endl;

return;

}

result=third_c_api_call();

.....

and so on, which is kinda boring when you have to call lots of API functions in one method.

I have been trying to write some kind of wrapper that can help making this a bit easier.
In a real life example, I’ve been trying to use gphoto2 api in a c++11 application.
Using c++11 lambdas and RAII this is what I’ve been able to do:

I can then declare some variables in the first part of the method, and inside the “gp_api” block i can execute a sequence of operation, each one returning an int value. This value is automatically checked for an error, and if it it’s a success exit code, the next sequence block is executed.
run_last is finally executed if all steps are completed successfully. An optional mutex locker (QMutexLocker) is passed to the gp_api block as the last constructor argument, to automatically lock the c api for multithreading.

The sequence class accepts a list of runs as construction parameters. These are stored as a class field, and sequentially executed at class destruction.
Sequence is a template class: you can define the return value type, the success value, a comparison operator to check each function result code against the success value, and finally a generic RAII_Object, which can be as previously told a mutex locker, or some other kind of resource to unlock after API executions.

The define directive at the end of the code is used to automatically create a run object which already contains a description of the code being executed (stringified).
You get this description in the on_error callback.

Near my gphoto class I also added a typedef to conveniently call the proper sequence template class with correct template parameters:

Which means that gp_api accepts code blocks returning int values, that the “ok” value is GP_OK (0), and that the returned value must be equal or greater than GP_OK to be considered a success run.
It also accepts a QMutexLocker shared pointer for thread locking.
As you can see in my first example I didn’t assign the gp_api object to any variable; this means that it is immediatly created, executed and destructed, for synchronous run.

Share this:

Like this:

In the last few months I started again deditcating more time on astronomy and star gazing.

To better organize my star gazing sessions I started developing a software capable of suggesting celestial object from various catalogues, choosing them among the best visible ones for the selected date and place, and that’s how SkyPlanner got started.

SkyPlanner has many features useful for visual observations: it allows searching and even suggests many objects from many catalogues, such as Messier, NGC/IC, Abell, Arp, MCG, UGC; provides information about the star gazing session, for instance weather, sun and moon rise/set time, moon phase; allows you to set your own telescopes, automatically estimating each object difficulty for the selected instrument; downloads preview images of the object field from the Digitized Sky Survey Archive, presents additional catalogue information and allows you to set your own notes before and after the visual observation.

The objects list is automatically sorted by transit time, creating a printer-friendly star gazing schedule.

I hope this software will help many of you organizing your best star gazing sessions!

I’m open for suggestions, feedback and error reporting, both in my blog here, or through SkyPlanner feedback form page. A more detailed features list and review is in this page.

A special thanks to Alessia, who helped in many ways, providing suggestions, ideas, testing, writing some catalogues importers, and a very detailed review.

Like this:

This time with more interesting features I hope.
First of all, now Touché is a KDE only application, no more dual releases with Qt-only version. Of course, this may disappoint someone, but this allowed me to add some nice new features, like Global Shortcuts for profile switching.
And profiles themself were improved too, both fixing small problems, and adding a “Default” profile, when no other profile is available.
Default profile will also provide a “fallback action” if some key is not configured on the selected profile, this way you can enable an action on multiple profiles without having to copy it.

Main menu was refactored a bit, It’s nicer and much more well organized.

Code was refactored as well, which lead us to an API for adding new “device modules”, not just HID devices.

And we have a living example too: Wiimote support. You can easly setup a Wiimote as remote control by just enabling it in the “Configure Touché” menu entry, “Modules section”, then by just connecting it. Currently it supports every physical button on the wiimote; I plan to add some other nice stuff too as gestures.

update: with further reading of rEFInd website, I could find a better way to specify more options with only one menu entry. The configuration section was subsequently updated.

This blogpost comes in handy mostly if you have an EFI system (Apple Macbook, but also some Intel based desktops and laptops), and you need a portable USB stick for emergency booting.
I’ve been using System Rescue CD for a long time now, it’s probably one of the best rescue tools around.
It’s a live Linux distribution that can help restoring not only Linux installations, but Windows and OSX too, has gparted as a partitioning tool, can restore bootloaders (such as grub), has network support and ssh server (so you can use rsync to copy filesystem, control it remotely, browse the web to search for help if you panic) but being a live linux distro it may be used in almost every way you like. You may give a look to their homepage to see details.
It can also be installed in an USB stick, which comes quite in handy as you don’t have to carry a relatively big support as a CDRom; nowadays usb sticks are cheap, small and fairly reliable, I always carry with me a SystemRescue usb stick for emergency repairs.

It might however be problematic using it if you have an EFI/UEFI based system, since SystemRescue CD doesn’t actively support it.
For instance, in a macbook you can boot a system rescue cd, but not from usb stick, as the EFI system can boot usb sticks only if they contains an EFI bootloader.
Which is just annoying if you have a macbook pro, but becomes a real problem if you have a Macbook Air, as they don’t have a CDROM Reader.

Another tool I’ve recently discovered is rEFInd Boot Manager, which is an EFI bootloader capable of discovering other EFI bootloaders. Beside being an excellent bootloader it can also be used as a rescue tool, since it might boot your system if your installed bootloader has been misconfigured.

Since rEFInd can directly boot Linux kernels too, if they’re compiled using EFISTUB option (version >= 3.4), and since System Rescue CD does itself contain a 3.4 kernel, can this help us, combining both of these tools in a single USB Stick?

Of course the answer is yes!

Let’s see how.

First, download System Rescue CD, and install it on the USB Stick using these instructions.
Now download rEFInd too, just choose the CD-R Image File on their download page.
Extract rEFInd CD-R Image copying all the files into the USB Stick.
Open/EFI/boot/refind.conf and modify it as follows:

find the “scanfor” commented out line, and add this one (uncommented, of course):

Shell

1

scanfor manual,internal,external,optical,hdbios,biosexternal,cd

At the end of the file, add the following lines (you may replace “it” with your favourite keymap):

And… that’s it! We’re done! Just try it out, rEFInd will show you the three System Rescue CD options, and the other installed operating systems.

You may of course customize kernel boot arguments with the options supported by System Recue CD.

As an optional step, since EFI is supported manily on x64 machines (that’s why I’ve only added x64 kernel boot options) you may safetly remove the various “*ia32*” files you may see around, which should be “shellia32.efi”, “refind/drivers_ia32″, “refind/refind_ia32.efi”, “EFI/boot/drivers_ia32″, “EFI/boot/bootia32.efi”.

Note: if you have one of the awful new Macbook pro/retina/air, which have serious problems booting linux, you may want to add the options “add_efi_memmap noapic” to properly boot System Rescue CD with EFI. I have already included it in one of the submenus.

The most important change in this version is the addition of profiles, meaning you can have multiple bindings configured for each device, and you can switch them by context menu.
This release also features many code reworks, GUI and backend fixes and refactorings opening the way to future new features.

Here’s the full changelog:

Ported build system to CMake

Added profiles, to have different bindings for the same keys

Major code cleanup, allowing to add more engines (next one probably will be Wiimote)

Cleaning up desktop file and appName (fixing some issues with encoding)

Binding keypress and keyrelease events on “Translate to key” dialog

Added “aliases” in keyboard database, so now different device version can be mapped to the same key (example: apple remote)

Now the bad news: both the keyboard database file and the configuration file have changed.

The first one won’t bother you, unless you’ve defined a custom keyboard mapping file. In this case, please contact me, I can help you fixing it, and it can also be added to the default keyboard database file.

For the configuration, it’s much easy to migrate it:

cd $HOME/.config/GuLinux

mv Touché.conf Touche.conf # I renamed it, to avoid encoding issues

now open Touche.conf with your favourite text editor, and replace “[bindings]” with “[bindings_Default]” (or bindings_YourDesiredProfileName).

As i wrote some days ago, I planned on doing some hack so control KStars with a Wiimote.

It turned out KStars isn’t the right target, as it seems to have no plug-in support (and I don’t want to modify core yet, as i’m still in an experimental phase).
But reading data from wiimote and correctly interpreting was already done some days ago, thought it was a little bit hard, so I switched to Stellarium instead.
This is the result: http://www.youtube.com/watch?v=BhVHJJaQ8Gs

Now some technical stuff:
The Wiimote gyro sensors aren’t easy to read, as they don’t send you current angle, but only
It doesn’t report current angle, instead it does report angular speed.
But afterall you can deduce current angle just dividing speed by elapsed time between each message report.
I had to do some tries before finding the proper way of “moving view window” on Stellarium.
It’s not so well documented, and i’m not exactly happy about current solution, but it works, and i’ll ask some help in their mailing list soon.
This solution anyway is easier than i thought, as it only receives as input angles delta, meaning it’s also easy to “align” your telescope to stellarium (just point an object with telescope, then manually point stellarium to that object).
What’s missing: