|
| 1 | +# Contributing |
| 2 | + |
| 3 | +## Padding, Margins, and Border Radii |
| 4 | + |
| 5 | +The base grid unit should be 3px. Sometimes widgets with borders will be "off by one" to align visually. |
| 6 | + |
| 7 | +Border radii should increase as they nest where reasonable. The largest border radii is 9px, used by windows. Popovers and On Screen Displays use a border radius half that. |
| 8 | + |
| 9 | +## Levels and Dark Style Theory |
| 10 | + |
| 11 | +Widget backgrounds are styled according to "level" or "elevation". Elements gets darker the further away they are in interaction hierarchy. For example, buttons are lightest and containers like sidebars are darkest. Widgets in dark style should follow this same progression from lightest in front to darkest in back, and not simply be inverted. |
| 12 | + |
| 13 | +## A11y |
| 14 | + |
| 15 | +* Colors should pass WCAG AA contrast requirements |
| 16 | +* Where possible, use the `rem()` function so that padding, margins, etc scale when users' adjust text size in system settings |
| 17 | + |
| 18 | +## Focus, Hover, Backdrop, etc |
| 19 | + |
| 20 | +Accent should be used to indicate the current area of focus. When selected, but not focused, use nuetral highlights. |
| 21 | + |
| 22 | +Focused widgets should be highlighted with a ring where possible. |
| 23 | + |
| 24 | +Backdrop states should use nuetral color and reduced depth. Contrast can be reduced in some cases, but be mindful of WCAG requirements even for backdrop elements. |
| 25 | + |
| 26 | +## File Name Conventions |
| 27 | + |
| 28 | +A file should be named after the CSS node it addresses. For instance, |
| 29 | +the file addressing `GtkButton` and its descendants would use the file name |
| 30 | +`Button.scss`. As a `GtkCheckButton` has a different CSS node (`checkbutton`), |
| 31 | +it would be placed into it's own file, named `CheckButton.scss`. If you are |
| 32 | +unsure of what node something uses, it's node can be found under the "Name" |
| 33 | +column of the "CSS Nodes" tab of the "Objects" page in Gtk Inspector. |
| 34 | + |
| 35 | +For nodes that are rarely used outside of the context of a parent node (i.e. |
| 36 | +`check` is rarely used outside of the context of `checkbutton`), they can be |
| 37 | +placed in the parent node file. |
| 38 | + |
| 39 | +CSS style classes, such as `Granite.CssClass.CARD`, should be placed in a |
| 40 | +`_classes.scss` file under the relevant library directory (e.g. Granite, Gtk, |
| 41 | +Adw). |
| 42 | + |
| 43 | +## Testing Changes |
| 44 | + |
| 45 | +Apps may need to be restarted or the system stylesheet may need to be changed before installed changes take effect. |
| 46 | + |
| 47 | +You can also test changes live with Gtk Inspector. Make sure you have Gtk development libraries installed, then enable the inspector shortcut: |
| 48 | + |
| 49 | +```bash |
| 50 | + apt install libgtk-4-dev |
| 51 | + gsettings set org.gtk.gtk4.Settings.Debug enable-inspector-keybinding true |
| 52 | +``` |
| 53 | + |
| 54 | +Open an app you wish to test your changes on. Open Gtk Inspector with the keyboard shortcut Shift + Ctrl + D, then navigate to the tab "CSS" in Gtk4. Your changes here will take immediate effect on the focused app. You may have to toggle the "pause" button in the top left before changes take effect. |
| 55 | + |
| 56 | +## Proposing Changes |
| 57 | + |
| 58 | +Changes should be tested against the following apps to avoid breakage: |
| 59 | +* Gtk Demo |
| 60 | +* Gtk Widget Factory |
| 61 | +* Granite Demo |
| 62 | + |
| 63 | +Avoid hardcoding palette colors where possible. `accent_color` should be used for any hightlights or selection states that should adapt to users' color preferences. Use semantic variables like `warning_color` where possible since these are contrast checked for dark and light styles. |
| 64 | + |
| 65 | +Please provide before and after screenshots of your change where applicable |
0 commit comments