Link to gamja for web chat

gamja offers a better experience than Kiwi.

CONTRIBUTING.md

@@ -1,9 +1,8 @@
 # Contributing to wlroots
 
 Contributing just involves sending a pull request. You will probably be more
-successful with your contribution if you visit
-[#sway-devel on Libera Chat](https://web.libera.chat/?channels=#sway-devel) upfront and
-discuss your plans.
+successful with your contribution if you visit [#sway-devel on Libera Chat]
+upfront and discuss your plans.
 
 Note: rules are made to be broken. Adjust or ignore any/all of these as you see
 fit, but be prepared to justify it to your peers.
@@ -15,7 +14,7 @@ don't, however, allow me to make a suggestion: feature branches pulled from
 upstream. Try this:
 
 1. Fork wlroots
-2. `git clone https://github.com/username/wlroots && cd wlroots`
+2. `git clone git@github.com:<username>/wlroots.git && cd wlroots`
 3. `git remote add upstream https://github.com/swaywm/wlroots`
 
 You only need to do this once. You're never going to use your fork's master
@@ -36,6 +35,41 @@ your new features work correctly). Document all of the edge cases you're aware
 of so we can adequately test them - then verify the test plan yourself before
 submitting.
 
+## Commit Log
+
+Unlike many projects using GitHub and GitLab, wlroots has a [linear, "recipe"
+style] history. This means that every commit should be small, digestible,
+stand-alone, and functional. Rather than a purely chronological commit history
+like this:
+
+```
+doc: final docs for view transforms
+fix tests when disabled, redo broken doc formatting
+better transformed-view iteration (thanks Hannah!)
+try to catch more cases in tests
+tests: add new spline test
+fix compilation on splines
+doc: notes on reticulating splines
+compositor: add spline reticulation for view transforms
+```
+
+We aim to have a clean history which only reflects the final state, broken up
+into functional groupings:
+
+```
+compositor: add spline reticulation for view transforms
+compositor: new iterator for view transforms
+tests: add view-transform correctness tests
+doc: fix formatting for view transforms
+```
+
+This ensures that the final patch series only contains the final state,
+without the changes and missteps taken along the development process. A linear
+history eases reviewing, cherry-picking and reverting changes.
+
+If you aren't comfortable with manipulating the Git history, have a look at
+[git-rebase.io].
+
 ## Commit Messages
 
 Please strive to write good commit messages. Here's some guidelines to follow:
@@ -47,20 +81,18 @@ or similar.
 
 The subsequent lines should be separated from the subject line by a single
 blank line, and include optional details. In this you can give justification
-for the change, [reference Github
-issues](https://help.github.com/articles/closing-issues-via-commit-messages/),
-or explain some of the subtler details of your patch. This is important because
-when someone finds a line of code they don't understand later, they can use the
-`git blame` command to find out what the author was thinking when they wrote
-it. It's also easier to review your pull requests if they're separated into
-logical commits that have good commit messages and justify themselves in the
-extended commit description.
+for the change, [reference Github issues], or explain some of the subtler
+details of your patch. This is important because when someone finds a line of
+code they don't understand later, they can use the `git blame` command to find
+out what the author was thinking when they wrote it. It's also easier to review
+your pull requests if they're separated into logical commits that have good
+commit messages and justify themselves in the extended commit description.
 
 As a good rule of thumb, anything you might put into the pull request
 description on Github is probably fair game for going into the extended commit
 message as well.
 
-See [here](https://chris.beams.io/posts/git-commit/) for more details.
+See [How to Write a Git Commit Message] for more details.
 
 ## Code Review
 
@@ -84,9 +116,8 @@ process is:
 
 ## Style Reference
 
-wlroots is written in C with a style similar to the [kernel
-style](https://www.kernel.org/doc/Documentation/process/coding-style.rst), but
-with a few notable differences.
+wlroots is written in C with a style similar to the [kernel style], but with a
+few notable differences.
 
 Try to keep your code conforming to C11 and POSIX as much as possible, and do
 not use GNU extensions.
@@ -362,3 +393,10 @@ static void subsurface_handle_surface_destroy(struct wl_listener *listener,
 	subsurface_destroy(subsurface);
 }
 ```
+
+[#sway-devel on Libera Chat]: https://web.libera.chat/gamja/?channels=#sway-devel
+[linear, "recipe" style]: https://www.bitsnbites.eu/git-history-work-log-vs-recipe/
+[git-rebase.io]: https://git-rebase.io/
+[reference Github issues]: https://help.github.com/articles/closing-issues-via-commit-messages/
+[How to Write a Git Commit Message]: https://chris.beams.io/posts/git-commit/
+[kernel style]: https://www.kernel.org/doc/Documentation/process/coding-style.rst

README.md

@@ -76,7 +76,7 @@ See [CONTRIBUTING.md].
 
 [Wayland]: https://wayland.freedesktop.org/
 [wiki]: https://github.com/swaywm/wlroots/wiki/Getting-started
-[#sway-devel on Libera Chat]: https://web.libera.chat/?channels=#sway-devel
+[#sway-devel on Libera Chat]: https://web.libera.chat/gamja/?channels=#sway-devel
 [Sway]: https://github.com/swaywm/sway
 [wrapper libraries]: https://github.com/search?q=topic%3Abindings+org%3Aswaywm&type=Repositories
 [libseat]: https://git.sr.ht/~kennylevinsen/seatd

include/wlr/types/wlr_scene.h

@@ -90,6 +90,11 @@ void wlr_scene_node_place_above(struct wlr_scene_node *node,
  */
 void wlr_scene_node_place_below(struct wlr_scene_node *node,
 	struct wlr_scene_node *sibling);
+/**
+ * Move the node to another location in the tree.
+ */
+void wlr_scene_node_reparent(struct wlr_scene_node *node,
+	struct wlr_scene_node *new_parent);
 /**
  * Call `iterator` on each surface in the scene-graph, with the surface's
  * position in layout coordinates. The function is called from root to leaves

types/wlr_scene.c

@@ -133,6 +133,24 @@ void wlr_scene_node_place_below(struct wlr_scene_node *node,
 	wl_list_insert(sibling->state.link.prev, &node->state.link);
 }
 
+void wlr_scene_node_reparent(struct wlr_scene_node *node,
+		struct wlr_scene_node *new_parent) {
+	assert(node->type != WLR_SCENE_NODE_ROOT && new_parent != NULL);
+
+	if (node->parent == new_parent) {
+		return;
+	}
+	/* Ensure that a node cannot become its own ancestor */
+	for (struct wlr_scene_node *ancestor = new_parent; ancestor != NULL;
+			ancestor = ancestor->parent) {
+		assert(ancestor != node);
+	}
+
+	wl_list_remove(&node->state.link);
+	node->parent = new_parent;
+	wl_list_insert(new_parent->state.children.prev, &node->state.link);
+}
+
 static void scene_node_for_each_surface(struct wlr_scene_node *node,
 		int lx, int ly, wlr_surface_iterator_func_t user_iterator,
 		void *user_data) {