A Graphical User Interface for Munipack

I had started work on the graphical user interface (GUI) for Munipack year ago. The issue of a first public experimental version including the GUI is ready for downloading. Thus, I think the time to resume of my selected skills with the GUI development is coming now.

Why GUI?

Steps towards development of GUI ripened inside me for a long time. The last story which rouse me was processing of large data sets of images from our digital camera. I scaled by manual way its intensities which was produced a very long sequence of commands with fine-tuning options.

Screenshot of my older terminal

Other reasons:

• simple complex visual manipulation with FITSes
• processing of astronomical data by my students during migrating from another platforms
• it is really shame that we have not a simple astronomical data manipulation tool in 21. century
• command line utilities needs a lot of experiences to work with
• I want save my skills with data processing (any kind of description is not satisfactory with respect to a dynamic actions, a white paper is not a way).
• More simple and interactive way of operations on images.

Not all the aims are included in current versions, but they are planned.

Inspirations

I started work with long time experiences of using ds9 and Gaia. Both are my personal favorites. Unfortunately, both does not fully supports my needs and also the reasons above. Initially, I started work on GUI as a modernized copy of ds9. Lately, I abandoned the way but many of features introduced by the tools are presented.

As a first step, I coded Help window as a simple copy of Gnome's Epiphany browser which can be used to display on-line help. Epiphany was one from first clear designed web browsers.

A help (large)

The Browser window with thumbnails is similar to another Gnome's utility - Nautilus, the file browser.

A browser (large)

The dynamical behavior during image rendering/loading is similar to iPhoto. The load of large images can take many seconds and user is confused when see only a blinded menus or controls. So I used the hook: Firstly display appropriately scaled icon and display a rendered image later. This gives effect of "working application" without confusing of its user.

A view during loading (large)

The design

I designed GUI practically randomly in early phases. A lot of features I'd take from ds9 or Gaia. After some period of frequent redesigning, I found the document Apple Human Interface Guidelines and afterward I cleared concept. By my opinion, the chapter Characteristics of Great Software is on base of work and ideas of Jef Raskin.

The key principles:

• Keep everything simple as possible.
• Don't distract the user from his/her ideas which working on.
• The user is not a programmer. It is expert in astronomy and I is not (not want to be) an expert in programming.

See J.Raskin's rules.

In astronomical processing, the user thinking in absolutely different working framework or technical terms (for example: spectral distribution, black holes, fluxes) than a programmer. So I tried design the GUI in that way. For example, a FITS file is displayed as a tree structure similar with single parts representing every HDUs. User can easy show info about image as well as image itself.

Don't expect that the GUI will cover all functionality of command line utilities.

The programming language selection

The code of Munipack has been developed in Fortran up today. I used Fortran 77 in early days, but now is everything except munimatch coded in Fortran 90. Unfortunately, there is no graphical toolkit for Fortran.

I selected C++ after forethought. The C only is too primitive and too difficult for GUI programming. The Pascal or Ada has poor support of libraries. Go looks attractively (is like C++ with garbage collector) but is not matured yet and also has no support for graphical toolkit.

I abandoned Java, Python, Ruby, etc. for theirs very slow run and needs of a virtual machine. Also, I can not hustle users for installing some additional exotic virtual machines when they have running CPUs. By my opinion, it is very bad idea to write a image processing utility in interpreted language. The counterargument that the development is more fast is fake. I spend approximate same time while developing in Python and C++ under wxWidgets.

Also, theirs run-time speed is important. All interpreters are slow, really slow. The pull of menu is a great action spending many seconds.:) The replace of sub-elements in a window induces a pause for cup of coffee.:) But users have no time. User wants to see their results immediately. The one is less important in GUI elements but it is really important while displaying of large images. The image must be recomputed (rendered) before every displaying.

