For this project, me and a fellow student had the idea of basing it on the example illustrated in Fig 1 below.
Fig 1: From Wikimedia Commons
We mailed our teacher and asked if we could both work on this, and were told we could, as long as there was a clear distinction between our work. He suggested one of us could do the simulation / processing, and the other could make a GUI. After discussing it for a bit with the other student, we decided he would do the processing, and I'd make a GUI.
I decided to make a standalone GUI to begin with, and then integrate my fellow student's work into it. Download the project files here
First, open root, then load the program with ".L Standalone_GUI.C" and start it by typing "go()".
Fig 2: Standalone GUI at start-up
The GUI consists of the following features:
The program is built on a Mainframe, with elements in it. The canvas is an embedded canvas, and is implemented using "TCanvas *name = EmbCanvas->GetCanvas();". Below the canvas is a horizontal frame, in which the control-panel is placed. The four graph buttons link to four different functions, in this case these are just dummy functions, having nothing to do with radiation. This goes for all controls in the GUI, they don't do what their names would suggest, but they do affect the functions, as can be seen in Fig. 2, where Graph2 has been pressed for different parameters.
Fig 3: Graphing Graph4 for different parameters
The drop-down menu was added with the idea of the entries correlating to a specific energy of a beam. The idea was correlating the entries in the drop-down menu to a line in a file, by using "AddEntry();" and the int value from "GetSelected();" for this standalone GUI though, dummy entries were added, and the int value gotten from them were used a factor on the functions, just to show that changing it affects the graph.
Next to this is a numerical entry accepting double values, with controls on the right that ups the last number by 1. This is placed within its own group frame, to get a title indicating what the numerical entry is above it. The selectors next to this are both radio buttons that allow only one input, that correlate to a value, like for instance the absorption coefficient of a material, mu. This is achieved using the id of which one is selected to assign a specific value to a variable. At the end of the control-panel, there's an Exit-button that quits the program, and ROOT.
There were some hiccups making this GUI that are worth discussing. The way to use the control-panel is not the smoothest. Pressing a button to display a graph is fine, but it would be better for the functions to be updated when the parameters are changed directly. A solution for a single graph would be linking each control to the graph-block, but this wouldn't be as easy for multiple graphs.
The integration of the value from the drop-down menu and selectors leaves a bit to be desired. The drop-down does not actually correlate to a value found in an entry, it only fabricates a value from the number of the entry. The selectors also correlate to hard-coded values, they're not flexible inputs.
They say beauty is in the eye of the beholder, but as far as this beholder goes, the layout of the UI could've been improved. Using kLHints allowed for the buttons to be placed and padded somewhat neatly, but in retrospect, a vertical frame containing more sub-frames with the control-panel would probably have been a better solution.
Now, to implement the code Marius Nevland wrote, which in its entirety can be found here
My standalone GUI has some redundancies for the functions Marius wrote. His project was based on graphing the intensity and attenuation using any absorber material, for gamma-radiation. This makes both selectors in the GUI obsolete. He also allowed for the element to be written in by the user, either by it's Z or name. Therefore, the drop-down menu is not needed, and a text-entry field for the material, as well as an additional numerical entry for photon-energy. He solved for the allowed energies by using an interpolation method on the users input. For the theory behind these, see his project.
Taking from, and adding to Standalone_GUI.C, this is the layout for his simulation:
Fig 4: The layout for the modified GUI using Marius' scripts
For this to work, a .txt file called element_data.txt is needed, as well as .txt's for the elements to be used. For my testing, I used Carbon.txt and Magnesium.txt, both of which are included in the project archive above. To test with other elements, download the project files of Marius' project.
The text-entry works in a similar manner to the numerical-entry, but despite several attempts and troubleshooting, the string gotten from it could not be implemented with Marius' code. The programs Marius wrote used the command line as the interface, where the user wrote either an elements atomic number Z or its chemical name (not case-sensitive). The goal was to simply replace the code where the user input (cin) appears, with Get(); functions on the UI input. This worked fine for both thickness and photon-energy, but the string input didn't work.
To test that the rest of the implementation works, the shell-input lines for the absorber material code has been retained. Pressing the Intensity / Attenuation button now prompts the user to input a material name or Z into the shell used to start root. This work-around is very clunky, as it requires the user to change window, enter Z or the name of the element, and press Return twice. It's made even more clunky by the fact that the user input is not visible, so if the user is typing elements by name, they're doing it blindly.
Fig 5: Intensity graph for Carbon
To get the graph seen in Fig 5, I loaded and started the program, set the thickness and photon energy, and pressed Intensity. Then I switched back to the shell, wrote "6" and pressed Return twice.
Fig 6: Attenuation graph for Magnesium
Similarly, to get the plot in Fig 6, I pressed the Attenuation button, changed window, wrote "magnesium" and pressed Return twice. We see that with the exception of the user text input, the implementation works fine.
Marius later updated his functions to allow multiple graphs to be plotted at once. The GUI program does not work with this, as the input-fields become bugged when linked to a MultiGraph, as seen in Fig 7.
Fig 7: Bugged control panel when using multigraph
Though the implementation of Marius' work didn't quite pan out as it should, the project worked fine. The main goal of this project was to create a generic GUI with various types of inputs, all of which should affect the plot, which is what is seen in "Standalone_GUI.C". The framework involved in making a GUI in ROOT shows ROOTs practicality when it comes to scientific programming, as it makes heavy use of ROOTs functions.
Working with another person's code wasn't quite the success I'd hoped it would be. It would've been beneficial to know the ins and outs of Marius' code before I went to work implementing it into my GUI, and we should perhaps have communicated more, but then again we did set out to make two separate projects when we started. The parts that did work though, taught me a great bit about scientific programming, and programming in general, as both C++ and ROOT were completely new to me. Specifically, seeing how classes and functions works in C, and how I may implement someone else's script into my programs (and what pitfalls to avoid) are great lessons for future projects.
Thanks to Ladislav Kocbach and Boris Wagner for teaching me this stuff, and to the good folks over at ROOT's website, especially whoever wrote these great tutorials!