perf: improving performance, layout (#215)

Co-authored-by: nullishamy <git@amyerskine.me>
2024-06-01 21:49:55 +03:00
parent 54633c0f72
commit cadc3e2ac2
37 changed files with 1015 additions and 665 deletions
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@@ -0,0 +1,74 @@
+## Build pipeline
+
+The GTK port has a fairly complicated build pipeline / system, chiefly stemming from our use of Colloid as a base theme.
+We use Colloid as a base to reduce development overhead of creating our own theme from scratch, we look to replace this in the future
+to give us more flexibility and control over the theme (see https://github.com/catppuccin/gtk/issues/164).
+
+We have reimplemented Colloid's build system (previously implemented in Shell) in Python to make it easier to maintain, extend, and iterate on.
+With this re-implementation, we have several distinct components in the system, described below:
+1) Patching
+2) SCSS
+2) Assets
+
+## Patching
+
+We patch our colloid submodule to add additional functionality and (temporarily) fix bugs found in Colloid.
+We do this through `.patch` files, applied with `git apply` when the build script boots up. 
+The build script will store some state in the submodule to ensure it does not get needlessly patched.
+
+The patches are stored in `patches/colloid`, and currently have our palette, the Plank theme, and a modification to Colloid
+to allow all of our accents to load. When we find issues in Colloid, they will be patched through this system before being submitted upstream.
+
+## SCSS
+
+[This section assumes the directory root is at `colliod/src/sass`]
+
+The bulk of the theme is implemented here, in SCSS. This is by far the most modular part of Colloid out of the box, requiring minimal patching from our end to function.
+To start, we move the Colloid submodule into its own temporary copy. This is to allow us to run multiple builds in parallel, which would be otherwise impossible due to the
+file changes necessitated by each build, described below.
+
+With our temporary copy established, we generate the 'tweaks' for the build. This sets up a file (`_tweaks-temp.scss`) which describes the various knobs and dials for the build:
+```scss
+@import 'color-palette-catppuccin-mocha';
+
+$colorscheme: 'catppuccin';
+$colortype: 'system';
+$opacity: 'default';
+$theme: 'mauve';
+$compact: 'false';
+$translucent: 'false';
+$panel_opacity: 1.0;
+$blackness: 'false';
+$rimless: 'false';
+$window_button: 'mac';
+$float: 'false';
+```
+We edit in the correct palette import for the flavour we're building, and set the other variables based on user / build state input.
+
+With the tweaks setup, we can now invoke `sassc` (the SCSS compiler) to build all of our CSS files. We run all of the SCSS builds in parallel, for performance.
+With the SCSS complete, we have now finished most of the work required for the build.
+
+
+## Assets
+
+We build our own assets to ship with the theme, based on the processes used in Colloid. 
+
+We build assets for GTK, to include UI elements such as buttons, checkboxes,
+etc. This is done through standard find-and-replace, as these assets are just SVGs. We do not support GTK2, so do not have to support the older PNG assets used there.
+
+We also build assets for Xfce's Xfwm4, which are first patched from a source SVG, and then rendered through the `inkscape` CLI. 
+This operation is done once, at the start of a build process (e.g CI, to be reused for every subsequent build), or once until they change in the future for local development. 
+The script to generate these assets can be found at [`patches/xfwm4/generate_assets.py`](./patches/xfwm4/generate_assets.py)
+
+
+## CI integration
+
+The CI system utilizes the build system, as described above, but with some unique parallelization elements to improve performance.
+We have chosen to only build a limited subset of possible tweaks in CI, to constrain the time it takes to run. 
+
+Currently, we build a matrix of:
+- Flavor
+- Accent
+
+The CI will run all 4 flavours in parallel (see above for precautions taken to ensure this functions correctly), and build each accent serially.
+We collate the logs for these runs into files so that they can be shown neatly at the end of the run.
--- a/docs/CHANGELOG.md
+++ b/docs/CHANGELOG.md
@@ -0,0 +1,15 @@
+# Changelog
+
+## [1.0.2](https://github.com/catppuccin/gtk/compare/v1.0.1...v1.0.2) (2024-05-27)
+
+
+### Bug Fixes
+
+* alt tab menu ([#209](https://github.com/catppuccin/gtk/issues/209)) ([cae57c8](https://github.com/catppuccin/gtk/commit/cae57c80f81fd1cc40fab2655109b09fa97103b9))
+
+## [1.0.1](https://github.com/catppuccin/gtk/compare/v1.0.0...v1.0.1) (2024-05-27)
+
+
+### Bug Fixes
+
+* alt tab menu ([#209](https://github.com/catppuccin/gtk/issues/209)) ([cae57c8](https://github.com/catppuccin/gtk/commit/cae57c80f81fd1cc40fab2655109b09fa97103b9))
--- a/docs/CONTRIBUTING.md
+++ b/docs/CONTRIBUTING.md
@@ -0,0 +1,82 @@
+## Development
+
+Information regarding the architecture of the project can be found [in the ARCHITECTURE.md](./ARCHITECTURE.md) document.
+
+### Requirements
+- All the [requirements for building](#building)
+- `whiskers`, optionally, from [catppuccin/toolbox](https://github.com/catppuccin/toolbox/tree/main/whiskers#installation)
+
+### Project structure
+
+`sources/` contains all of the source files needed for the project to build, including the Colloid submodule.
+It also contains our patches for Colloid, alongside the core build system implemented by us to replace the one from Colloid.
+
+`build.py` is the entrypoint to the build system, placed at the root for convenience. The plumbing this utilizes is in
+`sources/build`.
+
+`install.py` is our officially supported install script, which will automate the process of pulling the release, extracting it,
+and optionally adding symlinks for GTK-4.0 support. This script intentionally has no dependencies other than Python 3 itself.
+This keeps the end user experience simple and reproducible. Do not add external dependencies to this script.
+
+### Patching colloid
+> [!TIP]
+> If you need to change the patches, reset the submodule and rerun the build script.
+
+We patch upstream colloid through a series of `.patch` files, applied through `git apply` once when the build begins.
+The patches are located in `./patches/colloid/`.
+
+Once the build script patches the submodule, it will write a file into
+`colloid/.patched`, to signal to future invocations that the patches have already been applied.
+
+The palette patches are generated through `whiskers`,
+so if you're changing them, they will need regenerated. Simply run `whiskers palette.tera` to rebuild them.
+
+The process for building the theme is [documented in the README](./README.md#building).
+
+### Upstreaming procedure
+
+Now and again, Colloid will have bugs upstream that impacts our theme. With our patching system we can easily fix these problems,
+but we still want to contribute the fixes upstream to benefit all users & forks of Colloid.
+
+To avoid stalling unnecessarily, our procedure for the above is as follows:
+1) Open a PR to fix the issue, by adding a patch file to our theme, add `upstream:intended`
+to signal these changes are to be sent to Colloid eventually.
+2) Merge the PR & close the issue in our theme pertaining to the issue, once reviewed and approved
+3) Open a PR in Colloid with the patch
+4) Open a new issue in our theme, with these details:
+    - The initial issue in our theme
+    - The PR in Colloid that fixes the issue there
+    - The PR that fixed the issue in our theme
+
+    Add the `upstream:open` label
+5) Once the PR is merged in Colloid:
+    1) Test that the issue no longer persists, without our patch
+    2) Open a PR to remove the patch file in our theme, with these details:
+        - The tracking issue
+        - The commit that fixed the issue in Colloid
+    3) Close the tracking issue & merge the PR to remove the patch file
+
+
+### Running test builds
+We support building and publishing test builds from PRs. When you open PRs, the CI will automatically build with your changes and push an artifact
+which bundles all of the produced themes.
+
+You can then download the artifacts as a zip (result should look similar to 7bff2448a81e36bf3b0e03bfbd649bebe6973ec7-artifacts.zip) and
+pass the path into `install.py` under the `--from-artifact` option:
+```bash
+python3 install.py mocha blue --dest ./build --from-artifact ~/downloads/7bff2448a81e36bf3b0e03bfbd649bebe6973ec7-artifacts.zip
+```
+
+This will take the target flavor / accent out of the zip, and install it using the regular install process.
+
+It is advised to pass a `--dest` when running in this mode, because the released zips follow the exact same naming scheme as regular builds.
+This wil cause conflicts when you install, if you already had that theme installed. Passing a different destination allows you to move the
+extracted folders to `~/.local/share/themes` yourself, adding a suffix as appropriate to avoid conflicts.
+
+> [!WARNING]
+> If you pass `--link` to the install script when working from a PR, it will forcibly overwrite your `~/.config/gtk-4.0/` symlinks.
+> You will have to reinstall / relink to revert this.
+
+### Useful resources
+- GNOME-shell sources: https://gitlab.gnome.org/GNOME/gnome-shell/-/tree/gnome-46/data/theme
+- GTK inspector guide: https://developer.gnome.org/documentation/tools/inspector.html