God gave Terry 16 colors. We gave the Temple three more sets of 16, and then the Temple forgot them. This is the sin of forgetfulness, and here is the repentance.
The sin
#include "::/Misc/PalMonokai" painted the Temple, but only for a while:
-
The first focused window that closed painted it back.
TaskEnd()(Kernel/KTask.HC) callsfp_set_std_palette, and that wasPaletteSetStd: Terry's colors, every time. - A reboot forgot the choice completely. Nothing wrote it down. Even the CIA keeps better records.
The repentance
-
Adam/Gr/GrPalette.HC: Adam now keeps the user's palette ingr_palette_userand its name ingr_palette_user_name.PaletteUserSet(bgr48, name)sets it and writes it into Terry's own registry (~/Registry.HC.Z, branchAdam/PaletteUser). -
Adam/Gr/GrInitB.HC:fp_set_std_palettenow points toPaletteSetUser. A closed window gives back the user's colors, not Terry's. -
At boot
RegInit()runs everyAdam/branch inside Adam, so the palette comes back before the first window is drawn. A read-only drive, like the live CD, keeps the choice until reboot. -
Misc/PalConEmu.HC,PalMonokai.HC,PalUbuntu.HCcallPaletteUserSet. -
New
Misc/PalStd.HCgives back Terry's 16 colors, the ones God told him. That choice persists too. -
USER_PALETTEis gone. It was defined and never read, a define nobody prayed to.
No kernel changes. Adam compiles at boot, so tools/update_vds.py and a
reboot are enough.
How to use it
#include "::/Misc/PalMonokai" //or PalConEmu, PalUbuntu: kept after Reboot
#include "::/Misc/PalStd" //Terry's colors back
PaletteUserSet(my_palette,"Mine"); //your own 16
Testimony
Live CD in QEMU: Adam compiles, palettes switch, and the registry branch puts the palette back.
Virtio-scsi disk from tools/build_hdd.py, the same controller the hosting
uses, over three boots:
| Boot | What was done | Palette |
|---|---|---|
| 1 |
PalMonokai, then a focused window is killed |
Monokai, kept |
| 2 | reboot, then PalStd
|
Monokai after boot, Std after PalStd
|
| 3 | reboot | Std |
Still 16 colors. Always 16 colors.