Proposal to upgrade the UI of Gcalctool
The main goal of this project is upgrade the UI from its current look to a look that is more reflective of the black, white and grey colour set used throughout GNOME. This will not only create a unified experience throughout GNOME, but will make it much more pleasant for a user to use. the base code from the original Fortran translated coding into one that has the various bugs fixed and at the same time changes the UI to one that reflects a more elegant and appealing UI. This is especially important for users to continue to use this application and not abandon it for a potentially better application that may be out there. For the UI change, I will take inspiration from this page: https://live.gnome.org/Design/Apps/Calculator where there is already an image showing the relevant art and the ideal new UI for the application. In addition to this UI change, an optional goal would be to redo the base Fortran translated code by taking inspiratio from the bugs that are mentioned here: https://bugzilla.gnome.org/buglist.cgi?quicksearch=product%3A%22gcalctool%22+ and the idea is that by fixing these bugs and changing the UI, there will be a dramatic usability increase. Finally, C and GTK+ will be used to do this from a coding perspective.
In order for the base code to be upgraded, the major modules concerning basic, advanced, financial and programming mode will need to be looked at in detail in order for the bugs that have been mentioned above to be tested and fixed. More specifically the following is to be ideally done: The entry field’s size will be increased to accommodate more digits, specifically more than 9 so that it is much more easier for a user to input large digits without resizing the window. In addition, two new keys (= and enter) will also be added for confirmation of operations which is more easier than dragging a mouse to the equals sign every single time. When large, complex calculations are performed the entire program becomes unresponsive and a user is unable to tell if application has hung or if it is just unresponsive for a bit. The solution is to implement a spinner similar to the one seen in Cydia for jailbroken iOS devices as shown here: http://ipodtouchtricks.net/wp-content/uploads/2010/08/cydialoading.png. This will inform the user that the application is not hanging but is actually calculating the answer, and in addition will allow the background changes to the input box based on the answer. These were three major obstacles in radically changing the look of the UI. Currently the theme used is in stark contrast to GNOME’s colors which distracts away from the flow of each application that comes with GNOME. In addition to this, the current colors have been the same for while and are also slightly dull. So a rejuvenation is required in the entire color scheme similar to what is shown here: https://live.gnome.org/Design/Apps/Calculator. This can be further modified by taking inspiration from the Mac, Windows and QNX (Blackberry Playbook) calculator applications. A change in the placement and spacing of the buttons currently has to be changed slightly so that it feels more natural to every user since it will be similar to what they have used before in other operating systems as well as on their physical calculators. In addition to this change, an extra window space above the input box has to be added which will act as the history of calculations done since opening the application. This will allow a user to be able to clearly see what their input was and check if they if any mistakes were made in their input. In addition if they lose track of a previous answer they will have an entire history to scroll through for it. Last but not the least specific portions of the documentation will have to be redone to reflect the changes mentioned above. This is in addition to skimming through the entire documentation for any possible mistakes.
Once the above goals have been completed, there are set of minor changes that can be made which will make the entire program better. As mentioned above, when complex calculations such as ones containing large exponents or exponents with decimals in it, will cause wrong calculus to be performed as well as hang to occur in the entire application which I suspect is due to an overflow happening since the answer becomes larger and larger through the process. It can also be due to truncation but this will have to be examined in detail. There is also a certain lag seen when switching modes which is about 2 seconds which is probably due to an inefficient way of calling the next module or class that has been used for the mode being switched to. So in short the running time will have to be reduced for this mode change.
History box listing previous calculations done
Large input box that will allow more than 9 digits to be entered
Addition of = and enter key for confirmation of calculations
Spinner during large calculations to show application is taking time to do these complex calculations
Layout change of the buttons to be more similar to calculators on other operating systems
Theme change to be more natural and pleasant
No errors during complex calculations
Virtually no lag during a mode change
Week 1: Get to know specifically which mode belongs which module and the other modules linked to these main modes. In addition to this, further improve my knowledge of C and understand GTK+ as a whole.
Week 2-4: Add a history box right above the input box that will be scrollable. This will be limited to about 6-7 set of calculations only and will hold two sets of calculations in one look.
Week 5-8: Implement spinner similar to the one linked to above during calculation that are taking more than a second to solve due to the largeness of the answer involved. Ensure the spinner does not conflict with the GUI of the application and the changes to the code implemented previously.
MIDTERM SHOWABLE WORK: History box should be successfully done and working. In addition, the basic framework of the spinner should be completed.
Week 9-12: Focus on the input box and fix the input size, digit limit and the acceptance of = and enter as confirmation of the the operation inputted and selected by the user. Test these changes by rolling them out as a patch to a small group of my mentor, and another person that will be chosen in consultation with my mentor so as to confirm that they work.
Week 13-14: Document all changes done above and begin fixing any documentation errors throughout the program.
Week 15: Implement the optional changes mentioned above if no incomplete work is left from the above weeks.
I’m studying Software Engineering at McMaster University and am in my second year of the program. I have programmed for the last 6 years in Visual Basic, Java, C, and C++ which means I have the perfect set of skills for improving this program to an even better level than what it is at currently. I am an enthusiast for free software which is why my blackberry app that I designed for the blackberry playbook is for free (it is known as Bacon). This app is a calculator that acts like a base converter which gives me some of the direct experience needed for this program. I have been running linux mint since September 2011 and am quite familiar with the GNOME desktop environment. Finally, my best asset is my knowledge of C++, C and also the writing of my blackberry app that is similar to Gcalctool. To get in touch with me:
Email : email@example.com
Bugs I have fixed: https://bugzilla.gnome.org/show_bug.cgi?id=670678
Blackberry App related to Gcalctool: http://appworld.blackberry.com/webstore/content/84740/?lang=en
|File name||Size||Date submitted|
|Gopalkrishnan_Radhakrishnan.tar.gz||51.7 KB||August 25 2012 20:22 UTC|