PROJECT: GuiltTrip

Overview

Craving for a nice bowl of Mala but can’t seem to save up enough for it? guiltTrip() is the perfect platform for those aspiring to be able to afford their Mala, finally!

Summary of contributions

  • Major enhancement: added the ability to customise the look of UI

    • What it does: allows the user to toggle specific panels on and off, change the font and theme of the application. The font and theme settings are also saved.

    • Justification: This feature improves the product by a moderate degree as it gives the user ability to change the look of the GUI to their liking. Because these settings are saved, when the user launches the application again, it is already in the user’s preferred settings. As we are targeting young people who often like to customise the look of their applications (light/dark theme, type of font used), we believe that making the GUI customisable will draw our target users in and encourage them to continue using the application.

    • Highlights: This enhancements supplements some of the existing commands as it allows the user to view other entries such as Budgets, Wishes and AutoExpenses or not to view them, by toggling those panels off.

  • Minor enhancement:

    • Implement specific add, delete and edit commands for Expense and Income to maintain consistency (previously was one add/delete/edit command for both Expense and Income while Wish, Budget, AutoExpenses had their own commands).

    • Improve listBudget and listWish to replace budgets/wishes with expenses and incomes in the main panel. Thus this allocates more space for the user to view budgets or wishes, whenever the user wants to.

  • Code contributed: [Reposense code]

  • Other contributions:

    • Project management:

      • Helped to manage releases v1.2 - v1.4 (3 releases) on GitHub

      • Did initial morphing of AB3 to GuiltTrip, from Person to Entry class (Pull request #68)

      • Renamed some parts of AB3 to GuiltTrip as part of morphing (Pull request #261)

      • Repackaged classes for better organisation (Pull request #256)

    • Enhancements to existing features:

      • Updated the GUI color scheme by colour-coding different kinds of entries and improving the general look of GUI (Pull requests #74, #140 #177, #261)

      • Wrote tests for existing feature (Pull request #261)

    • Documentation:

      • Updated AboutUs and README documents (Pull requests #36, #46, #62)

      • Looked through User Guide to ensure formatting is consistent, correct minor mistakes and update command summary section (Pull requests #190, #191)

    • Community:

      • Reported bugs and suggestions for other teams (PE dry run)

    • Tools:

      • Integrated a third party library (TestFX) to the project to facilitate testing of UI (Pull request #283)

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

UI features

Toggle Panel : toggle

Toggles visibility of the specified panel on the GUI. Only the following inputs are accepted:

  • for wishlist panel: wishlist/wishes/wish/w

  • for budget panel: budgets/budget/b

  • for reminders panel: reminders/reminder/r

  • for auto expenses panel: autoexpenses/autoexpense/autoexp/ae

Format: toggle <panel name>

Examples:

  • toggle wishlist

  • toggle ae`

Example usage:

Step 1. If user does not want to view the wishlist panel all the time, he could choose to execute the toggle wishlist command as shown below.

  1. He could refer to the panel names in the result display box above when typing in the input panel name.

ToggleBefore

Step 2. After the command is executed, the wishlist panel is toggled off and no longer in the side panel.

ToggleAfter

Change Font : changeFont

Changes the font used in application to the specified font. The input is case-sensitive. Only the following font names are accepted: "arial", "calibri", "cambria", "candara", "garamond", "georgia", "rockwell", "segoe UI", "serif", "verdana". The available fonts to change to will be shown in the result display box for the user to refer to easily. The change in font will be saved.

Format: changeFont <font name>

Examples:

  • changeFont rockwell

  • changeFont segoe UI

Example usage:

  1. User changes the font by executing the changeFont rockwell command as shown below.

    1. He is also able to refer to the available font names in the result display box above.

    ChangeFontBefore
  2. The font is successfully changed to ROCKWELL as seen in the result display box and the application.

    ChangeFontAfter

Change to dark theme : setDarkTheme

Changes the theme from light to dark. The change in theme will be saved.

Format: setDarkTheme

Example usage:

  1. User executes the command setDarkTheme as shown below:

    SetDarkThemeBefore
  2. After command is executed, the theme is changed to the dark theme and the result display box notifies user that the command is executed successfully.

    SetDarkThemeAfter

Change to light theme : setLightTheme

Changes the theme from dark to light. The change in theme will be saved.

Format: setLightTheme

  1. User executes the command setLightTheme as shown below:

    SetLightThemeBefore
  2. After command is executed, the theme is changed to the light theme and the result display box notifies user that the command is executed successfully.

    SetLightThemeAfter

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

UI component

UiClassDiagram
Figure 1. Structure of UI component

API : Ui.java

  • The UI consists of a MainWindow that is made up of parts e.g. CommandBox, ResultDisplay, ExpenseListPanel, StatusBarFooter etc. All these, including the MainWindow, inherit from the abstract UiPart class.

  • The UI component uses JavaFx UI framework. The layout of these UI parts are defined in matching .fxml files that are in the src/main/resources/view folder. For example, the layout of the MainWindow is specified in MainWindow.fxml

The UI component

  • Executes user commands using the Logic component.

  • Listens for changes to Model data so that the UI can be updated with the modified data.

Toggle Panel Command

Implementation

PartialUiClassDiagramForToggle
Figure 2. Partial class diagram showing only the classes in UI involved in the Toggle Panel Command.

The toggle command extends from the Command class. MainWindow checks using the CommandResult obtained from Logic if the user wants to toggle a specified panel. If so, it toggles the isVisible and isManaged properties of the place holder for that panel.

The following sequence diagram shows how an example usage scenario toggle wishlist would work:

ToggleSequenceDiagram
Figure 3. Interactions inside the Logic and UI components for the toggle wishlist command

The sequence diagram is as explained below:

  1. The user launches the application and executes the toggle wishlist command to toggle the wishlist panel.

  2. commandResult is obtained in MainWindow after the command is parsed and executed.

  3. MainWindow checks if the togglePanel attribute in commandResult is true.

  4. Since it is true, it retrieves the PanelName WISH from commandResult and calls on its own method handleTogglePanel.

  5. This method then calls on another method togglePanel() that toggles the panel and takes in the PanelName WISH as a parameter.

    1. (Not shown in sequence diagram to reduce its complexity) It also checks if the wishlist is already shown in the main panel.

    2. If it is, then a CommandException is thrown to prevent the user from toggling the wishlist side panel when the wishlist is already shown in the main panel.

The following activity diagram summarizes what happens when a user executes a toggle command:

ToggleActivityDiagram
Figure 4. Activity diagram showing what happens when user executes a toggle command

Design Considerations

  • Alternative 1 (current method): Toggle the panels from within MainWindow.

    • Pros: Easy to implement.

    • Cons: Might not be as OOP as other designs.

  • Alternative 2: MainWindow has a PanelManager class that manages all the side panels (toggling them on and off).

    • Pros: More OOP, reduces number of methods and lines of code in MainWindow.

    • Cons: May introduce cyclic dependency between PanelManager and MainWindow.

Change Font Command

Implementation

The changeFont command extends from the Command class. MainWindow checks using the CommandResult obtained from Logic if the user wants to change the application font. If so, it immediately changes the font without requiring the user to exit and launch the application again.

This change in font is also saved in UserPrefs.

The following sequence diagram shows how an example usage scenario changeFont rockwell would work:

ChangeFontSequenceDiagram
Figure 5. Interactions inside Logic and UI components for the changeFont rockwell command

The sequence diagram is as explained below:

  1. The user launches the application and executes the changeFont rockwell command to change the current application font to rockwell.

  2. commandResult is obtained in MainWindow after the command is parsed and executed.

  3. MainWindow checks if the changeFont attribute in commandResult is true.

  4. Since it is true, it retrieves the FontName ROCKWELL from commandResult and calls on its own method handleChangeFont.

  5. This method then converts the FontName ROCKWELL to a String "rockwell" and sets the font-family attribute of window, that contains all the child nodes, to rockwell.

The following activity diagram summarizes what happens when a user executes a changeFont command:

ChangeFontActivityDiagram
Figure 6. Activity diagram showing what happens when user executes a changeFont command

Design Considerations

  • Alternative 1 (current choice): Change the application font from within MainWindow.

    • Pros: Easy to implement.

    • Cons: May not be as OOP as other methods.

  • Alternative 2: Use a separate class to control the theme, such as ThemeManager.

    • Pros: More OOP, reduces amount of code in MainWindow.

    • Cons: As the implementation is not very complicated, introducing a new class just to change the theme may not be worth the increase in dependency (introduces dependency between Theme and ThemeManager and between ThemeManager and MainWindow).

Set Light/Dark Theme Command

Implementation

The setLightTheme/setDarkTheme command extends from the Command class. MainWindow checks using the CommandResult obtained from Logic if the user wants to change the theme of the application. If so, it immediately changes the theme without requiring the user to exit and launch the application again.

This change in the application theme is also saved in UserPrefs.

The following sequence diagram shows how an example usage scenario setLightTheme would work:

SetLightThemeSequenceDiagram
Figure 7. Interactions inside Logic and UI components for setLightTheme command

The sequence diagram is as explained:

  1. The user launches the application and executes the setLightTheme command to change the current theme to light.

  2. commandResult is obtained in MainWindow after the command is parsed and executed.

  3. MainWindow checks if the changeTheme attribute in commandResult is true.

  4. Since it is true, it retrieves the newTheme from commandResult, LIGHT, and calls on its own method switchThemeTo(LIGHT).

    1. (Following details were trivial and thus omitted from the diagram) This method retrieves the URLs for the light theme and corresponding extensions css files and adds it to the stylesheets for the scene. This is done after removing the stylesheets for the previous theme.

  5. This implementation is essentially the same for setDarkTheme command, with the newTheme as DARK instead.

The following activity diagram summarizes what happens when a user executes a setLightTheme command:

SetLightThemeActivityDiagram
Figure 8. Activity diagram showing what happens when user executes a setLightTheme command

Design Considerations

  • Alternative 1 (current choice): Change the theme from within MainWindow.

    • Pros: Easy to implement.

    • Cons: May not be as OOP as it could be, increases number of lines of code in MainWindow.

  • Alternative 2: Use a separate class to control the theme, such as ThemeManager.

    • Pros: Abstracts out the methods regarding changing of theme to be contained in ThemeManager and reduces the number of lines of code in MainWindow.

    • Cons: Harder to implement; may introduce cyclic dependency. It may also be redundant or excessive as implementing the changeFont command is not very complicated.