feat: force render

Author: busyoGG

.github/ISSUE_TEMPLATE/bug_report.md

@@ -10,6 +10,13 @@ assignees: ''
 <!-- Please describe the issue here at the top, then fill in the system information below. -->
 
 <!-- Attaching your full niri config can help diagnose the problem. -->
+<details><summary>Config</summary>
+
+```kdl
+insert config here
+```
+
+</details> 
 
 <!--
 If you have a problem with a specific app, please verify that it is running on Wayland, rather than X11. An easy way is to run xeyes and mouse over the app: xeyes will be able to "see" only X11 windows.

.github/dependabot.yml

@@ -13,10 +13,12 @@ updates:
         update-types:
           - "minor"
           - "patch"
+    cooldown:
+      default-days: 7
 
   - package-ecosystem: "github-actions"
     directory: "/"
     schedule:
       interval: "weekly"
-    ignore:
-      - dependency-name: "Andrew-Chen-Wang/github-wiki-action"
+    cooldown:
+      default-days: 7

.github/workflows/ci.yml

@@ -181,7 +181,7 @@ jobs:
           sudo apt-get update -y
           sudo apt-get install -y ${{ env.DEPS_APT }} libadwaita-1-dev
 
-      - uses: dtolnay/rust-toolchain@1.80.1
+      - uses: dtolnay/rust-toolchain@1.85.0
 
       - uses: Swatinem/rust-cache@v2
 
@@ -255,32 +255,26 @@ jobs:
         with:
           show-progress: false
 
-      # Required for the rust-cache action to work.
-      - uses: dtolnay/rust-toolchain@stable
-
-      # FIXME: doesn't seem to cache the builds, only the downloads for some unknown reason.
-      - uses: Swatinem/rust-cache@v2
-        with:
-          cache-all-crates: true
-
       # Remove man-db triggers to speed up Ubuntu upgrade by a minute or two during vmactions/freebsd-vm action run.
       - run: |
           sudo rm /var/lib/dpkg/info/man-db.*
 
       - name: Build
-        uses: vmactions/freebsd-vm@966989c456d41351f095a421f60e71342d3bce41  # v1.2.1
+        uses: vmactions/freebsd-vm@v1
         with:
+          release: "15.0"
+          copyback: false
           prepare: |
             pkg update -f
             pkg install -y ${{ env.DEPS_PKG }}
           run: |
-            curl -o patch-pipewire_init 'https://cgit.freebsd.org/ports/plain/x11-wm/niri/files/patch-pipewire_init?id=f3f7e555b06d9a87d63c047ce3e82e936a11f2fe'
+            curl -o patch-pipewire_init 'https://cgit.freebsd.org/ports/plain/x11-wm/niri/files/patch-pipewire_init?id=cadf6784d264cf780b6e0ad59bd15b831d36cf80'
 
             export CARGO_HOME="$PWD/cargo-home"
 
             cargo fetch
 
-            ( cd $CARGO_HOME/git/checkouts/pipewire-rs-*/*/; patch -p2 < $CARGO_HOME/../patch-pipewire_init; )
+            ( cd $CARGO_HOME/registry/src/index.crates.io-*/; patch -p1 < $CARGO_HOME/../patch-pipewire_init; )
 
             cargo build \
               --offline \
@@ -289,16 +283,18 @@ jobs:
   nix:
     runs-on: ubuntu-24.04
     steps:
+      - name: Free Disk Space (Ubuntu)
+        uses: jlumbroso/[email protected]
+        with:
+          dotnet: false
+          large-packages: false
+        
       - uses: actions/checkout@v4
         with:
           show-progress: false
 
-      - name: Check flake inputs
-        uses: DeterminateSystems/flake-checker-action@v4
-        continue-on-error: true
-
       - name: Install Nix
-        uses: DeterminateSystems/nix-installer-action@v3
+        uses: cachix/install-nix-action@v31
         continue-on-error: true
 
       - run: nix flake check

CONTRIBUTING.md

@@ -90,6 +90,24 @@ When creating pull requests, please keep the following in mind.
 - Remember to document new config options on the wiki.
 - When opening a pull request, ensure "Allow edits from maintainers" is enabled, so I can make final tweaks before merging.
 
+### How to get your pull request reviewed more quickly
+
+- Make it small and self-contained. Avoid mixing several unrelated changes in one PR.
+- Split the PR into small and self-contained commits. This makes it much easier to review.
+- Discuss new features, options, or behavior changes beforehand; make sure there's consensus about the design.
+- When creating the pull request, clearly write what it does, what problem it solves, how to test it.
+- Follow the rest of the advice from this document.
+
+## AI contributions
+
+If you use LLMs for your contribution (issue, comment, pull request), then it is *your job* to check and clean up its output, just like with any other tool.
+*You* have to spend the time doing this.
+Particularly:
+
+- If I can tell that a pull request is mostly LLM-generated, then very likely this pull request will take *significantly more time and effort* than usual to review and finish. This is based on my prior review experience. Therefore, I'm not interested in such pull requests—there's always plenty of human-written ones which take priority.
+- When using an LLM to prepare an issue, the text usually has a lot of unnecessary wording and irrelevant details. Anyone looking at such an issue will quickly lose interest in reading through it (myself certainly). Clean up the text and keep only those details that actually matter.
+- When using an LLM to comment on an issue, *you* have to verify that the comment makes sense, contributes something useful, and doesn't have unnecessary repetition.
+
 
 [cosmic-comp]: https://github.com/pop-os/cosmic-comp
 [anvil]: https://github.com/Smithay/smithay/tree/master/anvil