H
HyprL

Table of Contents

Introduction

We welcome and appreciate all contributions to the HyprL project! Whether you’re fixing a bug, adding a new feature, improving documentation, or sharing a theme, your efforts help make HyprL better for everyone. This guide outlines the different ways you can contribute and the guidelines to follow.

How to Contribute

Bug Reports

If you find a bug, please help us by reporting it on the HyprL GitHub Issues page.

  • Clear Reproduction Steps: Provide detailed steps on how to reproduce the bug.
  • System Information: Include relevant system details such as your GPU, screen resolution, and any specific hardware or software configurations.
  • Relevant Logs: Attach logs from ~/.cache/hyprland/hyprland.log or journalctl --user -u <service> if applicable.

Feature Requests

Have an idea for a new feature? We’d love to hear it!

  • Describe the Feature: Clearly explain what the feature is and how it would benefit users.
  • Use Case: Describe the problem it solves or the workflow it improves.
  • Check Existing Issues: Before submitting, please check if a similar feature request already exists.
  • Fit with Philosophy: Consider if the feature aligns with HyprL’s philosophy of being beautiful, functional, and accessible, while maintaining a minimal core.

Code Contributions

If you’d like to contribute code, please follow these steps:

  1. Fork the Repository: Fork the HyprL GitHub repository.
  2. Create a Feature Branch: Create a new branch for your changes (e.g., git checkout -b feature/my-new-feature).
  3. Implement Your Changes: Write your code, ensuring it adheres to the Code Style guidelines.
  4. Test Thoroughly: Test your changes to ensure they work as expected and don’t introduce new issues. Refer to the Testing Guidelines.
  5. Commit Your Changes: Write clear and concise commit messages.
  6. Submit a Pull Request (PR): Open a pull request to the main branch of the HyprL repository. Provide a clear description of your changes and why they are needed.

Documentation

Good documentation is crucial! You can contribute by:

  • Improving README Sections: Enhance clarity and completeness of the main README.md.
  • Adding Configuration Examples: Provide more examples for various configuration files.
  • Updating Keybinding Documentation: Keep the keybinding lists accurate and up-to-date.
  • Translating: Help translate documentation into other languages (future feature).

Themes & Customizations

If you’ve created a beautiful theme or a useful customization, consider sharing it!

  • Follow Naming Conventions: Adhere to existing naming conventions for themes and files.
  • Test on Different Resolutions: Ensure your theme looks good on various screen sizes.
  • Include Screenshots: Provide screenshots in your pull request or showcase submission.

Testing Guidelines

Before submitting a code contribution, please ensure you have tested your changes thoroughly:

  • Fresh Arch Linux Installation: Ideally, test on a clean Arch Linux installation to ensure no local conflicts.
  • Executable Scripts: Verify that all new or modified scripts are executable (chmod +x).
  • Functionality: Check that the feature or fix works as intended.
  • Wallpaper Automation: If related, verify wallpaper automation functions correctly.
  • Monitor Configurations: Test on different monitor setups if your changes affect display.

Code Style

To maintain consistency and readability, please follow these code style guidelines:

  • Bash/Shell Scripting: Use consistent bash/shell scripting practices. Prefer #!/bin/bash for Bash scripts and #!/bin/zsh for Zsh-specific scripts.
  • Comments: Add comments for complex logic or non-obvious parts of the code.
  • Directory Structure: Follow the existing directory structure and place files in their logical locations.
  • Variable Names: Use descriptive variable names.

Versioning

HyprL follows semantic versioning:

  • MAJOR: Breaking changes (e.g., major architectural overhaul).
  • MINOR: New features (e.g., adding a new theme, a new tool).
  • PATCH: Bug fixes (e.g., fixing a script error, a typo).
  • BUILD: Small tweaks or updates that don’t change functionality (e.g., documentation updates, minor refactoring).