Allow overriding stylesheet

[soraxas]

For example, I have removed the cyan tint in the background of the window by having the following contents in my ~/.config/paperwm/stylesheet.css

.paper-mm-selected-window {
    border: 10px;
    border-radius: 5px;
}

.paperwm-selection {
    border: 2px;
    border-radius: 8px;
    background-color: rgba(0, 0, 0, 0.1);  // this remove background colour
}

[smichel17]

The feature seems fine, but I don't think we should merge it here. For now, I think it would be best to send a PR upstream, instead.

Anything which is merged to this branch becomes part of the upstream PR to add support for GNOME 40; this feature is unrelated to GNOME 40 support.

Adding unrelated features makes this work harder to merge back upstream. If we do this, it's basically making the decision to hard fork instead of soft fork, aka deciding that we are not going to try and merge back upstream. I don't think we should do this yet. Maybe if another 6-12 months go by and hedning is still away.

[soraxas]

All upstream PRs are currently in limbo though, and it defeats the purpose of maintaining a PaperWM-community if this is only dedicated for GNOME 40 supports and does not try to merge the effort of other PRs (i.e. why open an entire community when the former intention can be achieved by one single branch).

More than that, the only difference that this would make is if @hedning decided to reject this feature PR isn't it (which can happen to any intermediate commit in this branch, e.g., changes to README.md notice in PaperWM-community:next-release is already an un-related commit)?

[smichel17]

I think you are reading too much into the name. People collaborating to support GNOME 40 is the reason I proposed creating a soft fork in paperwm#376 (comment), nothing more. In my mind, a happy ending to this project is that it gets merged back into upstream, and then @hedning invites some of the involved folks to be co-maintainers so that we can start merging PRs there.

Maybe it would be better to rename the next-release branch here to gnome-40 or something like that, but there's already a number of open PRs (plus the one back to upstream) that would need to be re-done. Alternatively, we could rename the repo to PaperWM-gnome-40 or something like that.

[smichel17]

I guess I didn't respond to some of your specific points:

why open an entire community when the former intention can be achieved by one single branch

You're right that we only need one branch. Unfortunately, none of us here has push permissions on the PaperWM repo, so we need a new repo to host that one branch. We could have used someone else's personal fork, but that would put them in charge; this positions the various contributors as equals.

the only difference that this would make is if @hedning decided to reject this feature PR

The bigger the number of changes, the harder to review. So, the more focused we keep the changes here on GNOME 40, the more likely @hedning is to merge them back upstream.

any intermediate commit in this branch, e.g., changes to README.md notice in PaperWM-community:next-release is already an un-related commit

Yeah, that wasn't great, either. But those commits have already been reverted on next-release, and I will likely rebase thenext-release branch to remove them from the history entirely.

[smichel17]

It's been 6 months and we're going ahead with a hard fork (#27), so I think this would be OK to merge, after clarifying the readme information.

[smichel17]

1. I think this is a good feature to have. Especially, it provides an easier on-ramp for people to become involved in PaperWM development (tweaking their own styles).
2. Since I now have commit access upstream, I'd like to start moving PRs there, so I'll close this; can you please re-create it upstream? Thanks!
3. I think it would be best to call it user.css, to match user.js

[smichel17]

Suggested change

	let userStylesheet = getConfigDir().get_child("stylesheet.css");
	let userStylesheet = getConfigDir().get_child("user.css");

[smichel17]

Suggested change

	You can also supply a custom `stylesheet.css` in `~/.config/paperwm/`, and paperwm will override its own default stylesheet located at the extension installation location, e.g., `~/.local/share/gnome-shell/extensions/paperwm@hedning:matrix.org/stylesheet.css or `/usr/share/gnome-shell/extensions/paperwm@hedning:matrix.org/stylesheet.css`.
	You can also supply a custom `user.css` in `~/.config/paperwm/`, and paperwm will override its own default stylesheet located at the extension installation location, e.g., `~/.local/share/gnome-shell/extensions/paperwm@hedning:matrix.org/stylesheet.css or `/usr/share/gnome-shell/extensions/paperwm@hedning:matrix.org/stylesheet.css`.