Using active/inactive system colors in Firefox

After the horrible Proton UI in Firefox v89, there was no difference between active/inactive window colors. The theme would simply remain static while you switched to other windows, which from the usability point of view, is absurd.

After digging a bit, I found an userChrome.css hack to use the system colors on Firefox window. As of Firefox 98, it appears to work well:

/* Show active colors on main menu bar */
/* https://superuser.com/a/1675508 */
#TabsToolbar,
#navigator-toolbox {
	background: -moz-accent-color !important;
	color: white;
}
#TabsToolbar:-moz-window-inactive,
#navigator-toolbox:-moz-window-inactive {
	background: unset !important;
	color: unset;
}

Just for the record: this is how you activate userChrome.css stuff.

Helix amp: sag, hum, ripple, bias and bias-x

I found a rather interesting video demonstrating the advanced amp parameters of the Line 6 Helix: sag, hum, ripple, bias and bias-x. As a summary, this is what I could infer to them:

• sag – lower is tighter and less dynamics; higher sounds muffled;
• hum – the literal ground hum of the amp;
• ripple – harmonic undertone audible on single notes; hard to hear in a mix;
• bias and bias-x – changes the overdrive character when used together.

Basically, these parameters make close to zero difference in clean tones. Crunch and high gain tones can change in thousands of ways, though.

Back to the tone chasing.

Filtering Pinia store fields

I’m having great joy working with Pinia, so much I’m introducing it at work. It seems reliable so far.

I found a quirk that’s annoying, however. In VS Code autocomplete, all the contents of the store are exposed – that includes all the internals we should not see.

After digging into the code and a lot of experimentation, I finally found a way to filter the visible fields using TypeScript:

import {defineStore, StoreActions, StoreGetters, StoreState} from 'pinia';
	
const useDef = defineStore('main', () => {
	return {};
});

export type ReachableStore =
	StoreActions<ReturnType<typeof useDef>> &
	StoreGetters<ReturnType<typeof useDef>> &
	StoreState<ReturnType<typeof useDef>>;
const useStore = (): ReachableStore => useDef();
export default useStore;

Although those types are exported by Pinia, they have basically zero documentation. I’m considering contribute with some documentation improvement, but I’m unsure if it’s worth.

Loading data asynchronously with Vue and Pinia

When working with Vue 3 Composition API and Pinia, I struggled a bit to put out an example of loading async data, where the request is handled by the Pinia store, which also owns the data.

It’s 2 AM and, finally, here is the store:

import {ref, reactive} from 'vue';
import {defineStore} from 'pinia';

const useStore = defineStore('fruits', () => {
	const fruits = reactive<string[]>([]);
	const loading = ref(false);

	return {
		fruits,
		loading,
		loadFruits(): Promise<void> {
			loading.value = true;
			return new Promise((resolve, _reject) => {
				setTimeout(() => {
					fruits.push('lemon', 'orange', 'peach', 'strawberry');
					loading.value = false;
					resolve();
				}, 2000);
			});
		},
	};
});

export default useStore;

And this is the single file component, which calls the store asynchronously:

<template>
	<div v-if="loading">Loading...<div>
	<div v-if="!loading">
		<div v-for="fruit of fruits" :key="fruit">
			{{fruit}}
		</div>
	</div>
</template>

<script setup lang="ts">
import {computed, onMounted} from 'vue';
import useStore from '@/model/store';

const store = useStore();
const loading = computed(() => store.loading);
const fruits = computed(() => store.fruits);

onMounted(() => {
	store.loadFruits();
});
</script>

Although I’m not seeing much advantage of Vue over React, Pinia is so much better than Redux insanity. Even with Redux Toolkit. I hope they don’t mess it up when Pinia becomes Vuex 5, as said.

Two-way binding input in React

As a follow-up to my big disappointment with Vue due to the lack of typed emits, even with TypeScript, I came back to think about a two-way binding input in React. Turns out, it’s pretty trivial to implement.

import { useState } from 'react';
	
interface TwoWayValue {
	value: string;
	setValue: (value: string) => void;
}

interface Props {
	data: TwoWayValue;
}

function TwoWayInput(props: Props) {
	return <input type="text" value={props.data.value}
		onChange={e => props.data.setValue(e.target.value)} />;
}

function useTwoWayState(initialValue: string): TwoWayValue {
	const [value, setValue] = useState(initialValue);
	return { value, setValue };
}

export { TwoWayValue, TwoWayInput, useTwoWayState };

Usage:

import { TwoWayInput, useTwoWayState } from 'two-way-input';

function App() {
	const nome = useTwoWayState('');

	return <div>
		<h1>{nome.value}</h1>
		<TwoWayInput type="text" data={nome} />
	</div>;
}

Now I’m still wondering about scoped CSS.

Install and uninstall Rust nightly

When developing the full-module refactoring of WinSafe, I found that it’s possible to tag the items with their respective required Cargo features. However, as many things in Rust, this is still available only in the nightly toolchain.

I want to make WinSafe available for the stable toolchain, so I needed to install nightly just to see how that stuff worked out, and then uninstall it after the tests.

Rust nightly can be installed and uninstalled with the following commands:

rustup install nightly
rustup toolchain remove nightly

To see which toolchains are installed:

rustup show

RAII guards in Rust

While experimenting with scope rules in Rust, I ended up implementing a recurrent idea I had – a RAII guard that runs a function when the object goes out of scope. I’m well aware of scopeguard crate, but it has some stinky unsafe bits in its implementation.