The operation must be done on CPU because I have not found a way how to done it onto a graphical card (if there is the way, I think OpenGL specification doesn't supports my needs). To illustrate the computations , please try code with loop over 1000x1000 pixels with a simple operation like sum of two real numbers in various languages. I got: C++ under 0.1 sec, Java, Python a few seconds. Because the operations are done very frequently the interpreted languages are unusable for me.

The toolkit

Alternatives for graphical toolkit:

• Gtk+ - With Gtkmm+ may be useful. But relative rapid development and non-platform looks doesn't fit my needs.
• Qt - controversial license. Development depends on one company. Unaesthetic look.
• GnuStep - Very attractive alternative witch offers look, control and behavior like Mac OS X. Moreover it is programmed in Objective-C. Unfortunately, graphical look under Linux is like one from the past.

All others are unmatured and too simple (Fltk, fox, ..) or they are in too many retro-style (Motif, Athena ..).

Finally, I selected wxWidgets. The toolkit offers many amazing features.

Two crucial features for me:

• Portable (multiplatform). It can be run under many possible environments including Unix, Mac OS X, Windows, smart phones.. The library is as the unified layer between portable code (developed by my) and a native toolkit. Impressive! So it looks as a native application. Many additional features like portable configuration support, filesystem managements and many more helpers are implemented.
• Memory management. wxWidgets has two approaches to memory management. Graphical widgets (like windows, controls, dialog.. elements..) are created as pointers and destroyed by the library itself so memory management is done by library itself. Second way is implementation of reference-counting into library core. Therefore all my data I'm using as reference (not pointers) without risk of memory leaks. Both techniques practically does a kind of automatic garbage collector. The memory is checked via valgrind.

The GUI core

I spend a large working time with:

• design and implementation of FITS representation on the top of cFITSIO. I developed a set of C++ classes as representation of a general FITS file. The implementation can be used as a simple library for cFITSIO. CCFits library does not fit my needs.
• I'm using two sets of classes. First represents a original FITS file and the structure is fully used in View window. Second represents a FITS meta object containing only headers and icons without memory consuming bitmaps or tables. The structure is used in Browser window.
• GUI design (see rest of the post).
• Any interaction between different windows controls is implemented by all modern window systems via events. Unfortunately, the implementation is very primitive. Single object sends events to another specified object but it is very difficult to sent the signal to various objects, gets a response and vice versa. The basic idiom used in this context is model view-control. I'm using some ideas of its for displaying of images. But I developed it by little another way and independently.
• Using of threads. One from big problems when I solved. The windowing system runs handlers for prepared actions without interruption. If any action takes longer periods (over 0.7 sec) user can see that the application hangups. This is very confusing behavior. The right way, how to solve, is via independent threads. The application responses very quickly and it pleasure for use when threads are used. It is very nice when more than one CPU (or core) is installed. Than both threads can run on different CPUs to importantly speed up the application.

During hungup (large)

The GUI design

I choose untypical (with respect to ds9 or Gaia) layout as result on many experiments. The View window is divided onto two pars. The left is a control panel where a structure and additional info (histogram, size) of FITS is displayed and the right is for displaying of a contents. The window can show all images, tables and header.

The geometry is ideal for modern monitors (commonly in 16:9 format, Xerox Alto computers are very rare to meet today) when a maximal area of image can be displayed without compromises. The left part is near of other controls (menu or toolbar) to meet a right ergonomy (my personal preference is the close button on the left).

Two important improvements over the ds9 and Gaia are included:

• The image is fitted on the size during load (like iPhoto's). This speed up loading of large images and also the image is completely and perfectly prepared for a quick inspection.
• The image is automatically scaled in intensity. The user probably will see mostly details on the image.

Some controversy can be creating of separated windows for tuning and detail view. Many peoples don't like the behavior. I checked both alternatives, the dialogs included in tabs in control area and the separated windows. Perhaps, the including is too restricting. The windows has limited space so you can't freely move or size windows. The layout and labels must fit the space. You can't have opened both windows together etc. A useful discussion can clarify the layout.

A detail (large)

Bugs

The current version is relative stable but it was not tested on wide range of software configurations or operating systems. Therefore I expecting a lot of bugs to fix.

The are two channels to report any bugs:

• The issue tracker under Google code. You must have OpenID account to use it. You can also use the tracker to request of new features.
• When application crashes, the application shows an dialog with a log which can be used to directly report to my ftp server. The log can contain some private information. Please check directly that the info can be read be me and when you will accept to pass a (really) small info about your configuration, please send the report.

A crash report

You are also welcomed to Munipack's Google groups where you can report bugs or discuss more detaily other aspect of Munipack and the astronomical processing.

Discover of a New World

The detailed structure of FITS files reveals a new world for me. With help of the one, many FITSes shows unexpected additional features. Do you know that DSS images has two parts? The use of the parts is trivial not a complicated. The structure of FITS is displayed as an integral part of FITS world so users are not surprised by the complicated structure. Especially, it is important during inspection of any unknown file.

Horse nebula (large)

Unimplemented features

• List mode (don't show icons, show table with files) in Browser. It is probably useless, because thumbnails are not visible. I'm hesitating with its support.
• Orthogonal intensity scaling. The well behaving applications has orthogonal controls. That means, that when one tune a quantity, other quantities are not affected. Unfortunately, the intensity scaling in not implemented orthogonally. The image is brighter of darker by using of both sliders. I have no idea how orthogonalise it.

Please, keep in mind that everything can be changed.