Week+of+2-18+to+2-24

Section 10.2 provides various examples and explains useful GUI ideas contained in them. I will not spend unnecessary time making yet another GUI right now, but I will at least hash out the ideas that the author puts forth in this section. The first example shows the concept of having more than one graph in order to allow the user to easily compare two graphs about the same idea. The example used is a program that graphs the position and energy over time of a ball launched out of a catapult. This shows the idea perfectly because you can see at different times how the positions relate to the different types of energy involved in the situation. The author also discusses the concept of using a pop-up menu to choose which things to graph if you are dealing with a more complex situation, an idea that I'm sure will come up when I look at the CMS GUI. Finally, in this example the author discusses the ways that different graphing commands work. Most of them will take the handles as an argument and then will clear the graph before changing the graph. Some more basic ones, though, do not have this capability, which can probably be a blessing and a curse. The next point the author makes also uses the catapult program as an example. He explains that some GUIs could involve processes that take quite some time to compute, once again a concept that I feel will be important to remember when I deal with the CMS GUI. So, in the example of the catapult function, which takes a few seconds to calculate and animate everything it needs to, he suggests that it is not necessarily intelligent to have the program redo //everything// as soon as a single input is changed. Rather, he suggests that the programmer have the recalculation and graphing not be tied to a change in value, but rather to a button which can be pressed after the user changes multiple values. That way, if the user wants to change multiple things at once, he does not have to wait for the program to graph things he doesn't care about each time he changes a single value. I would guess this is hugely important in the CMS GUI because the giant amount of data it handles surely takes a while to deal with. One last idea the author touches on is the display in a static text box of some certain result or conclusion. His example from the catapult tool would be to display a static text box that always displays "Mean velocity (m/s):" and then depending on the calculation will display after that what the actual mean velocity is. Other examples are things like "You win!" or messages to explain an error the user made, for example in the program I just made I could have the GUI pop up a message that says "x min cannot be higher than x max" if the user tried to put the bars in conflicting positions. Chapter 11 is a reference guide for the basic GUI components and the common ways to use each one. The first component addressed is the 'pushbutton' object. It does something when it is clicked, so it usually is used to activate various components of the GUI. He notes the usefulness of various fonts and colors, but warns programmers against going too crazy with either of these because the default stuff and things near it usually looks the most professional and doesn't look just plain crazy. One thing he mentions that I figure is worthy of writing down for future reference is the 'listfonts' command, which apparently shows all the available fonts on the given system. The next component addressed is the 'slider' object. I have already used these a few times, so it's pretty obvious that their use is to dynamically set a value by sliding a bar or by pressing arrows at the end of the bar or by clicking the troughs between the bar and the arrows. The sizes of increments for moving the bar are determined by a two-fold property 'SliderStep' which takes a vector of length 2 containing 'MinorStepSize' and 'MajorStepSize'. Next is the 'checkbox' object. This is a very simple object that allows for manipulation of a binary or boolean variable. When the box is clicked it switches from one value to the other, and the box is either checked or unchecked. Next is the 'edit textbox' object. I have dealt with this one plenty already as well. The user clicks into it and then is able to type text into it. This is essentially the GUI equivalent of the 'input' command. The same things about the font and color apply as did for the 'pushbutton' object. Next is the 'static textbox' object. This is a tool used by the programmer to show information (in string form) to the user which the user cannot edit. Often they are used as labels for other elements, and in this case their tag is negligible which is nice because it makes them even simpler. Their other main function is to output information, very much like a GUI equivalent of the 'display' command. The same font and color advice as other functions also applies here. The author notes that the "Symbol" font is quite useful here because it can be used to display things such as pi, mu, gamma, or other Greek letters. Unfortunately, with this, one would have to cleverly position different text boxes together because two different fonts cannot be used in the same text box. Also, the text can be centered, or aligned left or right with the 'HorizontalAlignment' property. Next is the 'popupmenu' object. This is exactly how it sounds; the user clicks it and then a list of options appears, and the user can click one of them to activate it. This is useful because the object itself doesn't have to take up much space in the GUI, since the menu only has to be displayed when the user is selecting an option. The current choice is always displayed on the object itself, even when the user is not actually using it. The 'String' property contains all the options, and the author warns against accidentally adding in a blank option when programming options. There is a 'Value' property that is an integer which represents the spot on the list that is currently selected. This is how other parts of the program will be able to access the state of the menu and what is selected. It is not a String thing based on the option itself, but rather an integer representing the option's spot in the list. This also means that other parts of the program can change which option of the list is selected. Also, other parts of the program can change the very contents of the list. If one option of the list becomes irrelevant or if a new option presents itself, an option can be added or subtracted from the list by some other part of the GUI. Also, a popup menu is good because there's no need to program in solutions to exceptions since the user can't possibly select anything besides what's right there. Next is the 'listbox' object. In a listbox, __one or more__ objects can be selected at once. In this way it is more flexible than the popup menu. Notably, its size does not depend on the number of options, because it possesses the element of scrolling. The 'Min' and 'Max' properties control how many options the user selects at a time. The 'Min' is how many must be selected at all times and the 'Max' is the maximum number the program will allow the user to select. After the first option, a 'ctrl-click' (or I'm guessing 'cmd-click' on a Mac) selects another option, and a 'ctrl-click' on an already selected option deselects that option. Rather than 'Value" being a single integer for a listbox, it is an array of length however many are selected, with the positions selected listed in ascending order. The next group of objects is 'buttongroup', 'togglebutton', and 'radiobutton'. These are all slight variations on the same theme. They are essentially the same as a popup menu but all options are always displayed and there is a title built into the object. The other main difference between these objects and popup menus is that these objects don't depend on a certain organization and an integer value to represent what is selected, because technically each option is an object in itself rather than just a categorized value. In this way, rather than using integers position values to communicate with the rest of the program, these use the 'Tag' or 'String' of the sub-object. Additionally, with these, the command 'SelectionChangeFcn' can be added to the script from the View Callbacks tab in GUIDE. Adding this command allows the list itself to cause something to happen when the selection is changed, rather than have other parts of the program be responsible for everything. Next is the 'panel' object. This allows multiple related GUI objects to be grouped inside a box to make the organization more user-friendly. Various things can be done with the 'Title' and 'BorderType' properties to alter the aesthetics of the panel. In fact, if the programmer wants no title at all, a blank String for the 'Title' value will just make the border continuous with no space for text. Next, the author addresses the 'uitable' object. This gives the user a 2-D table of elements. I'm sure this is quite useful if any data is displayed in the CMS GUI, since it all comes from spreadsheets in the first place. Tables can be set to be interactively edit-able by the programmer's choice for each column of whether the user is allowed to edit it. GUIDE can take care of the initial values put in the table, but it is often more useful for the programmer to alter the 'CreateFcn'. If you use the ability for the user to edit cells, you must activate the 'CellEditCallback' function in the View Callback menu of GUIDE. Apparently, a column can also act as a checkbox or a popup menu. Finally, I come to the 'axes' object. I am starting to become familiar with this, but apparently it is more capable than I had thought. It is interesting to note that with the plotting commands that do not take a handle as an input it is more difficult to communicate with the correct axis object in a program that deals with multiple. In addition to plotting, axes objects can also be used to display very complex symbol-filled texts. The 'LATEX' formatting commands allow various scientific and mathematical symbols, superscripts, subscripts, matrices and the like to be displayed all nicely organized. This can be achieved by making a text object with the 'axes' object as its parent, a process I will learn more in-depth if I ever need to use it. Also, 'axes' objects can be used to display images. That's all of Chapter 11, and I will dive into Chapter 12 in next week's post.