exu/configs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
34f17e467a
configs/arch-config/.mozilla/firefox/default-release/chrome/CONTRIBUTING.md

10 KiB
Raw Blame History

Contributing

Table of Contents

Introduce

I'm really glad you're reading this, because we need volunteer developers to help this project come to fruition.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Code of Conduct

Refer to CODE_OF_CONDUCT.md.

We Develop with Github

We use github to host code, to track issues and feature requests, as well as accept pull requests.

After feedback has been given we expect responses within two weeks. After two weeks we may close the issue and pull request if it isn't showing any activity.

Environment

You can configure it as follows:

## clone repository
git clone https://github.com/black7375/Firefox-UI-Fix.git
cd ./Firefox-UI-Fix

## checkout branch
git checkout <BRANCH_NAME>

Your First Contribution

Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub

The following documents may be helpful:

Live Debugging:

Firefox Source Code:

Test for None mac users:

Contribution Targets

We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:

Promotions

  • Introduce project
    • Video (Recommend!!, We need it)
    • Blog
    • SNS
    • Reddit, Hackernews..etc
  • Sample

Docs

  • Fix typos, alignments.
  • Correct awkward sentences.
  • Improve document readability.

Issues

  • Report a bug.
  • Discussing the current state of the code.
  • Tell us about related or relevant projects and documents.
  • Help other users issue.
  • Proposing others..

Codes

  • New Features.
  • Bug fixes.
  • Improved compatibility or accessibility.
  • Refactoring.

Project Structure

root
|- .gitattributes: Exclude at `Download Zip`
|- .github: Issue/PR Template, Github Actions
|- .prettierignore: Exclude coding style
|- .prettierrc.json: Coding style
|- icons/: Icons, illustrations
|- install.ps1: Install script write in powersehll
|- install.sh: Install script write in bash
|- LEPTON: Meta infos (branch, version)
|- user.js: about:config settings
|- userChrome.css: CSS for Browser UI
|- userContent.css: CSS for Web pages

Icon files

Most of them are made in SVG.

Except for illustrations, there must be an fill="context-fill" fill-opacity="context-fill-opacity" property to dynamically determine color and transparency.

Icons are mainly FirefoxUX/photon-icons or microsoft/fluentui-system-icons.

Meta Info files

It comes from install.sh.

LEPTON file format

If this file exist in same directory as the userChrome.css file, it is recognized as the "Lepton" installation directory.

[Info]
Branch=master | photon-style | proton-style
Ver=<git tag> | <git hash> | [NULL]

lepton.ini file Format

In lepton.ini, various information is stored during the installation process.
This file is recreated every time the installer is created.

[Profile Name]
Type=Local | Release | Git
Branch=master | photon-style | proton-style
Ver=<git tag> | <git hash> | [NULL]
Path=<Full PATH>

Update Policy according to Type

  • Local(unknown): force latest commit update
  • Release(): force latest tag update
  • Git: latest commit update

Restrictions

  • Cross Platform
    • Different compatibility issues occur in Win7, Win8, Win10, KDE, Gnome, Mac, etc.
    • Consider compatibility as much as possible, but use dedicated media queries in special cases
  • CSS Loading Order
    • User CSS(userChrome.css, userContent.css) is usually loaded first.
    • In many cases, overriding should be prevented with important!(Anti-pattern in general web), and side effects should also be considered.
  • DOM structure cannot be modified
    • It is possible with JS, but there are security and configuration issues, so we should make the most of CSS.
    • ::before and ::after can indirectly add CSS elements.
  • Shadow DOM
    • Firefox actively uses shadow dom internally
    • To modify, it is often a roundabout approach or impossible to inherit
  • XUL
    • Sometimes written and bound in C++ for performance, like a treeview of bookmarks.
    • The proper document does not exist, so we have to read the source code and work
    • Available CSS features are also restricted.
  • Side Effects

Rules

Version

Milestone, The versioning scheme we use is SemVer. (Maintainer decides, do not pull request.)

We will release the feature as soon as it is complete, but the cycle should be 2-4 weeks. Rapid releases.

It comes from #109.

Branch

Stable: Only bugfix, Documentation.

  • master: Common bugfix, documentation.
  • photon-style: Bugfix, documentation specified in photon-style.
  • proton-sryle: Bugfix, documentation specified in proton-style.

Development: New Features.

  • dev: Common new features.
  • photon-style-dev: New features specified in photon-style.
  • proton-style-dev: New features specified in proton-style.

Issue

  • Versions:
  • Make sure you’re on the latest version.
  • Try older versions.
  • Try switching up dependency versions.
  • Search: Search the project’s issues to make sure it's not a known issue.

Coding style

  • Indent: 2 spaces for indentation rather than tabs.
  • Columns: Fit 80~100 columns as much as possible. (Auto formatting is using 120 to avoid the worst case)

Commit

  • Meaningfully:: It doesn't make meaningless commits.
  • One per task: It's difficult to distinguish when various tasks are mixed.
  • Often: Codes may corrupt during large changes.

Commit Message

For intuitive recognition, I put a prefix.

  • Add: Add feature or enhanced.
  • Fix: Bug fix or change default values.
  • Clean: Refactoring.
  • Doc: Update docs.

Pull request

  • Branch: Check the Branch section and PR to the correct branch.
  • Issue: We recommend that you open the issue first to discuss the changes with the owner of this repository.

License

Any contributions you make will be under the MPL 2.0 Software License

In short, when you submit code changes, your submissions are understood to be under the same MPL 2.0 License that covers the project. Feel free to contact the maintainers if that's a concern.

Reference specification

Even if you copy the code snippet, it is recommended that you leave a link.

FAQ

If you have any questions about other licenses, please see Moailla's MPL 2.0 FAQ.

References