Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Color Formatting Static Checks Messages #5329

Closed
kkmurerwa opened this issue Feb 1, 2024 · 9 comments · Fixed by #5540
Closed

[Feature Request]: Color Formatting Static Checks Messages #5329

kkmurerwa opened this issue Feb 1, 2024 · 9 comments · Fixed by #5540
Assignees
Labels
enhancement End user-perceivable enhancements. good first issue This item is good for new contributors to make their pull request. Impact: Low Low perceived user impact (e.g. edge cases). Work: Medium The means to find the solution is clear, but it isn't at good-first-issue level yet.

Comments

@kkmurerwa
Copy link
Collaborator

kkmurerwa commented Feb 1, 2024

Is your feature request related to a problem? Please describe.

Currently, the output of static checks is presented uniformly in the same color, making it challenging to quickly distinguish failed checks from successful ones. To enhance the experience, color-formatted messages should be implemented for static checks. Specifically, if a static check fails, the corresponding error message should be displayed in red, providing an immediate visual cue for attention while, if the check succeeds, the message should be presented in green, indicating a positive outcome. Warning messages can also be output in yellow for easy scanning.

Describe the solution you'd like

Shell provides a way to format the color of the output and we can use this to implement the feature. Using color codes, we can be able to implement a printer that takes in a string as a variable and formats it based on the type of message it is. Here is a shell script that can be used as a printer.

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
NC='\033[0m'

function echo_error() {
    echo -e "${RED}$1${NC}"
}

function echo_success() {
    echo -e "${GREEN}$1${NC}"
}

function echo_warning() {
    echo -e "${YELLOW}$1${NC}"
}

Example usage of this printer is as shown below;

# Import the printer file
source ./path/to/shell_printer.sh

echo_warning "This is a warning message" # Prints a yellow message

echo_error "This is an error message" # Prints a red message

echo_success "This is a success message" # Prints a green message

This blog post provides more insight on color formatting in shell.

Describe alternatives you've considered

No response

Additional context

No response

@kkmurerwa kkmurerwa added enhancement End user-perceivable enhancements. triage needed labels Feb 1, 2024
@kkmurerwa kkmurerwa changed the title [Feature Request]: Static Checks Color Formatting [Feature Request]: Color Formatting Static Checks Messages Feb 1, 2024
@adhiamboperes adhiamboperes added good first issue This item is good for new contributors to make their pull request. Impact: Low Low perceived user impact (e.g. edge cases). Work: Low Solution is clear and broken into good-first-issue-sized chunks. and removed triage needed labels Feb 1, 2024
@adhiamboperes adhiamboperes added Work: Medium The means to find the solution is clear, but it isn't at good-first-issue level yet. and removed Work: Low Solution is clear and broken into good-first-issue-sized chunks. labels Feb 1, 2024
@snehalchaudhari98
Copy link

Hi @adhiamboperes , if this issue is still available then I would love to work on this. This looks like a good point for someone new to start. If it's possible, can you please assign this issue to me?

@adhiamboperes
Copy link
Collaborator

@snehalchaudhari98, this issue is available. Could you please give an overview of you proposed solution? You can also open a draft pull request.

@aadityaguptaa
Copy link
Contributor

Hi @adhiamboperes can I work on this Issue?

@adhiamboperes
Copy link
Collaborator

Hi,
Please tell us your idea of how to solve this, then we will assign it to you once we're aligned!

@aadityaguptaa
Copy link
Contributor

Sure @adhiamboperes,

Here's a proposed solution:

We'll refactor the color-formatting logic into a separate script, for ex. formatting_utils.sh. This script will contain the echo_error, echo_success, and other formatting functions. We can then source this script within all the scripts that static check script is executing. For example, Static_Checks.sh file is executing, checkstyle_lint_check.sh file.
image

So, in checkstyle_lint_check,sh file,
image
instead of calling "echo "Checkstyle issue found."" on line 26, we can call
echo_error "CheckStyle issue found."

@aadityaguptaa
Copy link
Contributor

aadityaguptaa commented Mar 14, 2024

@adhiamboperes
Sorry, the line no is not mentioned in the above Image,

This is what I am trying to suggest:
image

PS: ignore my bad handwriting, thanks

@aadityaguptaa
Copy link
Contributor

Hey @adhiamboperes can I?

@dattasneha
Copy link
Contributor

Hey @adhiamboperes I would like to work on this next by referring to the explanation provided in the issue description and previous comments. My approach would be creating 3 different functions to format the color for success, failure and warning messages in a separate file and calling them from the necessary file.

@theMr17
Copy link
Collaborator

theMr17 commented Sep 20, 2024

De-assigning @snehalchaudhari98 due to inactivity.

@dattasneha assigning you the issue, feel free to work on this next.

subhajitxyz pushed a commit to subhajitxyz/oppia-android that referenced this issue Nov 19, 2024
…5540)

<!-- READ ME FIRST: Please fill in the explanation section below and
check off every point from the Essential Checklist! -->
## Explanation
Fixes oppia#5329  

This PR implements color-coded messages for static checks to improve
experience. Error messages are displayed in red for failing checks,
while warnings are shown in yellow. Successful checks are indicated with
green messages.
<!--
- Explain what your PR does. If this PR fixes an existing bug, please
include
- "Fixes #bugnum:" in the explanation so that GitHub can auto-close the
issue
  - when this PR is merged.
  -->

## Essential Checklist
<!-- Please tick the relevant boxes by putting an "x" in them. -->
- [x] The PR title and explanation each start with "Fix #bugnum: " (If
this PR fixes part of an issue, prefix the title with "Fix part of
#bugnum: ...".)
- [x] Any changes to
[scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets)
files have their rationale included in the PR explanation.
- [x] The PR follows the [style
guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide).
- [x] The PR does not contain any unnecessary code changes from Android
Studio
([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)).
- [x] The PR is made from a branch that's **not** called "develop" and
is up-to-date with "develop".
- [x] The PR is **assigned** to the appropriate reviewers
([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)).

## For UI-specific PRs only
<!-- Delete these section if this PR does not include UI-related
changes. -->
If your PR includes UI-related changes, then:
- Add screenshots for portrait/landscape for both a tablet & phone of
the before & after UI changes
- For the screenshots above, include both English and pseudo-localized
(RTL) screenshots (see [RTL
guide](https://github.com/oppia/oppia-android/wiki/RTL-Guidelines))
- Add a video showing the full UX flow with a screen reader enabled (see
[accessibility
guide](https://github.com/oppia/oppia-android/wiki/Accessibility-A11y-Guide))
- For PRs introducing new UI elements or color changes, both light and
dark mode screenshots must be included
- Add a screenshot demonstrating that you ran affected Espresso tests
locally & that they're passing

---------

Co-authored-by: Adhiambo Peres <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement End user-perceivable enhancements. good first issue This item is good for new contributors to make their pull request. Impact: Low Low perceived user impact (e.g. edge cases). Work: Medium The means to find the solution is clear, but it isn't at good-first-issue level yet.
Development

Successfully merging a pull request may close this issue.

6 participants