BananaFlip

Nah, unless you're unhappy with the current outcome, you can leave it as it is.

Changes in .config/gtk-4.0/gtk.css will be applied on top of the stylesheet, so whatever you don't override there, will fall back to the default, that's why your sidebar previously went full Adwaita light mode.

After taking a brief look at the libadwaita source, as far as I can see, helper colors are a special case anyways, @borders as well as border_coloris used exclusively in the scssfiles (which the gtk.css is generated from), whereas the gtk.css for some reason doesn't get back to the generic name, but uses the assigned value alpha(currentColor,0.15) - which doesn't help your case at all.

To actually change @borders, you would need to modify its value in .scss and regenerate the .css then.

For your other point, there's no need to introduce a new color for this, since the helper color is an alpha value derived from your foreground color (that's what currentColor is referring to), so if you change _fg_color in gtk.css, @borders will change along with it.

You're most certainly welcome.

I wanted to add on this, for anyone else stumbling across this post and struggling with sidebar theming: The above will work 90% of the time, but in case your some-random-theme.css overrides @sidebar_, or doesn't follow the naming convention to begin with, search your gtk.css for .sidebar-pane, which should be the actual css selector for @sidebar_, and .content-pane for @secondary-sidebar_.

Defining sidebar_bg_color does not work?

@define-color sidebar_bg_color 	
@define-color sidebar_fg_color 	
@define-color sidebar_backdrop_color 	
@define-color sidebar_border_color 	
@define-color sidebar_shade_color

@define-color secondary_sidebar_bg_color 	
@define-color secondary_sidebar_fg_color 	
@define-color secondary_sidebar_backdrop_color 	
@define-color secondary_sidebar_border_color 	
@define-color secondary_sidebar_shade_color

see libadwaita named colors

GTK Inspector comes with GTK, you don't need to install it.

Enable it with gsettings

gsettings get org.gtk.Settings.Debug enable-inspector-keybinding true

so you can invoke it either by running GTK_DEBUG=interactive application-name-here or, when alredy using the application, via Control + Shift + I/Control + Shift + D

While it's not a feature of lemmy, you can if you absolutely need to, without being subscribed to a kbin instance.

See for yourself: Go here to see this very thread on kbin, scroll down and click on the "favourites" tab, it will show you precisely who voted how on your post and when. For comments, see hitagi's reply.

This won't work as expected, I don't think?

Unless you installed the developer edition, which uses a separate profile/path, both of your installs will use the ~/.mozilla directory, so configs and profile of your new install will interfere with the ESR version.

(and why did you symlink /opt/firefox/firefox to /usr/bin/firefox? The desktop file already takes care of recognition)

Not quite. Snowflake, just like every other bridge, is one step before. Broadly speaking, blocked user connects to snowflake-proxy --> snowflake-proxy forwards blocked user's traffic to an entry node. And that's about it.

sounds like it turns your computer into a tor exit node?

Not at all. Snowflake belongs to the family of pluggable transports, and offers a connection to an entry node in the Tor Network. Just like a traditional bridge, with the advantage that the higher number of individual, constantly moving IP's makes blocking them by oppressive regimes more difficult.

It uses WebRTC to disguise the traffic as a real time peer to peer communication, like video/voice call.

Thanks for bringing some attention to this.

To add to the OP, if on linux or macOS, you may want to consider running a standalone proxy. Contrary to the browser extension it allows more than one connection at the same time and is more beneficial to the tor network all around.

Setting up is more than trivial following the instructions linked above, meanwhile snowflake got packaged for Debian, Ubuntu and a few others as well.

For macOS users there's is a homebrew package available.

Nah, you're good. For unknown reasons federation between kbin and lemmy.ml in particular is just fundamentally broken right now. There is some talk about this on lemmy.ml , there are a couple of threads about this topic on kbin as well somewhere, the most popular here.

Essence: Lots of speculation, nobody knows for sure, participation on lemmy.ml hosted discussions from kbin seems to be impossible right now (I tried, to no avail), federation between kbin and other lemmy instances does not seem to be impacted to the same extent, if at all?