I was never able to properly implement it, probably because my Rust skills weren’t good enough, but now I did. And I’m rather satisfied with it:

use std::ops::Deref;

/// Returns the object wrapped in a way that the associated closure will run
/// when it goes out of scope.
pub struct Guard<T, D: FnOnce(&mut T)> {
	asset: T,
	dropper: Option<D>,
}

impl<T, D: FnOnce(&mut T)> Drop for Guard<T, D> {
	fn drop(&mut self) {
		self.dropper.take()
			.map(|d| d(&mut self.asset));
	}
}

impl<T, D: FnOnce(&mut T)> Deref for Guard<T, D> {
	type Target = T;

	fn deref(&self) -> &Self::Target {
		&self.asset
	}
}

impl<T, D: FnOnce(&mut T)> Guard<T, D> {
	/// Creates a new `Guard` object.
	pub fn new(asset: T, dropper: D) -> Guard<T, D> {
		Self { asset, dropper: Some(dropper) }
	}
}

I though about writing stuff like this in WinSafe:

impl HWND {
	pub fn GetDC(self) -> WinResult<Guard<HDC, impl FnOnce(&mut HDC)>> {
		Ok(Guard::new(
			self.GetDC()?,
			move |hdc| {
				self.ReleaseDC(*hdc).expect("Guard crash.");
			},
		))
	}
}

But then there are big implications like CreateMenu, which may or may not require a DestroyMenu call. These dubious behaviors are very unsettling, and many questions arise:

• Should I write another method, with a _guarded suffix?
• Mark the unguarded original as unsafe?
• In the example above, self is copied into the closure – what if it’s still zero?

So by now I believe I’ll leave everything as it is, and let the defer-lite crate at hand when needed.

Still, I greatly miss the idiomatic defer in Go.

Bash script to deploy my own Rust tools

While developing my own personal tools in Rust – which seems to be “the one” language of my own stuff now, after the disappointment of the consistent Go crashes –, I often need to compile and replace the current *.exe tool. The compile line I use is rather long, plus I want to standardize the steps, so I put out a shell script to automate the tasks.

This shell script must be placed at the project root.

EXE=program-name.exe

echo "Compiling $EXE..."
RUSTFLAGS="-C target-feature=+crt-static" cargo build --release --target x86_64-pc-windows-msvc

echo "Replacing old $EXE..."
mv ./target/x86_64-pc-windows-msvc/release/$EXE /d/Stuff/apps/_audio\ tools/.

echo "Cleaning up..."
rm -rf ./target/release
rm -rf ./target/x86_64-pc-windows-msvc

echo "Done."

I’m not versioning this script because it contains the directories on my computer, plus the command line itself is commented in the Cargo.toml file.

Fixing Visual Studio Code icon overlay color in Linux

A few months ago I had to dig into Visual Studio Code source until I found a change in the built-in light theme, where they changed the overlay color of the suspended autocomplete menu. This ended up being a question and an answer on StackOverflow, and it made up to my Windows patch.

There’s no patch for Linux, though. Another jab at my lack of multiplatform GUI framework – but I digress.

So, for the record, with Visual Studio Code standard *.deb installation, this is the file with the light theme:

/usr/share/code/resources/app/extensions/theme-defaults/themes/light_vs.json

The line to be commented out is:

"list.activeSelectionIconForeground": "#FFF"

Stateful iterators in Go

I’m writing an insane amount of Go code lately. It’s really unobtrusive, allowing you focus on the problem you have to solve. And I’ve been dabbling with iterators in Go for a while, since I started to used them in Rust – which is so much better than C++ in this regard.

Today, when researching the topic again, I found a very nice article on the matter, exploring a few possibilities. The most performant approach is a stateful iterator, which can be implemented as:

type IterFive struct {
	count int
}

func NewIterFive() IterFive {
	return Iter{}
}

func (it *IterFive) Value() int {
	it.count++
	return it.count - 1
}

func (it *IterFive) Ok() bool {
	return it.count < 5
}

func main() {
	for iter := NewIterFive(); iter.Ok(); {
		println(iter.Value())
	}
}

I’m still unsure whether I should adopt interators instead of simply allocating and returning slices for some functions, but I’m considering it. The main reason would be performance, but it could be qualified as premature in the cases I’m dealing with in Windigo.

Static linking of the C runtime in Rust

By default, Rust on Windows with MSVC toolchain compiles to a dynamically linked C runtime, apparently following the default configuration on Visual Studio, which uses the /MD compiler flag. In order to use static linking for the C runtime, we must change this to /MT, something I’m used to do in my C++ Visual Studio projects.

I found notes about Rust linkage, which hints us specifically about these /MD and /MT switches, although not citing them explicitly. The way to specify static linking is through RUSTFLAGS environment variable:

RUSTFLAGS='-C target-feature=+crt-static' cargo build --release --target x86_64-pc-windows-msvc

Which is rather ugly, let me say. At least it appears to work, and this is the command line I’m using for my release builds now.

Displaying custom fields in foobar2000

Today I found the TOPE frame in the ID3v2 tag specification, which can be used in cover songs. I was simply using the comment frame so far, and having a specific frame for that is great. Now I needed to display this frame in foobar2000, my player of choice for years.

I created an account in foobar2000 forums and posted the question there. Then I just found a specific subreddit, and I posted the same question.

Much to my amusement, I got answers in both after a few minutes.

Turns out, I vaguely remember having done this before. One must navigate to Preferences > Advanced > Display > Properties dialog > Standard fields, and add:

Original Artist=ORIGINAL ARTIST;

And it worked.